Redis知识体系架构（二）

痛定思痛。 2022-11-05 13:59 114阅读 0赞

### ⭐Redis ###

*  四、过期数据的删除策略
 *   *  1、设置过期时间
     *  2、策略
 *  五、⭐Redis 内存淘汰机制
 *  六、⭐Redis持久化机制
 *  七、⭐缓存击穿与缓存雪崩
 *   *  1、缓存击穿
     *  2、缓存雪崩
 *  八、保证缓存与数据库的一致性
 *  九、分布式锁（RedLock）
 *  十、分布式集群应用场景（主从+哨兵）

# 四、过期数据的删除策略 #

## 1、设置过期时间 ##

*  设置过期时间的**原因**：我们的内存是有限的，如果一直存放的，尽管它能存到磁盘上，但是这些都是又边界的，如果一直存放，那么最终必会导致系统宕机（OOM）
 *  过期时间有助于**缓解内存的消耗**
 *  业务场景：短信验证码（比如说一分钟内有效），用户的token
 *  Redis 通过一个叫做**过期字典**（可以看作是hash表）来保存数据过期的时间

## 2、策略 ##

上面设置了过期时间，那么如何对这些过期的数据进行删除呢？

*  **惰性删除**
    
     *  在根据key进行读数据的时候进行检查，看看是否过期；对CPU友好，但是如果有大量的该删除数据未删除对内存是很崩溃的。
 *  **定期删除**
    
     *  每隔一段时间抽取一批 key 执行删除过期 key 的操作。对内存很友好，但是过长频率的操作可能会对CPU带来很大的影响，所以Redis通过限制删除操作的执行时长和频率来减少对CPU消耗的影响。
 *  Redis 采用的是 **定期删除+惰性删除**

# 五、⭐Redis 内存淘汰机制 #

> 我们通过定期删除和惰性删除，还有可能会漏掉大量过期的key未删除的情况，导致内存堆积大量无用的key。所以我们引入了淘汰机制来解决这个问题。

Redis 提供 6 种数据淘汰策略：

*  **volatile-lru**（least recently used）：从已设置过期时间的数据集里面挑选出**最近最少使用的数据**进行淘汰
 *  **volatile-ttl**：从已经设置过期时间的数据集里面挑选出**将要过期的数据**淘汰
 *  **volatile-random**：从已设置过期时间的数据集里面选择**任意的数据**进行淘汰
 *  ⭐（常用）**allkeys-lru**（least recently used）：**当内存不足以容纳新写入的数据的时候，移除最近最少使用的key**
 *  **allkeys-random**：从数据集里面任意选择数据进行淘汰
 *  **no-eviction**：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。（最少使用）

Redis 4又引入了两种淘汰机制：

*  **volatile-lfu**：从已设置过期时间的数据集中挑选**最不经常使用的数据**淘汰
 *  **allkeys-lfu**：**当内存不足以容纳新写入数据时，移除最不经常使用的 key**

# 六、⭐Redis持久化机制 #

> **保证 Redis 挂掉之后再重启数据可以进行恢复**  
> Redis支持两种不同的持久化操作：**RDB（快照）** 和 **AOF（追加文件）**

*  （**默认**）**RDB**
    
     *  通过创建快照来获得存储在内存里面的数据在**某个时间点上的副本**。在指定的时间间隔内将内存中的数据集**快照写入磁盘**，恢复时是将快照文件直接读到内存里。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能）。
     *  **快照持久化是 Redis 默认采用的持久化方式**
 *  （主流）**AOF**
    
     *  AOF 持久化的**实时性更好**
     *  每执行一条会更改Redis数据的命令，Redis就会将该命令写入磁盘中的AOF文件中。Redis启动之初会读取该文件重新构建数据。也就是说Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
     *  为了兼顾数据和写入性能，用户可以让 Redis **每秒同步一次 AOF 文件**（如果是每次修改发生时都会写入AOF文件，那么会严重降低Redis的速度），Redis 性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。

# 七、⭐缓存击穿与缓存雪崩 #

## 1、缓存击穿 ##

*  什么是缓存击穿
    
     *  就是说大量的key根本不存在于缓存中，导致大量的请求打到了数据库上，导致数据库崩溃。
 *  解决办法
    
     *  （治标不治本）**缓存无效key**：就是说如果缓存和数据库都查不到，那么久生成一个key，并设置过期时间写入到Redis里面。如果有大量无效的请求，那么会导致 Redis 中缓存大量无效的 key。
     *  **布隆过滤器**：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。  
        PS：盗用大神一张图（假装看不见，哈哈哈）：![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0OTIyMTEz_size_16_color_FFFFFF_t_70]
        
         *  使用布隆过滤器可能会**小概率的误判**（因为他是根据哈希进行存值，又是根据hash来判断此值是否存在，那么这就有一个问题，我们在核心卷1中知道不同的字符串，他们的hash值有可能是会相同的，所以会带来小概率的误判情况）

## 2、缓存雪崩 ##

*  什么是缓存雪崩
    
     *  就是大量的key同时失效，那么大量的请求过来以后，发现对应的key失效，那就回造成数据库短时间内承受大量的请求，搞崩数据库。称为 **缓存雪崩** 。
     *  一种场景就是：有一些被大量访问数据（热点缓存）在某一时刻大面积失效，导致对应的请求直接落到了数据库上。
 *  解决办法
    
     *  如果Redis不可用的话，我们可以尝试搭建集群来解决不可用的情况
     *  针对缓存失效，我们可以给缓存设置不同的失效时间。
     *  针对缓存失效，暴力的解决办法就是设置缓存不失效（不推荐）

# 八、保证缓存与数据库的一致性 #

三种读写策略

*  ⭐（常见） **Cache Aside Pattern（旁路缓存模式）**
    
     *  大体思路就是**先更新数据库，再删除缓存** 。
     *  **抛出问题**：有一个问题就是**DB更新成功，但是缓存删除失败**
        
         *  **增加cache更新重试机制（常用）** ： 如果 cache 服务当前不可用导致缓存删除失败的话，我们就隔一段时间进行重试，重试次数可以自己定。
         *  **缓存失效时间变短**（不推荐）
 *  **Read/Write Through Pattern（读写穿透）**
    
     *  同步更新 cache 和 DB
 *  **Write Behind Pattern（异步缓存写入）**
    
     *  只更新缓存，不直接更新 DB，而是改为异步批量的方式来更新 DB

# 九、分布式锁（RedLock） #

> 基于 Redis 实现分布式锁的方式名叫 *Redlock*

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

# 十、分布式集群应用场景（主从+哨兵） #

[详解Centos7 安装redis集群哨兵模式][Centos7 _redis]

（PS：又是盗图的一刻）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0OTIyMTEz_size_16_color_FFFFFF_t_70 1]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0OTIyMTEz_size_16_color_FFFFFF_t_70]: /images/20221023/15d1631b99b04a92be39934441dd9be0.png
[Centos7 _redis]: https://blog.csdn.net/qq_44922113/article/details/105125175
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQ0OTIyMTEz_size_16_color_FFFFFF_t_70 1]: /images/20221023/8ecb4059c221413f8269133907629576.png