一般套路
缓存由于其高并发和高性能的特性，已经在项目中被广泛使用。一般读缓存流程如下：
缓存更新的争议
主要是解决并发情况下缓存读与写的一致性和时效性
一 缓存不能读到脏数据
二 缓存可能会读到过期数据，但要在可容忍时间内实现最总一致
三 这个可容忍时间尽可能的小
基本核心套路（当然有很多变种，但主要思想如此）：
- 先更新数据库，再更新缓存
- 先删除缓存，再更新数据库
- 先更新数据库，再删除缓存
- 为什么没有先更新缓存，再更新数据库这种策略（ram、rom）
一、先更新数据库，再更新缓存
问题：同时有请求A和请求B进行更新操作，可能出现
（1）线程A更新了数据库 key = 1 value = 2
（2）线程B更新了数据库 key = 1 value = 3
（3）线程B更新了缓存 key = 1 value = 3
（4）线程A更新了缓存 key = 1 value = 2
这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据
方法：
- 更新缓存数据时判是否最新（如增加版本号）
- 只有比缓存中的新才可更新，否则不管（版本号大于当前版本号才可更新）
二、先删除缓存，再更新数据库
问题：同时有一个请求A进行更新操作，一个请求B进行查询操作。可能出现:
（1）请求A进行写操作（key = 1 value = 2），先删除缓存 key = 1 value = 1
（2）请求B查询发现缓存不存在
（3）请求B去数据库查询得到旧值 key = 1 value = 1
（4）请求B将旧值写入缓存 key = 1 value = 1
（5）请求A将新值写入数据库key = 1 value = 2
如果不采用给缓存设置过期时间策略，该数据永远都是脏数据
方法：
- 先删除缓存，再更新数据库，再回写缓存（出现套路一的情况）
- 先删除缓存，再更新数据库，再删缓存（双删，第二次删可异步）
数据库读写分离，本地缓存都不再适用，数据一致性需要用到远程数据同步
三、先更新数据库，再删除缓存
有两篇参考：《Cache-Aside pattern》、《Scaling Memcache at Facebook》
主要的思路就是先更新数据库，再删缓存的策略。
问题：一个请求A做查询操作，一个请求B做更新操作，可能情况
（1）缓存刚好失效
（2）请求A查询数据库，得一个旧值
（3）请求B将新值写入数据库
（4）请求B删除缓存
（5）请求A将查到的旧值写入缓存
如果发生上述情况，确实是会发生脏数据。然而，发生这种情况的概率又有多少呢？
我们知道一般来说读比写快很多，这一情形很难出现。
二、三套路的共性问题：删缓存失败了怎么办？
方案一
方案缺点：
- 引入中间件，增加复杂度
- 对业务线代码造成大量的侵入
方案二
启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。
mysql中有现成的中间件叫canal，可以完成订阅binlog日志的功能。
另我团的DataBus更强大。
四、缓存的不适用场景
- 写多：如果新增、修改、删除比较多，则需慎用缓存，因为缓存会频繁的更新会很浪费性能。
- 大Key/Value：大到会影响GC、swap，最好别用。
