缓存的收益与成本
①收益
- 加速读写：因为缓存通常都是全内存的（例如Redis、Memcache），而存储层通常读写性能不够强悍（例如MySQL），通过缓存的使用可以有效地加速读写，优化用户体验。
- 降低后端负载：帮助后端减少访问量和复杂计算（例如很复杂的SQL语句），在很大程度降低了后端的负载。
②成本 - 数据不一致性：缓存层和存储层的数据存在着一定时间窗口的不一致性，时间窗口跟更新策略有关。
- 代码维护成本：加入缓存后，需要同时处理缓存层和存储层的逻辑，增大了开发者维护代码的成本。
- 运维成本：以Redis Cluster为例，加入后无形中增加了运维成本。
使用场景 - 开销大的复杂计算：以MySQL为例子，一些复杂的操作或者计算（例如大量联表操作、一些分组计算），如果不加缓存，不但无法满足高并发量，同时也会给MySQL带来巨大的负担。
- 加速请求响应：即使查询单条后端数据足够快，那么依然可以使用缓存，以Redis为例子，每秒可以完成数万次读写，并且提供的批量操作可以优化整个IO链的响应时间
缓存更新策略
内存溢出淘汰策略
当Redis所用内存达到maxmemory上限（used_memory>maxmemory）时会触发相应的溢出控制策略。具体策略受maxmemory-policy参数控制。
Redis支持6种策略：
1）noeviction：默认策略，不会删除任何数据，拒绝所有写入操作并返回客户端错误信息（error）OOM command not allowed when used memory，此时Redis只响应读操作。
2）volatile-lru：根据LRU算法删除设置了超时属性（expire）的键，直到腾出足够空间为止。如果没有可删除的键对象，回退到noeviction策略。
3）volatile-random：随机删除过期键，直到腾出足够空间为止。
4）allkeys-lru：根据LRU算法删除键，不管数据有没有设置超时属性，直到腾出足够空间为止。
5）allkeys-random：随机删除所有键，直到腾出足够空间为止。
6）volatile-ttl：根据键值对象的ttl属性，删除最近将要过期数据。如果没有，回退到noeviction策略
内存溢出控制策略可以采用config set maxmemory-policy{policy}动态配置。
写命令导致当内存溢出时会频繁执行回收内存成本很高，如果Redis有从节点，回收内存操作对应的删除命令会同步到从节点，导致写放大的问题。
过期删除
- 惰性删除
Redis的每个库都有一个过期字典，过期字典中保存所有key的过期时间。当客户端读取一个key时会先到过期字典内查询key是否已经过期，如果已经超过键，会执行删除操作并返回空。，这种策略是出于节省CPU成本考虑，但是单独用这种方式存在内存泄露的问题，当过期键一直没有访问将无法得到及时删除，从而导致内存不能及时释放。 -
定时删除
Redis内部维护一个定时任务，默认每秒运行10次。通过hz修改运行次数。定时任务中删除过期键逻辑采用了自适应算法，根据键的过期比例、使用快慢两种速率模式回收键。ServerCron
慢模式：定时任务执行时间超过25毫秒自动退出
快模式：上次执行时间超过25毫秒，则采用快模式，快模式下超时时间为1毫秒且2秒内只能运行1次。
应用方更新
a、应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
b、先删除缓存，再更新数据库
这个操作有一个比较大的问题，更新数据的请求在对缓存删除完之后，又收到一个读请求，这个时候由于缓存被删除所以直接会读库，读操作的数据是老的并且会被加载进入缓存当中，后续读请求全部访问的老数据。
c、先更新数据库，再删除缓存(推荐)
为什么不是写完数据库后更新缓存？主要是怕两个并发的写操作导致脏数据。
缓存粒度
通用性
缓存全部数据比部分数据更加通用，但从实际经验看，很长时间内应用只需要几个重要的属性。
占用空间
缓存全部数据要比部分数据占用更多的空间，存在以下问题：
- 全部数据会造成内存的浪费。
- 全部数据可能每次传输产生的网络流量会比较大，耗时相对较大，在极端情况下会阻塞网络。
- 全部数据的序列化和反序列化的CPU开销更大。
代码维护
全部数据的优势更加明显，而部分数据一旦要加新字段需要修改业务代码，而且修改后通常还需要刷新缓存数据。
缓存穿透
缓存穿透是指查询一个根本不存在的数据，缓存层和持久层都不会命中，通常出于容错的考虑，如果从持久层查不到数据则不写入缓存层。
缓存穿透示意图
缓存穿透将导致不存在的数据每次请求都要到持久层去查询，失去了缓存保护后端持久的意义。
缓存穿透问题可能会使后端存储负载加大，由于很多后端持久层不具备高并发性，甚至可能造成后端存储宕掉。通常可以在程序中统计总调用数、缓存层命中数、如果同一个Key的缓存命中率很低，可能就是出现了缓存穿透问题。
造成缓存穿透的基本原因有两个。第一，自身业务代码或者数据出现问题，第二，一些恶意攻击、爬虫等造成大量空命中。
①缓存空对象
缓存空对象会有两个问题：第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为5分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。
②布隆过滤器拦截
在访问缓存层和存储层之前，将存在的key用布隆过滤器提前保存起来，做第一层拦截，当收到一个对key请求时先用布隆过滤器验证是key否存在，如果存在在进入缓存层、存储层。可以使用bitmap做布隆过滤器。这种方法适用于数据命中不高、数据相对固定、实时性低的应用场景，代码维护较为复杂，但是缓存空间占用少。
布隆过滤器实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。
算法描述：
- 初始状态时，BloomFilter是一个长度为m的位数组，每一位都置为0。
- 添加元素x时，x使用k个hash函数得到k个hash值，对m取余，对应的bit位设置为1。
- 判断y是否属于这个集合，对y使用k个哈希函数得到k个哈希值，对m取余，所有对应的位置都是1，则认为y属于该集合（哈希冲突，可能存在误判），否则就认为y不属于该集合。可以通过增加哈希函数和增加二进制位数组的长度来降低误报率。
方案对比：
缓存雪崩
由于缓存层承载着大量请求，有效地保护了存储层，但是如果缓存层由于某些原因
不可用或者大量缓存由于超时时间相同在同一时间段失效，大量请求直接到达存储层，存储层压力过大导致系统雪崩。
解决方案：
- 可以把缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务。利用sentinel或cluster实现。
- 采用多级缓存，本地进程作为一级缓存，redis作为二级缓存，不同级别的缓存设置的超时时间不同，即使某级缓存过期了，也有其他级别缓存兜底。
- 缓存的过期时间用随机值，尽量让不同的key的过期时间不同。
缓存击穿
系统中存在以下两个问题时需要引起注意：
- 当前key是一个热点key（例如一个秒杀活动），并发量非常大。
重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的SQL、多次IO、多个依赖等。 - 在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃。
解决方案：
①分布式互斥锁
只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可。set(key,value,timeout)
②永不过期 - 从缓存层面来看，确实没有设置过期时间，所以不会出现热点key过期后产生的问题，也就是“物理”不过期。
- 从功能层面来看，为每个value设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去更新缓存。
2种方案对比： - 分布式互斥锁：这种方案思路比较简单，但是存在一定的隐患，如果构建缓存过程出现问题或者时间较长，可能会存在死锁和线程池阻塞的风险，但是这种方法能够较好地降低后端存储负载，并在一致性上做得比较好。
- “永远不过期”：这种方案由于没有设置真正的过期时间，实际上已经不存在热点key产生的一系列危害，但是会存在数据不一致的情况，同时代码复杂度会增大。
网友评论