AAA Redis的过期删除策略+缓存雪崩+缓存一致性问题

目录

一、三种删除策略比较

二、缓存雪崩+缓存击穿+缓存穿透

三、缓存一致性

---

Redis学习笔记

一、三种删除策略比较

	内存占用	CPU占用	特征
定时删除	节约内存，无占用	不分时段占用CPU资源，频度高	时间换空间
惰性删除	内存占用严重	延时执行，CPU利用率高	空间换时间
定期删除	内存定期随机清理	每秒花费固定的CPU资源维护内存	随机抽查，重点抽查

1.定时删除：创建一个定时器，当key过期时，定时器立即删除过期数据。这样做节约内存，但是cpu负荷高，由于redis时单线程的，在访问量大时，甚至会引起线程阻塞。

2.惰性删除： 数据到达过期时间，不做处理。等下次访问该数据时，如果未过期，返回数据。如果已过期，删除，返回不存在。这样CPU压力会降低，但是内存压力很大，长期有过期数据占用内存。

3.定期删除：这种策略平衡了前两种极端的方案，Redis启动服务器初始化时，读取配置server.hz的值，默认为10.每秒执行server.hz次的serverCron()中的方法，周期性的轮询redis库中的时效型数据，采用随机抽取的策略，利用过期数据占比的方式控制删除频度（过期数据的比例不超过25%）。

定期删除的优点在于CPU性能占用设置有峰值，检测频度可自定义，内存压力和CPU压力都不大。但是仅仅是通过给key设置时长还是有问题的，因为还是有很多过期key堆积在内存中，容易引起Out Of Memory。那么如何解决这方面的问题呢？就是Redis的内存淘汰机制（逐出算法）。

Redis使用内存存储数据，在执行没一个命令前，会调用FreeMemoryIFNeeded（）检查内存是否充足，如果内存不满足新加入数据的最低存储要求，redis要删除一些数据为清理空间。清理的策略被称为逐出算法：

Redis目前有8种逐出策略：

1.volatile-lru：从已设置过期时间的数据中，挑选最近最少使用的数据淘汰。（针对时间）

2.volatile-lfu：从已设置过期时间的数据中，挑选最近使用次数最少的数据淘汰。（针对访问频率）

3.volatile-ttl：从已设置过期时间的数据中，挑选快要过期的数据。

4.volatile-random：从已设置过期时间的数据中，任意选择数据淘汰。

5.allkeys-lru：在所有的key中，移除最近最少使用的key。

6.allkeys-lfu:在所有的key中，移除最近使用次数最少的key。

7.allkeys-random：任意挑选数据淘汰。

8.no-eviction：禁止驱逐数据（Redis4.0默认策略）。

需要注意的时，逐出过程并不是100%的能够清理出足够的空间，如果不成功反复执行，在所有数据都尝试完毕后，如果还是不能满足内存清理的要求，将会出现错误信息。

(error) OOM command not allowed when used memory >'maxmemory'

二、缓存雪崩+缓存击穿+缓存穿透

缓存预热：在系统启动前，提交将相关的缓存数据直接加载到缓存系统，避免在用户请求的时候，先查数据库，然后再缓存数据的问题，

缓存雪崩：大面积key同一时间失效，所有请求直接落在数据库上，造成数据库压力过大，可能导致服务器宕机。

解决方案：1.更多的页面静态化处理；

                  2.构造多级缓存

                  3.灾难预警机制

                  4.限流，降级（短时间牺牲客户体验，限制一部分请求，降低服务器压力，待业务低速运转后，再逐步放开）

                  5.删除策略进行切换（lru->lfu）

                  6.数据分类，有效期策略调整（稀释集中到期的key的数量）

                  7.超热数据 永久key

缓存击穿：某个热点key过期，大量请求落在服务器。

解决方案：1.二级缓存

                   2.设置永久key

                   3.延长过期时间，待访问量降低后移除

缓存穿透：redis出现大面积未命中（请求的key不在redis中，直接落在服务器）

 解决方案：1.布隆过滤器

                    2.缓存null

                    3.做好参数校验

                    4.实时监控（redis的命中率）

                    5.key加密（不满足直接驳回）

三、缓存一致性

缓存数据同步的常见方式有三种：

• 设置有效期：给缓存设置有效期，到期后自动删除。再次查询时更新
  • 优势：简单、方便
  • 缺点：时效性差，缓存过期之前可能不一致
  • 场景：更新频率较低，时效性要求低的业务
• 延时双删：在修改数据库的同时，直接修改缓存
  • 优势：时效性强，缓存与数据库强一致
  • 缺点：有代码侵入，耦合度高；
  • 场景：对一致性、时效性要求较高的缓存数据
• 异步通知（MQ或监听bin log）：修改数据库时发送事件通知，相关服务监听到通知后修改缓存数据
  • 优势：低耦合，可以同时通知多个缓存服务
  • 缺点：时效性一般，可能存在中间不一致状态
  • 场景：时效性要求一般，有多个服务需要同步