双写一致性方案对比

双写一致性方案对比

结论：先写数据库，再删缓存（一致性最优解决方案）

方案：

先写 Redis，再更新 MySQL

如果mysql写入失败了怎么办？

先写 MySQL，再更新Redis

问题很明显，并发请求下，A请求（写请求）先到达Mysql，但卡了一会儿，B请求（写请求）后到达，但是处理比A快，此时最新的数据应该是B，但是由于更新redis的操作A比B晚一点儿，导致redis数据为A的数据。

先删除 Redis，再写MySQL

redis 删除后，mysql写数据库的时间内，所有的读请求都打到mysql上了

A请求（写）删除缓存后，更新mysql数据，此时B请求（读）也进入了Mysql，B先完成查询操作，回写redis,A请求完成更新，此时正常的数据应该为A数据，但redis中写的B数据。 （主要是因为，写请求比较耗时，查询请求耗时较短，出现上述问题的可能性较大）

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

经典的缓存双删问题，在上一个方案上有一些优化，让请求A等待一段时间，再删除缓存，保证蓝色的删除缓存在回写之后

• “缓存双删”不要用无脑的 sleep 500 ms；
• 通过消息队列的异步&串行，实现最后一次缓存删除；
• 缓存删除失败，增加重试机制。

先写 MySQL，再删除 Redis

可能存在的问题：当请求A更新Mysql为11后 ，回写redis之前，请求B读取到了缓存中的数据，出现不一致

也就是在A请求更新Mysql后且删除redis之前的读取请求会有不一致问题（发生概率低）

另外考虑缓存刚好失效的情况

请求A 查询缓存，缓存失效，直接查询mysql，并回写缓存，在回写缓存前，请求B更新了mysql数据，删除缓存（此时没有缓存），然后A再回写缓存。 此时数据不一致，可能持续较久。

上述需要满足两个条件 缓存刚好过期、B请求更新mysql的时间，比A请求读取mysql+回写缓存 时间还长。（条件很难达到）

总结：读写并发，缓存不失效的情况下，会出现A（写请求）删除缓存之前 读取到的数据不对，持续时间短

读写并发，缓存恰好失效，会出现B（读请求）查询mysql - [A(写请求)更新了mysql,删除过期缓存] 回写redis之间

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

主要是监听 MySQL 的 Binlog，然后通过异步的方式，将数据更新到 Redis，这种方案有个前提，查询的请求，不会回写 Redis

1、先写 MySQL，再删除 Redis

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

2、先写 MySQL，通过 Binlog，异步更新 Redis

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