1 关于一致性
为加速系统性能一般都会引入缓存机制，比如 Redis。这种情况下当用户读数据时一般会按照如下流程：
关于读的流程大家是没有异议的，但是对于数据的更新呢，如何操作才算合理呢？
先更新数据库再更新缓存。
先删缓存再更新数据库。
先更新数据库再删缓存。
2 一致性解决方法
2.1 缓存TTL
简单直接又暴力的方法，如果有些数据不重要，我们读完一次数据到缓存后设置个TTL即可，等待超时后缓存自动从数据库读取下数据。
2.2 先更新数据库 再更新缓存
大部分观点认为，做缓存不应该是去更新缓存，而是应该删除缓存，然后由下个请求去去缓存，发现不存在后再读取数据库，写入缓存。
原因一：线程安全角度
同时有请求A和请求B进行更新操作，那么会出现
（1）线程A更新了数据库
（2）线程B更新了数据库
（3）线程B更新了缓存
（4）线程A更新了缓存
这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。
原因二：业务场景角度
有如下两点：
（1）如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能，我们的缓存是用在写的上面的，而再修改的时候我们一直修改是很不合理的，因为我们在为用不到缓存的地方去消耗资源。
（2）如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合。
例子：
假如我们有A、B两个请求，A请求将age = 14，B请求将age = 12。我们看下正常执行跟非正常执行情况：
可发现如果出现网络震荡会导致缓存的数据是旧数据。因此这种方法不可取。并且如果是如下场景也不合适：
写场景多而读场景少的业务需求，此时缓存不是经常性的读，却被频繁的更新。
如果缓存的数据是经过各种复杂计算后写入的，那每次写入缓存都要运算一次，此法不可取。
2.3 先删缓存 再更新数据库
假如A先请求更改数据，B请求读数据，如果因为网络导致发生如下情况也会造成缓存脏数据，如果此时缓存没有设置TTL那会一直是脏数据。
上面这种情况如何解决呢？一般可以采用延时双删策略，他的核心执行流程如下：
public void write(String key,Object value){
redis.delKey(key);
db.updateValue(value);
Thread.sleep(1000); // 再次删除
redis.delKey(key);
}
该思路落实到流程图上如下所示：
sleep的时间要根据业务数据逻辑耗时而定，反正目的是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。
当然如果用的是主从写读架构，那处理思路跟上面类似，无非就是休眠时间再加上主从同步的时间即可。
可是其实第二次删除还是有不妥的地方：
二次删除前面涉及到休眠，可能导致系统性能降低，可以采用异步的方式，再起一个线程来进行异步删除。
如果二次删除失败了，还是会导致缓存脏数据存在的啊！
2.4 先更新数据库 再删缓存
针对缓存更新问题，老外提出了一个名为《Cache-Aside pattern》的缓存更新套路，该策略在Facebook中也广泛使用，该策略指出：
失效：应用程序先从缓存取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。命中：应用程序从缓存中取数据，取到后返回。更新：先把数据存到数据库中，成功后，再让缓存失效。
假如此时A、B两个线程同时请求，正常来讲不管你是读写分离还是单机版，读一般比写快。那删除缓存一般是有效的。
但是也有可能别的原因导致读比写还慢，导致我们删了个寂寞，虽然这种情况很少发生。
该方案相比先删除缓存再更新数据库还是稳妥些的，但是也不是万无一失的。不管是先删缓存再更新数据库还是先更新数据库再删缓存，如果删除缓存失败了都会导致缓存跟数据不一致问题！
2.5 消息队列 确保消息删除
通过消息队列的确认消费机制来删除缓存。
缺点也很明显：
对业务线代码造成大量的侵入，引入了中间件。
消息的延迟删除也会造成短暂的不一致。
2.6 专门程序+消息队列 确保消息删除
该方案启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。
订阅binlog程序在mysql中有现成的中间件叫canal，可以完成订阅binlog日志的功能。
3 总结
分析后你会发现数据更新时缓存是删除不是更新，而删除缓存一般有三种方法：
如果缓存数据不敏感，直接给缓存设置TTL即可。
先删缓存再更新数据库，此时需配合延时双删技术，但可能导致二次删除失败。
先更新数据库再删缓存，此时需配合binlog消费 + 消息队列来实现。
