在一次排查线上case的过程中，经分析后发现问题的原因是由于缓存淘汰策略存在问题而引起了缓存与数据库不一致，最终导致了业务异常
优化前的流程
写流程：
- 淘汰cache
- 写db
读流程：
- 读cache，若命中则返回
- 若未命中，则读db，将读出来的数据经过处理后写入缓存
注意：本文分析的前提是不考虑因请求db或cache失败而引起的数据不一致
什么场景下会出现数据不一致
在高并发的互联网应用中，读和写会同时存在，在缓存淘汰策略设置得不当的情况，就有可能发生数据不一致的情况，看看如下场景
1.png
若执行的顺序恰好为①清cache ②读cache miss ③读db ④写db ⑤写cache，在程序没有异常的情况下，就会出现缓存与数据库不一致的现象
若先写db，再清cache会不会出现数据不一致？
这种场景下，仍然会出现数据不一致，只是出现的概率会比先清cache后写db要小些，请看如下场景
假如读、写请求正好发生在同一时刻且请求db和cache时程序都没有发生异常
写请求
- 更新db（耗时4ms）
- 清除cache（耗时2ms）
读请求
- 读cache miss（耗时1ms）
- 读db（耗时2ms）
- 处理从db读出来的数据（耗时10ms）
- 写cache（耗时2ms）
在这种场景下，写请求在更新完db后，此时读请求读到的数据就变成脏数据了，由于读请求处理数据的时间较长，导致写cache发生在写请求清除cache之后，这样就导致cache里存的是脏数据，进而引发缓存与数据库不一致的问题
在使用了分布式缓存的应用中，当缓存的数据粒度比较粗时，往往需要针对从数据库里读出来的数据做进一步的处理，若数据处理的时间较长，在高并发的场景下，就很有可能会出现数据不一致的现象。
优化方案
采取清除两次cache的方案；第一次发生在操作完数据库后，同步清除，第二次延迟清除，延迟清除可以使用支持延迟投递的消息队列来实现。
2.png
