关于MySQL、redis双写一致性的思考

首先先说结论

我认为没有办法来保证MySQL、redis的双写强一致性。最终下边文章讨论的只是双写的最终一致性。

思考的问题

1. 应该先操作数据库，还是先操作缓存？
2. 操作缓存时是应该删除还是更新？

针对问题的讨论

其实针对上面的两个问题，可以分成四种情况

1. 先更新缓存，再操作数据库
2. 先删除缓存，再操作数据库
3. 先操作数据库，再更新缓存
4. 先操作数据库，再删除缓存

先更新缓存，再操作数据库

这个方式有很大的弊端，比如缓存更新成功了，数据库更新失败，会导致缓存值脏数据的出现。

先操作数据库，再更新缓存

如果再高并发的情况下，可能会存在如下的情况，线程A更新了数据库，如果由于网络或者其他的原因，线程A还没来得及更新缓存，这时候有一个进程B更新了数据库，更新了缓存，这时候进程A才更新缓存，这时候就会导致线程B对缓存的更新丢失了，像事务丢失的情况

先删除缓存，再操作数据库

这种策略可能已经避免掉了，缓存丢失的情况，但是再高并发的情况下，也会有不一致的情况，比如线程A做写操作，首先删除缓存然后准备更新数据库，这时候，线程B执行了写操作，没有命中缓存，然后查询数据库，这时候读取的是旧值，并把查询到的旧值保存到缓存中，接着线程A完成了数据库的更新，这时候数据库和缓存又出现了不一致的情况，解决方案：我们只要再线程A，完成数据库的更新之后，稍作延迟再删除一次缓存，也叫作延迟双删。这里的延迟时间一定要大于业务的一次读操作的时间。

先操作数据库，再删除缓存

再高并发的情况下，也会有不一致的情况，比如线程A做读取数据的操作，正准备写入缓存的时候，线程B更新了数据库，然后执行了删除缓存的操作，这时候线程A才把旧值写入到缓存中，虽然这种情况出现的概率比较低，因为写操作的时候要大于一次读操作的时间的。解决方案：延迟双删，延时双删还是有问题的，如果删除缓存失败怎么办，当然是再次删除，不断的循环删除。删除失败后我们可以将要删除的key放入到队列中，然后尝试重复删除，直到删除成功。

这个方案是比较推荐的，但是还有一定的问题

提供一个方案

首先针对延迟双删，以及缓存失败的重试机制，都会导致非业务代码的入侵，这样非常的不友好，这里可以把key的淘汰机制独立出来，采用binlog增量异步处理机制，将binlog通过kafka或其他的MQ发送给消费者，消费者读取到增量信息来维护对应的key。这里推荐一个阿里的组件Canal，有兴趣的同学可以了解一下