秒杀项目中保证redis和mysql一致性的方案

秒杀项目中保证redis和mysql一致性的方案

参考：https://blog..net/weixin_45480785/article/details/118253615 https://www.zhihu.com/question/23401553

首先分为三种一致性：

强一致性： 完全的一致，数据库里是什么，redis就是什么

弱一致性： 数据库和redis存在不一致的情况

最终一致性： 某些时刻是弱一致但是最终会保证完全的强一致

方案一:

读的时候先读缓存，缓存没有再读数据库。

写的时候先修改数据库，在后再删除缓存。

方案二：

写的时候只更新缓存，不更新数据库，通过异步的方式来更新数据库。

项目采用的方案：

读的时候先读缓存，缓存没有再读数据库。

写的时候先更新缓存，再异步修改数据库，修改成功删除缓存。

问题1：为何是删除缓存不是更新缓存

更新缓存存在脏数据的问题。

假设两个线程A和B

线程A先更新了数据库，然后线程B再更新数据库。

但是由于网络原因，线程B先于线程A更新缓存，线程A将旧的数据更新到缓存中，从而出错。

问题2：为何是先更新缓存再操作数据库

假设一个下单的场景

A用缓存中的库存判断发现库存足够，进入数据库完成库存扣减下单操作，这是B来了又判断，发现缓存中库存也足够进入数据库完成库存扣减下单操作，但是A扣减完库存后库存不足了，这就导致了B扣减失败。

问题3：为何不先删除库存再操作数据库。

假设另外一个场景A写数据，B读数据

A发起一个写操作，将库存删除

此时B读取数据库相关信息，发现没有缓存进数据库读取，保存缓存

这个时候A再修改数据库，最后缓存中保存的还是老的数据。

保证最终一致性方案：

1.采用延迟双删策略

先删除缓存

再写数据

休眠一段时间（读业务时间+redis和数据库主从同步的耗时）

再删缓存

缺点：休眠时间难以把控，请求耗费时间长

2.删除重试机制

以上方案建立在删缓存成功的情况，如果删除失败

写请求更新数据库

由于某些原因缓存删除失败

把失败的key放在消息队列里面

消费消息队列的消息，获取要删的key

重试删除缓存

缺点：会造成大量业务代码入侵

3.读取biglog异步更新缓存

通过数据库的binlog来异步淘汰key

MySQL中产生了新的写入、更新、删除等操作，就可以把binlog相关的消息推送至Redis，Redis再根据binlog中的记录，对Redis进行更新。