Redis实战案例4-缓存更新策略

1. 缓存更新策略

缓存中的数据一致性问题（数据库更新数据，而Redis存的是旧数据）
内存淘汰策略：当内存很充足时，很长时间无法淘汰数据，所以很难控制淘汰，一致性差；
超时剔除：取决于TTL大小，可以达到控制目的，但是在TTL时间内也可能存在数据库更新从而Redis中变成旧数据；
主动更新：也就是同时修改Redis和数据库的数据；

2. 主动更新策略

第二种：维护复杂，开发成本大；
第三种：维护异步任务难度大，要实时监控缓存中的变化；其次是一致性难以保证，如果缓存中已经存储了很多数据，但是还没有触发异步更新，这段时间内的缓存和数据库是不一致，当缓存宕机时，此时数据就会彻底丢失；

这里分析一下先操作缓存还是先操作数据库

1. 先删除缓存，再操作数据库

正常情况：

异常情况（未加锁）：这种情况出现的频率高，当删除缓存之后，数据库进行更新时业务复制且较慢，这是线程2就会可能上处理器，此时它去查询缓存时未命中（已删除），这时就去查数据库数据（还未更新），写入缓存的也就会是未更新的旧数据，此时就出现了数据不一致的问题；
这里有个速度差异的问题，读写缓存的速度是很快的，而读写数据库的操作是较慢的，相当于是内存和磁盘的速度差异问题，所以就很有可能出现下面这种情况；

2. 先操作数据库，再删除缓存

正常情况：

异常情况：这种情况出现的频率低，两个线程并行执行，且线程1查询缓存时恰好失效（TTL时间到了），这时未命中会去查询数据库，同时查完数据库得到数据10准备去写缓存。但是此时出现另一个线程2插入进来，进行更新数据库操作，并且删除缓存（但此时缓存已经被删除掉了），线程2结束了，线程1进行写缓存操作，之前已经查到的是数据10（因为并不知道已经修改），所以写入缓存10，出现了数据不一致问题；、

但是这种情况出现的频率非常低，首先要出现两个线程并行，其次是线程1查询缓存时恰好失效（TTL时间到了），同时线程1查完数据库写缓存时，线程2要求进行更新数据库操作。但是数据库的读写操作较Redis缓存读写操作要慢很多，所以数据库更新完毕之后再写缓存的概率极其低，也就是说极大部分情况在线程1读写完缓存之后，线程2才会进行数据库更新，并且还会删除该缓存。当再次查询时，会再次未命中，重新查询过数据库，最后缓存也就会设置为数据20；
所以在概率的角度来选择也是先操作数据库，再删除缓存，并且可以再加一个超时剔除策略；