Redis进阶：持久化机制、缓存DB一致性、缓存隐患、分布式锁 ...

目次

Redis进阶
Redis的持久化机制
Redis持久化⽅式：
过期数据删除策略
redis作为缓存的三个隐患
布隆过滤器：
怎样包管缓存和数据库数据的一致性？
耽误双删策略：
Redis分布式锁：
Redisson 提供的分布式锁：
看门狗机制
RedLock

---

Redis进阶

Redis的持久化机制

Redis是⼀个基于内存的数据库，它的数据是存放在内存中，内存有个问题就是关闭服务大概断电会丢失。Redis的数据也⽀持写到硬盘中，这个过程就叫做持久化。
Redis持久化⽅式：

• RDB（Redis DataBase） ：在指定的时间隔断内，定时的将 redis 存储的数据⽣成Snapshot快照并存储到磁盘等介质上；
• AOF（Append Of File） ：将 redis 执⾏过的全部写指令记录下来，在下次 redis 重新启动时，只要把这些写指令从前到后再重复执⾏⼀遍，就可以实现数据恢复了。
• AOF+RDB ： RDB 和 AOF 两种⽅式也可以同时使⽤，在这种情况下，如果 redis 重启的话，则会优先采⽤ AOF ⽅式来进⾏数据恢复，这是因为 AOF ⽅式的数据恢复完整度更⾼
对比：
rdb体积小，恢复速率快，但是大概会丢数据
aof持久化方式丢失数据的风险更小，数据完整性更好，但是性能差，文件比较大，恢复速率慢
rdb存储的是效果，aof存储的是操纵
aof是基于内存中的数据进行重写的，重写的时间会把那些汗青的无用下令都扫撤消，只根据当前一刻内存的数据的终极下令进行重写
使用场景：
对数据（一致性）要求不很高的情况下，可以使用rdb；
aof性能较差，实用于对数据（一致性）要求比较高的情况；
而aof+rdb的情况就团体效果比较抱负。
过期数据删除策略

给redis的数据设置了定期时间，如果存储满了，怎样删除？
常用的过期数据的删除策略就两个（紧张！本身造缓存轮子的时间需要格外考虑的东西）：

• 惰性删除 ：只会在取出key的时间才对数据进行过期检查。如许对CPU最友好，但是大概会造成太多过期 key 没有被删除。
  
• 定期删除 ： 每隔一段时间抽取一批 key 执行删除过期key操纵。并且，Redis 底层会通过限制删除操纵执行的时长和频率来减少删除操纵对CPU时间的影响。
  

定期删除对内存更加友好，惰性删除对CPU更加友好。两者各有千秋，以是Redis 接纳的是 定期删除+惰性/懒汉式删除 。

redis作为缓存的三个隐患

缓存雪崩：缓存中⼤量key同时失效，导致流量请求到db中，造成db负载压⼒过⼤挂掉，这种情况叫做缓存雪崩。
解决方法：

缓存穿透：⼤量请求同时访问⼀个不存在的key，导致流量⾛到db数据库。
解决方案：添加⼀个默认值null，可以使⽤布隆过滤器判断是不是存在
缓存击穿：⼤量请求同时访问⼀个过期的key，导致流量⾛到db。
解决方案：加分布式锁避免
布隆过滤器：

布隆过滤器是一个非常神奇的数据布局，通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。我们需要的就是判断 key 是否合法。
具体做法：把全部大概存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。

布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。

怎样包管缓存和数据库数据的一致性？

耽误双删策略：

根本步骤：

• 更新数据库；
  
• 将缓存里对应的数据标志为失效或设置一个过期标志；
  
• ‌设定耽误期‌，在耽误期间，允许应用步伐从缓存中读取已经标志为失效的数据。（这个耽误期是为了确保在这个时间段内，即使缓存数据失效，应用步伐仍然可以读取缓存数据，从而减少数据库的压力。）
  
• ‌当耽误期过后，进行双删操纵：
  

第一次删除：首先检查缓存中的数据是否被标志为失效。如果数据被标志为失效，第一次删除操纵将尽快地从缓存中移除这些失效数据。
第二次删除：是为了确保全部的副本都被扫除。在某些分布式缓存系统中，数据大概有多个副本，第一次删除大概没有移除全部的副本。第二次删除是一个保险措施，确保全部的失效数据都被扫除。
相关问题：

Redis分布式锁：

为解决超卖问题，JVM级别的本地锁不实用于两台呆板部署的业务，要让这两台呆板用同一把锁，即分布式锁。
超卖问题：多个用户同时购买同一限量商品时，出售量大于实际库存数量。
分布式锁的深度解析和全面临比_哔哩哔哩_bilibili
Redisson 提供的分布式锁：

看门狗机制

1.为什么需要看门狗机制?
所谓看门狗机制，实在就是分布式锁的自动续期功能。如果持有当前分布式锁的应用步伐节点突然宕机，且当前分布式锁又处于未解锁的状态，此时就会出现死锁的问题！以是，一般情况下，我们都会给分布式锁设置一个过期时间。那么，问题来了，分布式锁的过期时间设置多少比较符合呢?
如果当前持有锁的线程在过期时间内没有执行完成，就会出现分布式锁提前过期的情况从而导致分布式锁出现问题!而如果当前持有锁的线程在过期时间内提前完成，又会影响性能。为此，Redisson 为我们提供了一套分布式锁的自动续期功能的看门狗机制。
2.Redisson 的看门狗机制是怎么实现的?
默认情况下，Redisson 分布式锁有用期时间为 30 秒，并且它会每 10 秒钟去校验一次当前持有锁的线程是否执行结束，如果未执行完毕，则会重新给当前锁续期 30 秒;否则就会取消续期。
当然，我们是可以通过指定 lockWatchdogTimeout 参数来自界说看门狗的续期时间的。另外，如果想要触发看门狗机制的一个必要条件是 leaseTime
RedLock

【Java口试】说说RedLock_哔哩哔哩_bilibili
为解决redis在集群模式下的多节点问题
计划思绪：
客户端会向 Redis 集群中多个独立的 Redis 实例节点请求加锁，如果客户端能够从半数以上的 Redis 实例节点申请加锁乐成，我们则以为客户端获取分布式锁乐成，反之，则以为获取分布式锁失败!
它可以包管以下特性：

• 安全特性：互斥访问，即永远只有一个 client 能拿到锁
  
• 避免死锁：终极 client 都大概拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了大概出现了网络分区
  
• 容错性：只要大部分 Redis 节点存活就可以正常提供服务
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

继续阅读请点击广告