Redis 指南(2)-重要概念

ゞ浴缸里的玫瑰 2023-10-19 08:01 91阅读 0赞

#### 文章目录 ####

*  1. Redis 的数据类型
 *   *   *  1.1 String
         *  1.2 List
         *  1.3 Set
         *  1.4 Zset
         *  1.5 Hash
 *  2. Redis 持久化机制
 *   *   *  2.1 RDB
         *   *  2.1.1 RDB持久化
             *  2.1.2 RDB持久化配置
         *  2.2 AOF
         *   *  2.2.1 AOF持久化
             *  2.2.2 AOF文件损坏问题
             *  2.2.3 AOF持久化配置
 *  3. Redis 主从复制
 *  4. Redis 哨兵机制
 *   *   *  4.1 工作原理
         *  4.2 哨兵集群选举Leader
         *  4.3 Redis 主从自动化切换
 *  5. Redis 内存淘汰策略

## 1. Redis 的数据类型 ##

Redis 是典型的 Key-Value 型存储系统,所有数据类型都以 key 作为标识,总共可分为 5种 数据类型.当设置数据时 Nx(if not exist) 参数意味着如果 key 不存在则可以设置,可以用于实现分布式锁.

#### 1.1 String ####

Redis中最基本的类型，它是key对应的一个单一值。二进制安全，不必担心由于编码等问题导致二进制数据变化。所以 redis 的`String`可以包含任何数据，比如jpg图片或者序列化的对象。Redis中一个字符串值的最大容量是512M。  
使用方式为 `set key value`

#### 1.2 List ####

List 是简单的字符串列表，按照插入顺序排序。可以添加一个元素到列表的头部（左边）或者尾部（右边）, 底层是基于链表实现的，所以它操作时头尾效率高，中间效率低。  
使用方式为`lpush key value`

#### 1.3 Set ####

唯一集合, 存储没有重复的的数据,是基于哈希表实现的。  
使用方式为 `sadd key value`

#### 1.4 Zset ####

Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序, zset的成员是唯一的,但分数(score)却可以重复。  
使用方式为 `zadd key [score member]`

#### 1.5 Hash ####

类似于数据库中一条记录的结构, 主要记录结构化的信息.以 key 为主键, \[field value\]作为数据存储的单元.使用方式为 `Hset`

## 2. Redis 持久化机制 ##

> Redis 持久化机制主要分为 RDB 和 AOF 两种，当 Redis 重启时，系统会优先使用 AOF 文件来还原数据集，因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整

#### 2.1 RDB ####

##### 2.1.1 RDB持久化 #####

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储.

*  优点:  
    保存的是真实数据, 一旦出现灾难性故障可以较容易地恢复数据.另外BGSAVE是fork出子进程完成持久化的工作, 这样就可以极大的避免服务进程执行IO操作,提高性能.在服务启动时, 数据较大的话RDB的启动效率较高.
 *  缺点:  
    系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失.

##### 2.1.2 RDB持久化配置 #####

配置文件 \*.conf 中可进行相关配置,默认开启.

<table> 
 <thead> 
  <tr> 
   <th>配置</th> 
   <th>作用</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>save 900 1</td> 
   <td>在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照</td> 
  </tr> 
  <tr> 
   <td>save 300 10</td> 
   <td>在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照</td> 
  </tr> 
  <tr> 
   <td>save 60 10000</td> 
   <td>在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照</td> 
  </tr> 
 </tbody> 
</table>

#### 2.2 AOF ####

##### 2.2.1 AOF持久化 #####

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录.

*  优点:  
    append模式,写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容.对数据的修改基本可以做到同步记录,当 AOF 文件过大时通过AOF Rewrite机制可以压缩文件.

<table> 
 <thead> 
  <tr> 
   <th>配置项</th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>auto-aof-rewrite-percentage 100</td> 
   <td>文件体积增大100%时执行AOF重写</td> 
  </tr> 
  <tr> 
   <td>auto-aof-rewrite-min-size 64mb</td> 
   <td>文件体积增长到64mb时执行AOF重写</td> 
  </tr> 
 </tbody> 
</table>

*  缺点:  
    相同数量的数据集AOF文件通常要大于RDB文件, 根据同步策略不同, AOF 可能比 RDB 慢.

##### 2.2.2 AOF文件损坏问题 #####

Redis服务器会在重新启动时执行一系列必要的一致性检测，一旦发现问题，就会立即退出并给出相应的错误提示。此时可利用Redis工具包中提供的redis-check-aof工具，该工具能够帮助我们定位到数据不一致的错误。其工作机制是将文件中损坏点之后的部分切除，而不是把受损数据恢复。

##### 2.2.3 AOF持久化配置 #####

在Redis的配置文件中存在三种同步方式, 不过需要手动配置启动.

<table> 
 <thead> 
  <tr> 
   <th>配置</th> 
   <th>作用</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>appendfsync always</td> 
   <td>每次有数据修改发生时都会写入AOF文件</td> 
  </tr> 
  <tr> 
   <td>appendfsync everysec</td> 
   <td>每秒钟同步一次，该策略为AOF的缺省策略</td> 
  </tr> 
  <tr> 
   <td>appendfsync no</td> 
   <td>从不同步,高效但是数据不会被持久化</td> 
  </tr> 
 </tbody> 
</table>

## 3. Redis 主从复制 ##

Redis 集群中通常把 Master 服务器作为写服务器, Slave服务器作为读服务器, Slave默认没有写数据权限. Master 服务器与Slave 服务器之间数据的同步就是主从复制.

**主从复制过程:**

> 1.  如果设置了 Slave,无论是第一次连接还是重连到Master,它都会发出一个SYNC请求.
> 2.  Master收到SYNC请求之后，会做两件事：  
>     1.Master执行BGSAVE，fork一个子进程，在后台保存数据到磁盘（rdb快照文件）.  
>     2.Master将新收到的写入和修改数据集的命令(非查询类)存入缓冲区.
> 3.  当Master在后台把数据保存到快照文件完成之后,会把这个快照文件传送给Slave,而Slave则把数据清空后,加载该文件到内存中.
> 4.  Master也会把此前收集到缓冲区中的命令通过Reids命令协议形式转发给Slave,Slave执行这些命令，实现和Master的同步.
> 5.  Master/Slave此后会不断通过异步方式进行命令的同步，达到最终数据的同步一致.

需要注意的是 Master 和 Slave 之间一旦发生重连都会引发全量同步操作, 但在2.8之后版本也可能是部分同步操作.

**部分复制**

1.  Redis 2.8 的这个部分重同步特性会用到一个新增的 PSYNC 内部命令，只要从服务器是 Redis 2.8 或以上的版本， 它就会根据主服务器的版本来决定到底是使用 PSYNC 还是 SYNC 。
2.  2.8开始，当 Master 和 Slave 之间的连接断开之后，他们之间可以采用持续复制处理方式代替采用全量同步。
3.  Master端为复制流维护一个内存缓冲区(in-memory backlog)，记录最近发送的复制流命令;同时Master和Slave之间都维护一个复制偏移量(replication offset), Slave 还会保存当前Master服务器ID(Master run id)。 
4.  当Slave尝试重连时, 如果MasterID相同（即仍是断网前的Master服务器），并且从断开时到当前时刻的历史命令依然在Master的内存缓冲区中存在，则Master会根据复制偏移量将 Slave 下线这段时间的所有命令发送给它执行，这样就完成了部分复制工作; 否则依然需要全量复制操作。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTUwNTMxMw_size_16_color_FFFFFF_t_70_pic_center]

## 4. Redis 哨兵机制 ##

Redis哨兵sentinel 主要用于监控集群中服务器的状态, 通过类似心跳检测的机制不断询问服务器状态, 在发现Master服务器挂了后就会从slave中重新选举一个Master服务器,以避免单点故障导致系统不可用的问题.

#### 4.1 工作原理 ####

1.  哨兵机制建立了多个哨兵节点(进程)，共同监控数据节点的运行状况.
2.  同时哨兵节点之间也互相通信，交换对主从节点的监控状况.
3.  每隔1秒每个哨兵会向整个集群(Master主服务器+Slave从服务器+其他Sentinel进程) 发送一次ping命令做心跳检测.如果一个节点距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel（哨兵）进程标记为主观下线(SDOWN).

哨兵用来判断节点是否正常的重要依据涉及两个概念：**主观下线和客观下线**.

*  **主观下线(sdown)**：一个哨兵节点判定节点down掉是主观下线.
 *  **客观下线(odown)**：判定节点主观下线的哨兵节点数量达到配置的值，此时判定节点客观下线.

基本上哪个哨兵节点最先判断出主节点客观下线，就会在各个哨兵节点中发起投票机制 Raft 算法(选举算法),最终 1.被投为领导者的哨兵节点 完成 2.主从自动化切换的过程.

#### 4.2 哨兵集群选举Leader ####

如果需要从redis集群选举一个节点为主节点，首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。

1.  每一个Sentinel节点都可以成为Leader，当一个Sentinel节点确认redis集群的主节点主观下线后，会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求，则同意该请求(选举票数+1)，否则不同意。
2.  如果一个Sentinel节点获得的选举票数达到指定票数(Sentinel节点数/2+1 与判定客观下线所需的哨兵节点数的最大值)，则该Sentinel节点选举为Leader；否则重新进行选举。

#### 4.3 Redis 主从自动化切换 ####

当哨兵集群选举出Leader后，由Sentinel Leader从redis从节点中选择一个作为主节点：

*  **过滤故障的节点**
 *  **选择优先级slave-priority最大**的从节点作为主节点，如不存在则继续
 *  **选择复制偏移量最大的从节点**（复制偏移量：数据写入量的字节，记录写了多少数据。主服务器会把偏移量同步给从服务器，当主从节点的偏移量一致，则数据是完全同步）作为主节点，如不存在则继续
 *  **选择runid 最小的从节点**（redis每次启动的时候生成随机的runid作为redis的标识）作为主节点

## 5. Redis 内存淘汰策略 ##

Redis内存使用超过一定值的时候可采用以下策略淘汰数据：

1.  `volatile-lru`：从已设置过期时间的数据集（server.db\[i\].expires）中挑选最近最少使用的数据淘汰
2.  `volatile-ttl`：从已设置过期时间的数据集（server.db\[i\].expires）中挑选将要过期的数据淘汰
3.  `volatile-random`：从已设置过期时间的数据集（server.db\[i\].expires）中任意选择数据淘汰
4.  `volatile-lfu`: 从所有设置了过期时间的键中驱逐使用频率最少的键
5.  `allkeys-lru`：从数据集（server.db\[i\].dict）中挑选最近最少使用的数据淘汰
6.  `allkeys-random`：从数据集（server.db\[i\].dict）中任意选择数据淘汰
7.  `noeviction`：禁止驱逐数据，当内存使用达到阈值的时候，所有引起申请内存的命令会报错
8.  `allkeys-lfu`:从所有键中驱逐使用频率最少的键

*  设置方式  
    `config set maxmemory-policy volatile-lru`

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTUwNTMxMw_size_16_color_FFFFFF_t_70_pic_center]: https://img-blog.csdnimg.cn/20190827162823367.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NTUwNTMxMw==,size_16,color_FFFFFF,t_70#pic_center