请求缓存：
https://blog.csdn.net/xiaowangku/article/details/90409224
缓存的受益与成本
通过缓存加速读写速度：CPU L1/L2/L3 Cache、Linux page Cache加速硬盘读写、浏览器缓存、Ehcache缓存数据库结果。
- 降低后端负载
后端服务器通过前端缓存降低负载：业务端使用Redis降低后端MySQL负载等。
成本
- 数据不一致：缓存层和数据层有时间窗口不一致，和更新策略有关。
- 代码维护成本：多了一层缓存逻辑
使用场景
对高消耗的SQL：join结果集/分组统计结果缓存
加速请求响应：利用Redis、Memcache优化IO响应时间
大量写合并为批量写：如计数器先Redis累加再批量写DB
缓存的更新策略：
LRU方法，LFU方法FIFO方法： 例如maxmemory-policy。
超时提出： 例如：例如 expire
主动更新：开发控制生命周期：
策略： 一致性 维护成本
LRU/LIRS算法剔除 最差 低
超时剔除 较差 低
主动更新 强 高
缓存在细粒度的控制：
1、从MySQL获取用户信息：
select * from user where id={id}
2、设置用户信息缓存：
set user:{id} `select * from user where id={id}`
3、缓存粒度：
全部属性：set user:{id} `select * from user where id={id}`
set user:{id} `select importColumn1...importColumnK from user where id={id}`
三个角度
- 通用性：全量属性更好
- 占用空间：部分属性更好
- 代码维护：表面上全量属性更好
缓存穿透问题—大量请求不命中
正常情况下，当访问到cache，它会把结果返回给request，如果cache没有命中的话，它就会把流量往下引到存储层，如果存储层正常的话，存储层拿到结果，回写到cache，返回给request，当下次request再次访问的时候，就可以直接从cache中获取，那么就不需要访问到存储层了。
但是如果存储层的数据根本就不存在，那会有什么问题？
即它会返回给request为空的结果，当下次再来request请求，再访问cache层，cache层还是没有，还要再访问存储层，所有的流量都被导入到存储层，这就是缓存穿透的一个基本过程，实际上这就已经失去了缓存的意义
产生的原因
- 业务代码自身问题
- 恶意攻击、爬虫等
如何发现
- 业务的响应时间
- 业务本身问题
- 相关指标：总调度数、缓存层命中数、存储层命中数
解决方法1-缓存空对象
即如果存储层返回的结果为空，那么就把它当作一个结果，存储到cache中。
两个问题
1、需要存储更多的键（更多无效的键）。
2、缓存层和存储层数据“短期”不一致。
缓存雪崩优化
由于cache服务承载大量请求，当cache服务异常/脱机，流量直接压向后端组件（例如DB），造成级联故障。
缓存雪崩-优化方案
1、保证缓存高可用：个别节点、个别机器、甚至是机房。
2、依赖隔离组件为后端限流。
3、提前演练：例如压力测试。
无底洞问题优化
问题描述：
2010年，Facebook有了3000个Memcache节点
发现问题：“加”机器性能没能提升，反而下降
无底洞问题关键点
更多的机器！=更高的性能
批量接口需求（mget，mset等）
数据增长与水平扩展需求
参考博文：https://blog.csdn.net/xiaowangku/article/details/9040922
===========================================================
redis 缓存设计和优化
缓存的优缺点及使用场景
好处
1.加速读写：通过缓存加速读写，如 CPU L1/L2/L3 的缓存、Linux Page Cache 的读写、游览器缓存、Ehchache 缓存数据库结果。
2.降低后端负载：后端服务器通过前端缓存来降低负载，业务端使用 Redis 来降低后端 MySQL 等数据库的负载。
缺点
- 数据不一致：这是因为缓存层和数据层有时间窗口是不一致的，这和更新策略有关的。
- 代码维护成本：这里多了一层缓存逻辑，就会增加成本。
- 运维费用的成本：如 Redis Cluster，甚至是现在最流行的各种云，都是成本
使用场景
1.降低后端负载：这是对高消耗的 SQL，join 结果集和分组统计结果缓存
2.加速请求响应：这是利用 Redis 或者 Memcache 优化 IO 响应时间。
3.大量写合并为批量写：比如一些计数器先 Redis 累加以后再批量写入数据库。
缓存的更新策略
三种策略
1.LRU、LFU、FIFO 算法策略。例如 maxmemory-policy，这是最大内存的策略，当 maxmemory 最大时，会优先删除过期数据。我们在控制最大内存，让它帮我们去删除数。
2.过期时间剔除，例如 expire。设置过期时间可以保证其性能，如果用户更新了重要信息，应该怎么办。所以这个时候就不适用了。
3.主动更新，例如开发控制生命周期。
这三个策略中，一致性最好的就是主动更新。能够根据代码实时的更新数据，但是维护成本也是最高的；算法剔除和超时剔除一致性都做的不够好，但是维护成本却非常低。
- 低一致性：最大内存和淘汰策略，数据库有些数据是不需要马上更新的，这个时候就可以用低一致性来操作。
- 高一致性：超时剔除和主动更新的结合，最大内存和淘汰策略兜底。你没办法确保内存不会增加，从而使服务不可用了。
缓存的粒度问题：
我们知道，用户第一次的客户端，客户端访问 Redis 肯定是没有的，这个时候只能从数据库 DB 那里获取信息，代码如下：
select * from t_teacher where id= {id}
在 Redis 设置用户信息缓存，代码如下
set teacher:{id} select * from t_teacher where id= {id}
这个时候我们来看看缓存粒度问题。
因为我们要更新全部属性。到底我们是采用 select * 还是仅仅只是更新你需要更新的那些字段呢？如下两段代码：
set key1 = ? from select * from t_teacher
set key1 = ? from select key1 from t_teacher
缓存粒度控制可以从以下三个角度来观察，通过这三点来决定如何选择。
全量属性更好。上面一个对比 * 和某个字段的查询，最好是通过全量属性，这样的话，select * 具有很好的通用性，因为如果你 select 某个字段的话，未来如果一旦业务改变，代码也要随之改变才可以。
2.占用空间：部分属性会更好。因为这样占用的空间是最小的。
3.代码维护上：表面上全量属性会更好。我们真的需要全量吗？其实我们在使用缓存的时候，优先考虑的是内存而不单单只是保证代码的扩展性。
缓存穿透问题
大量请求不命中（即访问缓存拿数据时发现缓存里没有数据，然后再访问数据库拿数据发现还是没有）：
解决方案1：缓存空对象：
当缓存中不存在，访问到数据的时候，又找不到数据，需要设置给cache的数值为null,这样的下次的访问
id 的时候，就会直接访问缓存中的null 了。
解决方案2：布隆过滤器的拦截
布隆过滤器实际上一个很长的二进制向量，和系列的堆积函数。布隆过滤器的用于检索一个元素的是否在
一个集合内。他的优点是：空间效率，和查询的时间，远程超过一般的算法，
缺点： 有一定的错误识别率和删除困难。
总结：
缓存的收益： 加快读写，降低后端存储负载降低后端存储负载
缓存的成本：缓存和存储数据不一致性，代码维护成本、运维成本。
更新策略：推荐结合剔除、超时、主动更新三种方案共同完成。
穿透的优化：使用缓存空对象和布隆过滤器来解决，注意各自使用场景和局限性。
无底洞问题：分布式缓存中，堆积机器不一定会使得性能更好，有四种批量操作方式：串行命令、串行 IO、并行 IO、hash_tag。
雪崩问题：缓存层高可用、客户端降级、提前演练是解决雪崩问题的重要方法。
热点key问题：互斥锁和永不过期这两种方式能够在一定程度上解决热点key问题，但各自有自己的缺点需要我们了解
来源：CSDN
作者：thoughtCodes
链接：https://blog.csdn.net/xiamaocheng/article/details/104052590