首先分为三种一致性:
强一致性: 完全的一致,数据库里是什么,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进行更新。