作者：京东零售 于泷
在高并发场景中，为防止大量请求直接访问数据库，缓解数据库压力，常用的方式一般会增加缓存层起到缓冲作用，减少数据库压力。引入缓存，就会涉及到缓存与数据库中数据如何保持一致性问题，本文将对几种缓存与数据库保证数据一致性的使用方式进行分析。为保证高并发性能，以下分析场景不考虑执行的原子性及加锁等强一致性要求的场景，仅追求最终一致性。
• 读缓存
• 如果缓存里没有值，那就读取数据库的值
• 同时把这个值写进缓存中
更新操作有多种策略，各有优劣，主要针对此场景进行分析
问题：
1.如果更新db成功，删缓存失败，将导致数据不一致
2.极端场景，请求A读，B写
1)此时缓存刚好失效 2）A查库得到旧值 3）B更新DB成功
4）B删除缓存 5）A将查到的旧值更新到缓存中
此场景的发生需要步骤2）查db 始终慢于 3）的更新db，才能导致4）先于5）执行，通常db的查询是要快于写入的，所以此极端场景的产生过于严格，不易发生
问题：
1.并发更新场景下，更新缓存会导致数据不一致
2.根据读写比，考虑是否有必要频繁同步更新缓存，而且，如果构造缓存中数据过于复杂，或者数据更新频繁，但是读取并不频繁的情况，还会造成不必要的性能损耗
此种方式不推荐
同上，不推荐
先删缓存，虽然解决了策略1中，后删缓存如果失败的场景，但也会发生不一致的问题
例如：请求 A 删除缓存，这时请求B来查，就会击穿到数据库，B读取到旧的值后写入缓存，A正常更新db,由于时间差导致数据不一致的情况
该策略兼容了策略1和策略4,解决了先删缓存还是后删缓存的问题，如策略1中，更新db后删缓存失败和策略4中的不一致场景，该策略可以将延时时间内（比如延时10ms）所造成的缓存脏数据，再次删除。但是，如果延时删缓存失败，策略4中不一致问题还会发生，同时延时的实现，如创建线程，或者引入mq异步，可能会增加系统复杂度问题。
该策略针对策略1中后删缓存失败的场景，前置一层缓存数据过期时间（具体时间根据自身系统本身评估，如可覆盖db读写耗时或一致性容忍度等），更新db后就算删缓存失败，在expire时间后也能保证缓存中无数据。同时，前置expire失败，或者更新db失败，都不会影响数据一致。
能够解决策略4中的问题：请求 A 删除缓存，这时请求B来查，就会击穿到数据库，B读取到旧的值后写入缓存，A正常更新db,由于时间差导致数据不一致的情况，描述图如下：
本策略中步骤1为expire缓存，不会发生击穿缓存到数据库的情况,数据将直接返回。除非更极端情况，如下图:
expire时间没有覆盖住更新db的耗时，类似策略1中极端场景，此处不赘述
对于每种方案策略，各有利弊，但一致性问题始终存在（文章开头排除了原子性和锁），只是发生的几率在一点点慢慢变小了，方案的评估不仅要根据自身系统的业务场景，如读写比、并发量、一致性容忍度，还要考虑系统复杂度，投入产出比等，寻找最合适的方案。
原文链接：https://www.cnblogs.com/jingdongkeji/p/17333646.html
本文链接：http://task.lmcjl.com/news/18205.html
