redis缓存更新、过期策略

更像是笔记，所以不会介绍的太详细
缓存过期策略：
redis是单线程，收割时间也会占用线程处理时间，如果收割过于频繁，会导致读写出现卡顿
1、主库过期策略：
1.1、定时扫描
首先将每个设置了过期时间的key放到一个独立的hash中，默认每秒定时遍历这个hash而不是整个空间：
并不会遍历所有的key，采用一种简单的贪心策略
1.1.1、从过期key字典中，随机找20个key。
1.1.2、删除20gekey中过期的key
1.1.3、如果2中过期的key超过1/4，则重复第一步
1.1.4、每次处理的时间都不会25ms
如果有大量的key在同一时间段内过期，就会造成数据库的集中访问，就是缓存雪崩！
1.2、惰性策略
客户端访问的时候，会对这个key的过期时间进行检查，如果过期了就立即删除。惰性策略是对定时策略的补充，因为定时策略不会删除所有过期的key
2、从库过期策略：
redis不会扫描从库，删除主库数据的时候，在aof文件里生成一条del指令，在主从同步的时候，从库会执行这条指令，删除过期key。
所以集群分布式锁算法的漏洞就是这样产生的。

缓存更新策略：
更新缓存的设计模式有四种：Cache aside, Read through, Write through, Write behind caching
Cache aside
读取：
失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。
命中：应用程序从cache中取数据，取到后返回。
更新：先把数据存到数据库中，成功后，再让缓存失效。

Read/Write Through Pattern
我们可以看到，在上面的Cache Aside套路中，我们的应用代码需要维护两个数据存储，一个是缓存（Cache），一个是数据库（Repository）。所以，应用程序比较啰嗦。而Read/Write Through套路是把更新数据库（Repository）的操作由缓存自己代理了，所以，对于应用层来说，就简单很多了。可以理解为，应用认为后端就是一个单一的存储，而存储自己维护自己的Cache。

1.Read Through
    Read Through 套路就是在查询操作中更新缓存，也就是说，当缓存失效的时候（过期或LRU换出），Cache Aside是由调用方负责把数据加载入缓存，而Read Through则用缓存服务自己来加载，从而对应用方是透明的。

2.Write Through
   Write Through 套路和Read Through相仿，不过是在更新数据时发生。当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后再由Cache自己更新数据库（这是一个同步操作）

Write Behind Caching Pattern
Write Back套路，一句说就是，在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。这个设计的好处就是让数据的I/O操作飞快无比（因为直接操作内存嘛 ），因为异步，write backg还可以合并对同一个数据的多次操作，所以性能的提高是相当可观的。
但是，其带来的问题是，数据不是强一致性的。