双写一致性
- 双写一致性
- 解决方案
- 延迟双删(有脏数据的风险)
- 分布式锁(强一致性,性能比较低)
- 异步通知(保证数据的最终一致性,高并发情况下会出现短暂的不一致情况)
双写一致性
当修改了数据库的数据也要同时更新缓存的数据,缓存和数据库的数据要保持一致
解决方案
延迟双删(有脏数据的风险)
延迟双删很多人应该也知道这个方案,具体的步骤呢就是先删除缓存然后修改数据库延迟一段时间再去一次删除缓存
先删除缓存还是先删除数据库?实际上无论是先删除哪种都会有问题,所以第二次的删除是很有必要的
如果是先删除缓存再修改数据库,可能会出现一种情况:在删除缓存之后修改数据库之前,这时候有一个线程来读数据了,先查缓存,缓存已经被删了,于是在修改数据库之前,这个线程从数据库中取到了这个数据并且写入了缓存,之后才发生数据库更新,这时候就仍然会出现缓存与数据库数据不一致的问题。先更新数据库再删除缓存其实也是类似的问题
为什么需要延时呢?
延时的主要原因是我们实际的数据库大部分是读写分离的,我们需要将主节点的数据同步到从节点中去。
分布式锁(强一致性,性能比较低)
我们可以使用读写锁来保证数据的一致性,下面记录一下具体的一个用法
异步通知(保证数据的最终一致性,高并发情况下会出现短暂的不一致情况)
基于MQ
基于Canal