【搞定面试官】系列：如何保证缓存与数据库的双写一致性

面试开始

小伙子你好，看你简历上写到了MySQL和Redis。今天我们就围绕他们两个展开吧。Redis和MySQL是后端开发中举重若轻的重要角色。实际开发中二者也基本上如影随行，为了提高性能和响应，Redis常常存放热点数据，MySQL存放所有数据，保证数据持久化。所以Redis可以说是MySQL的一部分数据。

那么问题来了，当MySQL中的持久化数据发生改变，如何通知Redis呢？也即如何保证缓存和数据库数据的双写一致性呢？

面试官您好，我们在开发中采取的方案是：先更新数据库，然后删除相应缓存，直到下次请求缓存发现没有数据，再从MySQL中读取，同时将数据更新到Redis。

那为什么采用删除缓存而不是更新缓存呢？

如下图所示，如果采取更新缓存的方式，可能出现请求A先于请求B发生，更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存，这就导致了脏数据。
在这里插入图片描述

其次，如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用更新缓存的方案就会导致数据压根还没被读取过，但缓存已被频繁的更新，浪费性能。

那先删除缓存，再更新数据库会不会有什么问题？

如下图所示，请求A进行写操作，删除缓存，请求B查询发现缓存不存在，就去数据库查询得到旧值，之后将旧值写入缓存，此时请求A再将新值写入数据库。
这种情况就会导致数据不一致的情形出现。而且，如果不采用给缓存设置过期时间策略，该缓存数据永远都是脏数据。
在这里插入图片描述

好的，刚刚说的方案确实在并发环境中都会有问题。那你们采用先更新数据库，再删除缓存，这种方案一定不会出现并发问题吗？

答案是不一定，也可能会出现并发问题。如下图所示，
当步骤Step3的更新数据库操作比步骤Step2的读取数据库操作耗时更短，就有可能使得步骤Step4先于步骤Step5，此时缓存中的就是脏数据。但一般情况下数据库的读操作的速度是远快于写操作的（此点从MySQL的并发读写量就可看出，相同硬件配置下并发读的效率是并发写的数倍）。
在这里插入图片描述

因此，如果你想实现基础的缓存和数据库双写一致的逻辑，那么在大多数情况下，在不想做过多设计、增加太大工作量的情况下，请先更新数据库，再删除缓存!

先更新数据库，再删除缓存，除了你刚刚说得问题，还会有别的问题吗？

如果MySQL采用了读写分离架构，当请求A更新数据在master库上并删除了缓存，但此时数据库主从同步还未完成。请求B查询缓存发生Cache miss之后从slave库上读取到的还是旧值，此时也会造成数据不一致。
在这里插入图片描述

你刚刚说到先更新数据库，再删除缓存也有可能造成数据不一致，怎么解决呢？

采用延时双删。如下图所示，请求A更新数据库之后，为防止删除缓存先行发生于请求B的将缓存写入旧值，可以通过将请求A更新完数据库之后休眠一会（例如100ms,200ms，根据实际业务场景拟定），再删除缓存，这样基本能保证缓存中存放的不会是脏数据。主从架构也是这个原理，就是请求A在更新master之后不用立即删除缓存，通过延时双删保证主从同步已经完成，最后删除缓存数据。
在这里插入图片描述