1、背景

先阐明一下Mysql和Redis的关系：Mysql是数据库，用来持久化数据，一定程度上保证数据的可靠性；Redis是用来当缓存，用来提升数据访问的性能。

关于如何保证Mysql和Redis中的数据一致（即缓存一致性问题），这是一个非常经典的问题。其实网上应该是有很多相关的介绍，但是其实从实际出发，如果数据存在频繁的写操作，是不建议直接放到Redis中的，并且无论是哪种方式，其实都不能说完全可以使得数据一致性，我们只能说尽可能的让数据在绝大部分时间内保持一致，并保证最终是一致的。

2、产生原因

如果数据一直没有变更，那么就不会出现缓存不一致的问题。

通常缓存不一致是发生在数据有变更的时候。 因为每次数据变更你需要同时操作数据库和缓存，而他们又属于不同的系统，无法做到同时操作成功或失败，总会有一个时间差。在并发读写的时候可能就会出现缓存不一致的问题（理论上通过分布式事务可以保证这一点，不过实际上基本上很少有人这么做，也可以通过订阅binlog日志来操作，但是系统的复杂度就会提高，也不建议）。

虽然没办法在数据有变更时，保证缓存和数据库强一致，但对缓存的更新还是有一定设计方法的，遵循这些设计方法，能够让这个不一致的影响时间和影响范围最小化

3、缓存更新的几种设计

• 先删除缓存，再更新数据库（这种方法在并发下最容易出现长时间的脏数据，不可取） 
• 先更新数据库，删除缓存
• 只更新缓存，由缓存自己同步更新数据库 
• 只更新缓存，由缓存自己异步更新数据库
• 经典延时双删策略

简单介绍：

• 先删除缓存，再更新数据库

这种方法在并发读写的情况下容易出现缓存不一致的问题

如上图所示，其可能的执行流程顺序为：

• 客户端1 触发更新数据A的逻辑

• 客户端2 触发查询数据A的逻辑

• 客户端1 删除缓存中数据A

• 客户端2 查询缓存中数据A，未命中

• 客户端2 从数据库查询数据A，并更新到缓存中

• 客户端1 更新数据库中数据A

可见，最后缓存中的数据A跟数据库中的数据A是不一致的，缓存中的数据A是旧的脏数据。

因此一般不建议使用这种方式。

• 先更新数据库，再让缓存失效

这种方法在并发读写的情况下，也可能会出现短暂缓存不一致的问题 

如上图所示，其可能执行的流程顺序为：

• 客户端1 触发更新数据A的逻辑

• 客户端2 触发查询数据A的逻辑

• 客户端3 触发查询数据A的逻辑

• 客户端1 更新数据库中数据A

• 客户端2 查询缓存中数据A，命中返回（旧数据）

• 客户端1 让缓存中数据A失效

• 客户端3 查询缓存中数据A，未命中

• 客户端3 查询数据库中数据A，并更新到缓存中

可见，最后缓存中的数据A和数据库中的数据A是一致的，理论上可能会出现一小段时间数据不一致，不过这种概率也比较低，大部分的业务也不会有太大的问题。这种方式相对第一种的可用性就大大提高。

• 只更新缓存，由缓存自己同步（异步）更新数据库

 大致思路：当A请求来的时候，只对缓存做更新操作，然后后续的请求来的时候，获取到的都是最新的缓存中的值。这样子读请求的数据可以到达一致性。当A请求更新完缓存的时候，再又缓存自己去同步（异步）更新数据库。只不过需要对缓存进行专门的改造。同步的方式相对异步较好，因为异步的情况会存在如果在缓存异步将数据更新到数据库中时，缓存服务挂了，此时未更新到数据库中的数据就丢失了。

•  延时双删策略

这个的相关介绍应该就很多了，在做数据更新的操作时候执行，大致简单的思路就是：先删除缓存数据 ->再执行update更新数据库数据 ->最后（延时N秒）执行删除缓存 。

这里有一个问题其实还是会存在，就是关于延时时间的问题，因为如果延时太久可能导致程序卡主时间较长，但是最终结果肯定是更好的准确。但是在高并发情况下，是不允许的。如果时间太短，可能会导致数据库数据更新还未完成就已开始执行删除的操作。一般更新自己系统日常的允许运行时长，可以来自定义时间。这里给一个参考时间500ms。

总结

综上所述，其实没有绝对完美的方式来解决数据一致性的问题，只能说尽最大的可能来对数据库的一致性进行保障。如果系统有机会引入第三方的监测软件（例如canal）也是可以的，但是不建议引入额外第三方，不然部署和日常开发都会增加额外的成本。

Redis的数据如果像上面说的，真的会存在很频繁的更新操作其实也不建议放Redis，直接通过数据库来查询，毕竟数据的准确性重要程度远远大于时效性。

根据上面的分析，个人建议可以采用 第二种：先更新数据库，再删除缓存。第五种：延时双删策略