【Redis核心】使用场景：双写一致性

目录

双写一致

问题分析

先删除缓存，后修改数据库

先修改数据库，后删除缓存

解决方案

1.针对一致性要求高

2 针对允许延迟一致

---

双写一致

双写一致性：当修改了数据库的数据也要同时更新缓存的数据，缓存和数据库的数据要保持一致

• 读操作：缓存命中，直接返回；缓存未命中查询数据库，写入缓存，设定超时时间
• 写操作：延迟双删

问题分析

这里就会产生一个问题，上图步骤可以调换顺序吗？即先删除缓存，还是先修改数据库？

先删除缓存，后修改数据库

①正常情况：

②异常情况：

先修改数据库，后删除缓存

①正常情况：

②异常情况：

综上观察发现不管先删除缓存，还是先修改数据库，都会产生脏数据，所以需要删除两次缓存；由于数据库主从同步的问题，还需要延时删除。

但是延迟双删这个延迟时间不好判断；而且在延时的过程中可能会出现脏数据，并不能保证强一致性；

解决方案

1.针对一致性要求高

使用分布式锁

• 共享锁：读锁readLock,加锁之后，其他线程可以共享读操作；
• 排他锁：也叫独占锁writeLock，加锁之后，阻塞其他线程读写操作；

虽然使用读写锁，可以保证强一致性，但性能会降低。

2.针对允许延迟一致

①基于MQ的异步通知：使用MQ中间件，更新数据之后，通知缓存删除；

②基于Canal的异步通知：利用canal中间件，不需要修改业务代码，伪装为mysql的一个从节点，canal通过读取binlog数据更新缓存；

二进制日志（BINLOG）记录了所有的 DDL（数据定义语言）语句和 DML（数据操纵语言）语句，但不包括数据查询（SELECT、SHOW）语句。