Redis双写一致性

文章目录

Redis双写一致性
[1. 延迟双删（有脏数据风险）](#1. 延迟双删（有脏数据风险）)
[2. 异步通知（保证数据最终一致性）](#2. 异步通知（保证数据最终一致性）)
[3. 分布式锁（数据的强一致，性能低）](#3. 分布式锁（数据的强一致，性能低）)

Redis双写一致性

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

1. 延迟双删（有脏数据风险）

先删缓存，还是先删数据库？
无论先删缓存还是先删数据库，在多线程情况下都可能导致缓存脏数据的可能。
延迟双删（有脏数据风险）

读操作：缓存命中，直接返回；缓存未命中查询数据库，写入缓存，设定超时时间
写操作：延迟双删
删除两次缓存，是为了减少缓存脏数据的可能性 。
存在的问题：延迟的时间不好控制

2. 异步通知（保证数据最终一致性）

基于MQ异步通知
基于Canal异步通知

二进制日志（BINLOG）记录了所有DDL语句和DML语句，但不包括数据查询（select，show）语句

3. 分布式锁（数据的强一致，性能低）

在读多写少 情况下可以使用分布式锁，能保证数据的强一致性，但是性能比较低。

实现：

共享锁：读锁readLock，加锁之后，其他线程可以共享读操作（用在查询数据方法里面）

排他锁：独占锁writeLock，加锁之后，阻塞其他线程读写操作（用在更新数据方法里面）

使用Redisson来实现，对同一把锁分别使用readLock，writeLock。

java 复制代码

RReadWriteLock readWriteLock = redissonClient.getReadWriteLock("ITEM_READ_WRITE_LOCK");
//在更新数据的方法里面使用writeLock
readWriteLock.writeLock();
//在查询的方法使用readLock
readWriteLock.readLock();