提到缓存，作为服务端的开发人员并不陌生，无论是本地缓存还是分布式缓存，其目的都是为了提高系统响应速度的同时减轻数据库的查询压力；在缓存开发中有个问题必需要解决，那就是“缓存一致性问题”！
缓存一致性
软件开发中的缓存一致性是指缓存中的数据要和数据库(或者数据提供方)的数据保持一致
关于缓存
我们必需要明白一点，并不是所有的场景下都适合加入缓存，当数据量较小时合理利用数据库的索引来加快查询速度来的更加方便。除非
-
- 数据量比较大单纯数据库查询性能无法满足性能要求
- 数据的查询比较频繁且更新频率不高
- 业务上必需能够容忍短暂的数据不一致的情况，如果是类似于银行金额等要求必须实时一直的情况，请慎用缓存
缓存一致性方案探讨
你是否被问过这个问题：当数据发生变更时，是先更新缓存还是先更新数据库？
这是一个在面试中经常被问到的问题，一般来讲，这个时候无论你回答先更新哪个答案都是错误的。
-
- 先更新缓存，那万一更新完缓存，数据库更新失败了怎么办？
- 先更新数据库，如果更新数据库成功，更新缓存失败了怎么办？
无论上述两种情况任何一种出现，都会导致缓存和数据库的数据不一致的情况
为了解决上述问题，我们一般会想到
“先删除缓存，然后再更新数据库，这样即使更新失败了，缓存也不会出现脏数据”真的是这样吗？
在单线程操作的情况下确实是这样的，但是实际应用中我们没法控制客户端请求是线性运行的，所以先删除缓存在更新数据库的方案是不可行的，容易产生脏数据。如图
缓存双删
为了保证缓存和数据库的数据一致
先删除缓存—>更新数据库—>再次删除缓存数据
如上图所示，双删也可能会存在问题，比如T5时刻删除了缓存，T6时刻却将T3时刻读取的数据更新到了缓存，从而导致缓存数据与数据库数据不一致；
针对上面存在的问题，我们可以采取如下方案
改进方案
一.锁加延时删除
流程说明：
- 上图锁并不能解决线程安全问题，而是为了减少查询线程查询数据库后更新缓存的次数（锁验证），若考虑到操作的便利性也可以去掉流程中的锁相关环节；
- 为了提高更新线程的并发效率，上图中的锁可以使用累加锁标记。默认是0（无锁），以后每一个更新线程获取锁时都对锁计数+1，更新线程释放锁的时候锁计数-1；
- 多个更新线程的并发及顺序问题可以交给数据库来控制也可以在业务中额外增加分布式锁或者有序队列来实现
- 查询线程中的获取锁可以理解为判断当前锁标记的计数是否等于0；
- 更新线程中先获取 锁再删除是考虑到如果先删除缓存的话在获取 锁之前，查询线程会额外增加一次线程更新操作；
- 在释放锁之后再次延时删除缓存是为了避免在查询线程在查询完数据库后，更新线程更新了数据库的值，此时查询线程将刚刚查询到的旧数据维护进缓存；
- 在更新和查询都比较频繁的情况下，更新的时候，根据数据的唯一标识，将操作添加进有序队列中进行处理。读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据+更新缓存的操作，根据唯一标识也发送一个有序队列中，但是要考虑到请求效率和超时问题。
写在最后，鉴于笔者能力有限，上述方案获取存在着不足，如果您发现有不足的地方，欢迎留言讨论
