Mysql和Redis数据一致性

什么是数据库与缓存一致性

• 数据一致性指的是：缓存的数据值 = 数据库中的值
  
  

为什么会出现数据一致性问题呢？

• 在高并发的业务场景下，数据库大多数情况都是用户并发访问最薄弱的环节。
• 所以，就需要使用redis做一个缓冲操作，让请求先访问到redis，而不是直接访问MySQL等数据库。
• 读取缓存步骤一般没有什么问题，但是一旦涉及到数据更新：数据库和缓存更新，就容易出现缓存(Redis)和数据库（MySQL）间的数据一致性问题。
  
  

解决数据一致性问题的常见方案

下面详细介绍

1. 先更新Mysql，再更新Redis

图解说明：

• 这是一副时序图，描述请求的先后调用顺序；
• 橘黄色的线是请求 A，黑色的线是请求 B；
• 橘黄色的文字，是 MySQL 和 Redis 最终不一致的数据；
• 数据是从 10 更新为 11，但是Redis中的数据还是10；
• 后面所有的图，都是这个含义，不再赘述。

请求 A、B 都是先写 MySQL，然后再写 Redis，在高并发情况下，如果请求 A 在写 Redis 时卡了一会，请求 B 已经依次完成数据的更新，就会出现图中的问题。

2. 先更新Redis，再更新Mysql

同“先写 MySQL，再写 Redis”，看图可秒懂。

3. 先删除Redis，再更新Mysql

请求 A 先删除缓存，可能因为卡顿，数据一直没有更新到 MySQL，导致两者数据不一致。这种情况出现的概率比较大，因为请求 A 更新 MySQL 可能耗时会比较长，而请求 B 的前两步都是查询，会非常快。

4. 先删除Redis，再更新Mysql，再删Redis

对于“先删除 Redis，再写 MySQL”，如果要解决最后的不一致问题，其实再对 Redis 重新删除即可，这个也是大家常说的“延迟双删”，不过最后一次删除Redis的时间需要评估业务逻辑执行的时间，即需要等请求B执行完毕再删除。

5. 先更新Mysql，再删Redis

对于上面这种情况，对于第一次查询，请求 B 查询的数据是 10，但是 MySQL 的数据是 11，只存在这一次不一致的情况，对于不是强一致性要求的业务，可以容忍。（那什么情况下不能容忍呢，比如秒杀业务、库存服务等。）

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

这种方案，主要是监听 MySQL 的 Binlog，然后通过异步的方式，将数据更新到 Redis，这种方案有个前提，查询的请求，不会回写 Redis，这个方案，是实现最终一致性的终极解决方案，但是不能保证实时性。

几种方案比较

1. 先更新 Redis，再更新 MySQL

   • 万一 DB 挂了，你把数据写到缓存，DB 无数据，这个是灾难性的；

2. 先更新 MySQL，再更新 Redis

   • 对于并发量、一致性要求不高的项目，很多就是这么用的，我之前也经常这么搞，但是不建议这么做；
   • 当 Redis 瞬间不可用的情况，需要报警出来，然后线下处理。

3. 先删除 Redis，再更新 MySQL

   • 高并发场景由于更新mysql使用时间较长就会产生数据不一致。

4. 先删除 Redis，再更新 MySQL，再删除 Redis

   • “延迟双删” 这种方式虽然可行，但是需要去评估业务逻辑的执行时间

5. 先更新MySQL，再删除 Redis

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

6. 先更新 MySQL，通过canal监听 Binlog，异步更新 Redis

   • 对于异地容灾、数据汇总等，建议会用这种方式，比如 binlog + kafka，数据的一致性也可以达到秒级；

个人结论

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