文章目录
- 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();