Redis主备原理

r囧r小猫 2023-01-23 05:52 34阅读 0赞

## Redis ##

Redis，Key-Value 数据库，用来保存一些不需要持久化的数据，或者是经常需要进行读取的数据（多读少写），并支持对数据设置有效期等。例如我们主备方案中的用户token信息、OLT设备信息等均使用到了Redis。

Sentinel是Redis高可用的解决方案之一，本身也是分布式的架构，包含了\*\*「多个」**Sentinel节点和**「多个」\*\*Redis节点。而每个Sentinel节点会对Redis节点和其余的Sentinel节点进行监控。主要功能是基于redis的主从复制基础上，提供节点故障检测，主节点选举，故障切换等等功能。保证服务不会因为单个redis节点宕机而出现故障。当其发现某个节点不可达时，如果是master节点就会与其余的Sentinel节点协商。当大多数的Sentinel节点都认为master不可达时，就会选出一个Sentinel节点对master执行故障转移，并通知Redis的调用方相关的变更。

**Redis的主从复制**：

1、同一个Master可以同步多个Slaves。

2、Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。

3、Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。

4、Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据。

5、在Slave启动并连接到Master之后，它将主动发送一个SYNC命令。此后Master将启动后台存盘进程，同时收集所有接收到的用于修改数据集的命令，在后台进程执行完毕后，Master将传送整个数据库文件到Slave，以完成一次完全同步。而Slave服务器在接收到数据库文件数据之后将其存盘并加载到内存中。即连上之后，先进行一次全量同步。

6、此后，Master继续将所有已经收集到的修改命令，和新的修改命令依次传送给Slaves，Slave将在本次执行这些数据修改命令，从而达到最终的数据同步。后面进行增量同步。

7、 如果Master和Slave之间的链接出现断连现象，Slave可以自动重连Master，但是在连接成功之后，一次完全同步将被自动执行。

**Redis-Sentinel**主要功能

1.  **监控（Monitoring）**：Sentinel会不断的检查你的主节点和从节点是否正常工作。
2.  **通知（Notification）**：被监控的Redis实例如果出现问题，Sentinel可以通过API（pub）通知系统管理员或者其他程序。
3.  **自动故障转移（Automatic failover）**：如果一个 master 离线，Sentinel 会开始进行故障转移，master 下的一个slave 会被选为新的 master，其他的 slave 会开始复制新的 master。应用可以通过 Redis 服务的通知机制更新新的master 地址。
4.  **配置提供（Configuration provider）**：客户端可以把 Sentinel 作为权威的配置发布者来获得最新的 master 地址。如果发生了故障转移，Sentinel 集群会通知客户端新的 master 地址，并刷新 Redis 的配置。

Sentinel 之间：**自动发现机制**

1.  Sentinel 利用 pub/sub（发布/订阅）机制，订阅了每个 master 和 slave 数据节点的 `__sentinel__:hello` 频道，去自动发现其它也监控了统一 master 的 sentinel 节点
2.  Sentinel 向每 1s 向 `__sentinel__:hello` 中发送一条消息，包含了其当前维护的最新的 master 配置。如果某个sentinel发现自己的配置版本低于接收到的配置版本，则会用新的配置更新自己的 master 配置
3.  与发现的 Sentinel 之间相互建立**命令连接**，之后会通过这个命令连接来交换对于 master 数据节点的看法

**监控机制**：

1.  **定时监控 Redis 数据节点**
2.  1.  **每 10 秒**每个 sentinel 向 master、slaves 节点发送 `INFO` 命令
    2.  **每 2 秒**每个 sentinel 通过 master 节点的 channel(名称为 `__sentinel__:hello`) 交换信息(pub/sub)
    3.  **每 1 秒**每个 sentinel 对其他 sentinel 和 redis master, slave 发送 `PING` 命令,用于心跳检测,作为节点存活的判断依据
3.  **主观下线和客观下线（发现故障）**
4.  1.  **主观下线（subjectively down，SDOWN）**：当前 Sentinel 实例认为某个 redis 服务为”不可用”状态。Sentinel 向 redis master 数据节点发送消息后 30s（down-after-milliseconds） 内没有收到有效回复（+PONG、-LOADING 或者 -MASTERDOWN），Sentinel 会将 master 标记为下线
    2.  \*\*客观下线（objectively down，ODOWN）：\*\*多个 Sentinel 实例都认为 master 处于 SDOWN 状态，那么此时 master 将处于 ODOWN， ODOWN可以简单理解为master已经被集群确定为”不可用”,将会开启故障转移机制。向其他 sentinel 节点发送 sentinel `is-master-down-by-addr` 消息询问数据节点情况，得知达到 quorum 数量的 sentinel 节点认为数据节点已经下线

**故障处理-选举**

就是选举出新的Leader-Sentinel，选举过程如下：

1、发现主库客观下线的哨兵节点（这里称为A）向每个哨兵节点发送命令要求对方选举自己为领头哨兵（leader）；  
2、如果目标哨兵没有选举过其他人，则同意将A选举为领头哨兵；  
3、如果A发现有超过半数且超过quorum参数值的哨兵节点同意选自己成为领头哨兵，则A哨兵成功选举为领头哨兵。  
4、当有多个哨兵节点同时参与领头哨兵选举时，出现没有任何节点当选可能，此时每个参选节点等待一个随机时间进行下一轮选举，直到选出领头哨兵。

**故障转移**（切换 Redis master 数据节点）

1.  1.  sentinel master 选择合适的 redis slave 成为 master  
        slave 选择标准：
    2.  1.  健康的节点：在线的、最近成功通信过的（5s 内回复过 `PING` 命令）、数据比较新的（与 master 失联时间不超过 10\*down-after-milliseconds）
        2.  slave-priority（slave节点优先级）最高的slave节点
        3.  复制偏移量最大的 slave 节点（复制的最完整）
        4.  选择 runId 最小的 slave 节点（启动最早的节点）
    3.  执行 `SLAVEOF no one`（不会删除已有数据，只是不再接受主节点新的数据变化） 命令让其成为新的 master 节点。每秒 Sentinel 向其发送一次 `INFO` 命令，直到成功变为 master
    4.  向剩余的 slave 节点发送 `SLAVEOF 新master` 命令，让他们成为新 master 节点的 slave 节点
    5.  让剩余的 slave 复制新 master 的数据，通过配置 `sentinel parallel-syncs`（sentinel.conf） 规定了每次向新的主节点发起复制操作的从节点个数，parallel-syncs 取值越大，slave 完成复制的时间越快，但是对主节点的网络负载、硬盘负载造成的压力也越大
    6.  更新原来master 节点配置为 slave 节点,并保持对其进行关注,一旦这个节点重新恢复正常后,会命令它去复制新的master节点信息
    7.  全部故障转移工作完成后，Leader Sentinel 就会推送 +switch-master 消息，同时重置 master，重置操作会释放掉原来 master 全部的 slave 对象和监听该 master 的其他 Sentinel 对象，然后创建出新的 slave 对象。故障迁移过程中 slave 能否返回数据给客户端取决于 `slave-serve-stale-data`（redis.conf）
    8.  **持续关注旧的 master**，并在他重新上线后将它设置为新 master 的 slave

在 sentinel 中执行 `sentinel failover master` 可以强制该 sentinel 节点执行故障转移，不与其他节点进行选举

我们主备方案下的Redis配置文件如下（仅列出有配置的项目）：

# 开启后台启动，默认为no
    daemonize yes
    
    # 新增密码，此处设置zhkjredis@002396
    requirepass "password"
    
    # 允许从节点进行写功能
    slave-read-only no
    
    # 设置了密码，主节点需要进行密码认证
    masterauth "password6"
    
    # 如果是Slave则需要配置Master的地址
    slaveof 10.10.10.238 6379

Sentinel配置文件如下（仅列出有配置的项目）：

# 检查主redis节点的地址和端口信息，1代表至少1个sentinel节点认为主节点宕机才算宕机，根据实际情况进行配置
    sentinel monitor mymaster 10.10.10.44 6379 1
    
    # 主节点失联X秒后，认为主节点不可达，默认30s
    sentinel down-after-milliseconds mymaster 5000
    
    # 主节点的密码，如有的话
    sentinel auth-pass mymaster password
    
    # sentinel后台运行
    daemonize yes
    
    # 解决哨兵之间不能通信，不能进行主结节客观下线的判断，以及failover
    protected-mode no