直接上最优解：如何保障MySQL和Redis的数据一致性？( 二 ) _MySQL

文章插图
这个方案，会保证 MySQL 和 Redis 的最终一致性，但是如果中途请求 B 需要查询数据，如果缓存无数据，就直接查 DB；如果缓存有数据，查询的数据也会存在不一致的情况。
所以这个方案，是实现最终一致性的终极解决方案，但是不能保证实时性。
几种方案比较
我们对比上面讨论的 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，数据的一致性也可以达到秒级。
纯粹的高并发场景，不建议用这种方案，比如抢购、秒杀等。
结论

实时一致性方案：采用“先写 MySQL ，再删除 Redis”的策略，这种情况虽然也会存在两者不一致，但是需要满足的条件有点苛刻，所以是满足实时性条件下，能尽量满足一致性的最优解。
最终一致性方案：采用“先写 MySQL，通过 Binlog，异步更新 Redis”，可以通过 Binlog，结合消息队列异步更新 Redis，是最终一致性的最优解。

作者丨楼仔
来源丨公众号：楼仔（ID：gh_8de52dba3fda）