缓存和数据库一致性

方案介绍

我们对比上面讨论的 6 种方案：

1.先写 Redis，再写 MySQL

• 这种方案，我肯定不会用，万一 DB 挂了，你把数据写到缓存，DB 无数据，这个是灾难性的；

• 我之前也见同学这么用过，如果写 DB 失败，对 Redis 进行逆操作，那如果逆操作失败呢，是不是还要搞个重试？

2.先写 MySQL，再写 Redis

• 对于并发量、一致性要求不高的项目，很多就是这么用的，我之前也经常这么搞，但是不建议这么做；

• 当 Redis 瞬间不可用的情况，需要报警出来，然后线下处理。

3.先删除 Redis，再写 MySQL

这种方式，我还真没用过，直接忽略吧。

4.先删除 Redis，再写 MySQL，再删除 Redis

这种方式虽然可行，但是感觉好复杂，还要搞个消息队列去异步删除 Redis。

5.先写 MySQL，再删除 Redis

• 比较推荐这种方式，删除 Redis 如果失败，可以再多重试几次，否则报警出来；
• 这个方案，是实时性中最好的方案，在一些高并发场景中，推荐这种。

6.先写 MySQL，通过 Binlog，异步更新 Redis

• 对于异地容灾、数据汇总等，建议会用这种方式，比如 binlog + kafka，数据的一致性也可以达到秒级；
• 纯粹的高并发场景，不建议用这种方案，比如抢购、秒杀等。

个人结论

1.实时一致性方案：采用“先写 MySQL，再删除 Redis”的策略，这种情况虽然也会存在两者不一致，但是需要满足的条件有点苛刻，所以是满足实时性条件下，能尽量满足一致性的最优解。

2.最终一致性方案：采用“先写 MySQL，通过 Binlog，异步更新 Redis”，可以通过 Binlog，结合消息队列异步更新 Redis，是最终一致性的最优解。