Redis之缓存一致性

Redis之缓存一致性

  • 1 缓存更新策略
    • 1.1 内存淘汰
    • 1.2 过期删除
    • 1.3 主动更新
    • 1.4 三种缓存更新策略的对比
  • 2 更新缓存的两种方式
  • 3 缓存更新策略的实现方式
    • 3.1 先更新DB,后更新缓存
    • 3.2 先更新DB,后删除缓存
    • 3.3 先更新缓存,后更新DB
    • 3.4 先删除缓存,后更新DB
    • 3.5 延迟双删
    • 3.6 异步删除缓存
      • 3.6.1 基于消息队列的异步删除缓存
      • 3.6.2 基于MySQL的bin log+消息队列删除缓存
      • 3.6.3 异步删除缓存的优缺点
      • 3.6.4 基于 阿里canal实现
    • 3.7 几种实现方式的对比

1 缓存更新策略

按照缓存更新的方式大致分为: 内存淘汰、过期删除、主动更新。

1.1 内存淘汰

利用Redis的内存淘汰策略,当内存不足时自动进行淘汰部分数据,下次查询时更新缓存,一致性差,无维护成本。

因为Redis是基于内存的,如果内存超过限定值(Redis配置文件的maxmemory参数决定Redis最大内存使用量),导致新的数据存不进去,此时Redis会根据淘汰策略删除一些数据。

淘汰策略由Redis配置文件的maxmemory-policy参数决定设置,默认为noeviction模式。

淘汰策略的执行过程

  • 执行写请求时,Redis会检查内存使用情况,内存使用超过限定值,按照淘汰策略删除key
  • Redis写入新数据。

具体的淘汰策略redis.windows-service.conf中可以查到

  1. noeviction:默认策略,当写入新数据后的内存超过限定值时,写请求直接返回错误,只读请求可以正常执行。
  2. allkeys-lru:当写入新数据后的内存超过限定值时,从所有key中使用LRU算法(最近最少使用算法)淘汰最久没有使用过的key
  3. volatile-lru:当写入新数据后的内存超过限定值时,从设置了过期时间的key中使用LRU算法淘汰最久没有使用过的key
  4. allkeys-random:当写入新数据后的内存超过限定值时,从所有key中随机淘汰key
  5. volatile-random:当写入新数据后的内存超过限定值时,从设置了过期时间的key中随机淘汰key
  6. volatile-ttl:当写入新数据后的内存超过限定值时,从设置了过期时间的key中根据过期时间淘汰key,越快过期越早淘汰。
  7. allkeys-lfu:当写入新数据后的内存超过限定值时,从所有key中使用LFU算法(最少频率访问算法)淘汰使用频率最低的key
  8. volatile-lfu:当写入新数据后的内存超过限定值时,从设置了过期时间的key中使用LFU算法淘汰使用频率最低的key

1.2 过期删除

缓存添加过期时间,到期后根据过期删除策略自动进行删除缓存,下次查询时更新缓存,一致性一般,维护成本低。

  1. 定时删除key设置了过期时间,一旦过期立即删除。
    • 优点:key一旦过期就会立即删除,不会占用内存。
    • 缺点:过期key较多时,删除key会占用CPU时间,影响服务器的响应时间,吞吐量,性能。
  2. 惰性删除:过期key不会马上被删除,而是继续保存在内存中,当key被访问时检查key的过期时间,若已过期则删除。
    • 优点:只在访问时才会对检查key的过期时间,没使用的key不会占用CPU的时间去检查过期时间,不会影响服务器的响应时间,吞吐量,性能。
    • 缺点:没有被访问的过期key继续保存在内存中,导致内存不会被释放,消耗内存资源。
  3. 定期删除:每隔一段时间(时间可以自行设置,Redis配置文件的hz参数表示1s执行多少次定期删除策略,默认值10),随机抽取设置了过期时间的key检查它们的过期时间,删除已过期的key
    • 优点:可以指定频率来减少删除操作对CPU性能的影响,定期删除也能释放没有被访问的过期key占用的内存。
    • 缺点:频率高影响CPU的性能,频率低过期key占用的内存不会及时释放。

1.3 主动更新

应用程序中修改DB,修改缓存,一致性好,维护成本高。

主动更新大致分为: Cache Aside PatternRead/Write Through PatternWrite Behind Caching Pattern

  1. Cache Aside Pattern:即旁路缓存模式,旁路路由策略,最经典常用的缓存策略。由应用程序负责缓存和DB的读写。读写操作步骤:
    • 读操作时,先读缓存,缓存存在直接返回;缓存不存在则读DB,然后把读的DB数据存入缓存,返回。
    • 写操作时,先更新DB,再删除缓存。
  2. Read/Write Through Pattern:即读写穿透模式,该模式下应用程序只与缓存管理组件交互,缓存管理组件负责缓存和DB的读写。
    • Read Through:读操作时,缓存管理组件先读缓存,缓存存在直接返回;缓存不存在则读DB,然后把读的DB数据存入缓存,返回。
    • Write Through:写操作时,缓存管理组件同步更数DB和缓存。
  3. Write Behind Caching Pattern:即异步缓存写入,该模式下应用程序只与缓存管理组件交互操作,缓存管理组件负责缓存和DB的读写,通过定时或阈值的异步方式将数据同步到DB,保证最终一致。该模式和Read/Write模式相似,不同点在于Read/Write模式更新DB和更新缓存是同步的,而Write Behind Caching Pattern模式更新DB和更新缓存是异步的。
    • 优点:减少了更新DB的频率,读写响应非常快,吞吐量也会有明显的提升。
    • 缺点:不能实时同步,数据同步DB过程服务不可用,导致数据丢失。

三种主动更新策略的对比

策略 说明 优点 缺点
Cache Aside Pattern 应用程序负责缓存和DB的读写 使用简单,直接操作缓存和DB 需要编写对缓存和DB读写的代码
Read/Write Through Pattern 应用程序只与缓存管理组件交互,缓存管理组件负责缓存和DB的读写 使代码更简洁 缓存管理组件需要提供对DB和缓存读写的方法
Write Behind Caching Pattern 应用程序只与缓存管理组件交互,缓存管理组件负责缓存和DB的读写 性能最好,在高并发场景下可以降低数据库的压力 缓存管理组件,需要提供对DB和缓存读写的方法;
不能实时同步,数据同步DB过程DB不可用,导致数据丢失;
一致性不强,对一致性要求高的系统不适用

1.4 三种缓存更新策略的对比

策略 说明 一致性 维护成本
内存淘汰 使用Redis的内存淘汰策略,当内存不足时自动进行淘汰部分数据,下次查询时更新缓存
过期删除 缓存添加过期时间,到期后根据过期删除策略自动进行删除缓存,下次查询时进行更新缓存
主动更新 修改数据库时也修改缓存,使用硬编码方式或者硬编码+中间件方式在修改数据库时同步或异步的修改缓存

2 更新缓存的两种方式

  1. 删除缓存:更新DB时删除缓存,查询时再从DB中读取数据并更新到缓存。
  2. 更新缓存:更新DB时更新缓存,频繁更新缓存开销大,且并发时可能导致请求读取的缓存数据是旧数据。

3 缓存更新策略的实现方式

3.1 先更新DB,后更新缓存

1 并发写场景
所有线程都是先更新DB再更新缓存,在某个写线程更新DB后继续更新缓存时,可能因为网络原因出现延迟,这时其他写线程也更新了DB和缓存,导致缓存和DB数据不一致。

具体步骤:

  1. 线程1更新DB
  2. 线程2更新DB
  3. 线程2更新缓存
  4. 线程1更新缓存

总结
理论上先更新DB的线程理应也会先更新缓存,但是并发场景下线程的执行顺序无法保证:

  • 若更新缓存的顺序是: 先线程1再线程2,则不会出现数据不一致问题。
  • 若更新缓存的顺序是: 先线程2再线程1,此时缓存是线程1的数据,DB是线程2的数据,导致缓存和DB数据不一致。

2 并发读写场景
在写线程更新DB和更新缓存之间,读线程可以获取到旧数据,但最终会一致。
具体步骤:

  1. 线程1更新DB
  2. 线程2查询,命中缓存返回
  3. 线程1更新缓存

总结
线程2获取的缓存是旧数据,但最终都会一致。

3.2 先更新DB,后删除缓存

1 并发写场景
所有线程都是先更新DB再删除缓存,无论哪个线程先更新DB再删除缓存,缓存都会被删除,不会导致缓存和DB数据不一致。

具体步骤:

  1. 线程1更新DB
  2. 线程2更新DB
  3. 线程2删除缓存
  4. 线程1删除缓存

总结
无论哪个线程先更新DB再删除缓存,缓存都会被删除,不会导致缓存和DB数据不一致。


2 并发读写场景
在写线程更新DB再删除缓存之间,读线程可以获取到旧数据,但最终会一致。

具体步骤:

  1. 线程1更新DB
  2. 线程2查询命中缓存返回
  3. 线程1删除缓存

总结
线程2获取的缓存是旧数据,但后续最终都会一致。

3.3 先更新缓存,后更新DB

1 并发写场景
所有线程都是先更新缓存再更新DB,在某个写线程更新缓存和更新DB之间,其他写线程也更新了缓存和DB,导致缓存和DB数据不一致。

具体步骤:

  1. 线程1更新缓存
  2. 线程2更新缓存
  3. 线程2更新DB
  4. 线程1更新DB

总结:理论上先更新缓存的线程也会先更新DB,但是并发场景下线程的执行顺序无法保证:

  • 若更新DB的顺序是: 线程1再线程2,则不会出现数据不一致问题。
  • 若更新DB的顺序是: 线程2再线程1,此时缓存是线程2的数据,DB是线程1的数据,导致缓存和DB数据不一致。

2 并发读写场景
在写线程更新缓存和更新DB之间,读线程也可以获取到最新的缓存,不会导致缓存和DB数据不一致。

具体步骤:

  1. 线程1更新缓存
  2. 线程2查询,命中缓存返回
  3. 线程1更新DB

总结
可以保证缓存和DB数据一致,虽然线程1更新DB的操作还没有完成,但是更新缓存的操作已经完成了,读请求可以获取到最新的缓存。

3.4 先删除缓存,后更新DB

1 并发写场景
所有线程都是先删除缓存再更新DB,无论哪个线程先删除缓存再更新DB,缓存都会被删除,不会导致缓存和DB数据不一致。

具体步骤:

  1. 线程1删除缓存
  2. 线程2删除缓存
  3. 线程2更新DB
  4. 线程1更新DB

总结
无论哪个线程先删除缓存再更新DB,缓存都会被删除,不会导致缓存和DB数据不一致。


2 并发读写场景
在写线程删除缓存和更新DB之间,读线程根据查询的DB结果更新了缓存,导致缓存和DB数据不一致。

具体步骤:

  1. 线程1删除缓存
  2. 线程2查询,未命中
  3. 线程2查询DB
  4. 线程2根据查询的DB结果更新缓存
  5. 线程1更新DB

总结:
线程1删除缓存和更新DB之间,线程2根据查询的DB结果更新了缓存,导致缓存和DB数据不一致。

3.5 延迟双删

因为3.4 先删除缓存,再更新DB,在并发读写场景会导致数据不一致。
延迟双删是基于先删除缓存再更新DB的基础上的改进,在更新DB后延迟一定时间,再次删除缓存。

延迟是为了保证第二次删除缓存前能完成更新DB操作,延迟时间根据系统的查询性能而定。
第二次删除缓存是为了保证后续请求查询DB(此时数据库中的数据已是更新后的数据),重新写入缓存,保证数据一致性。

1 并发写场景
无论哪个线程都会删除缓存,所以不会导致缓存和DB数据不一致。

具体步骤:

  1. 线程1删除缓存
  2. 线程2删除缓存
  3. 线程2更新DB
  4. 线程1更新DB
  5. 线程1延时删除缓存
  6. 线程2延时删除缓存

2 并发读写场景
具体步骤:

  1. 线程1删除缓存
  2. 线程2查询,未命中
  3. 线程2查询DB
  4. 线程2根据查询的DB结果更新缓存
  5. 线程1更新DB
  6. 线程1延时删除缓存

总结:
线程1第一次删除缓存之后,线程2根据查询的DB结果更新缓存,此时查询得到的结果是旧数据,线程1延迟第二次删除缓存之后,后续查询DB(此时数据库中的数据已是更新后的数据),重新写入缓存,不会导致缓存和DB数据不一致。


3 延时双删的缺点:

  1. 需要延时,低延时场景不合适,如秒杀等需要低延时,需要强一致,高频繁修改数据场景。
  2. 不能保证强一致性,在更新DB之前,查询线程查询得到的结果是旧数据,可但可以减轻缓存和DB数据不一致的问题。
  3. 延时的时间是一个不可评估的值,延时越久,能规避一致性的概率越大。

3.6 异步删除缓存

因为3.2 先更新DB,后删除缓存 在并发写场景不会导致数据不一致,但是在并发读写场景会短暂的导致数据不一致,但是由于删除缓存失败不会重试,并发写场景、并发读写场景都可能长时间导致数据不一致。

异步删除缓存是对先更新DB,后删除缓存的改进:更新DB之后,基于消费队列异步删除缓存。

根据消费队列不同大致分为:消息队列、bin log+消息队列。

3.6.1 基于消息队列的异步删除缓存

1 并发写场景
无论哪个线程先更新DB再删除缓存,缓存都会被删除,不会导致缓存和DB数据不一致。

具体步骤:

  1. 线程1更新DB
  2. 线程2更新DB
  3. 线程2把删除缓存放入消息队列
  4. 线程1把删除缓存放入消息队列
  5. 异步:消息队列消费删除缓存

总结:
无论哪个线程先更新DB再删除缓存,缓存都会被删除,不会导致缓存和DB数据不一致。

2 并发读写场景
异步删除缓存期间,读线程获取的缓存是旧数据,短暂出现数据不一致,异步删除缓存后最终会一致。

具体步骤:

  1. 线程1更新DB
  2. 线程2查询缓存,命中返回
  3. 线程1把删除缓存放入消息队列
  4. 异步:消息队列消费删除缓存

总结:
异步删除缓存期间,读线程获取的缓存是旧数据,短暂出现数据不一致,异步删除缓存后最终会一致。

3.6.2 基于MySQL的bin log+消息队列删除缓存

1 并发写场景

具体步骤:

  1. 线程1更新DB
  2. 线程2更新DB
  3. 异步:bin log日志收集中间件定时收集DBbin log日志
  4. 异步:bin log日志收集中间件发送日志消息到消息队列
  5. 异步:消息队列消费删除缓存

总结:
无论哪个线程先更新DB再删除缓存,缓存都会被删除,不会导致缓存和DB数据不一致。


2 并发读写场景
具体步骤:

  1. 线程1更新DB
  2. 线程2查询缓存,命中返回
  3. 异步:bin log日志收集中间件定时收集DBbin log日志
  4. 异步:bin log日志收集中间件发送日志消息到消息队列
  5. 异步:消息队列消费删除缓存

总结:
异步删除缓存期间,读线程获取的缓存是旧数据,短暂出现数据不一致,异步删除缓存后最终会一致。

3.6.3 异步删除缓存的优缺点

优点:

  1. 删除缓存的操作与主流程代码解耦。
  2. 中间件自带重试机制,增加了操作缓存的成功率。

缺点:
引入中间件,提升了系统的复杂度,在高并发场景可能会产生性能问题。

3.6.4 基于 阿里canal实现

canal是阿里开发的基于数据库增量日志解析,提供增量数据的订阅和消费,目前主要支持MySQLbin log解析。基于canal的实现方案完全避免了对业务代码的侵入,核心业务代码只管更新数据库,其他的不用care

canal地址:https://github.com/alibaba/canal

MySQL会将操作记录在bin log日志中,通过canal去监听数据库日志二进制文件,解析bin log日志,同步到Redis中进行增删改操作。

canal的工作原理:canal是模拟MySQL slave的交互协议,伪装自己为MySQL slave,向MySQL master发送dump协议;MySQL master收到dump请求,开始推送bin logslave (即canal);canal解析bin log象(原始为byte流)。
Redis之缓存一致性_第1张图片

3.7 几种实现方式的对比

参看:redis之缓存一致性 最后一部分

你可能感兴趣的:(redis,redis)