Redis的replication架构(主从+哨兵)

Love The Way You Lie 2021-11-27 06:22 287阅读 0赞

# Redis #

### 文章目录 ###

*  Redis
 *   *  replication架构
     *   *  承载高并发
         *  一些基本概念
         *   *  offset
             *  backlog
             *  master run id
             *  psync
             *  heartbeat
             *  异步复制
         *  最基本的功能
         *  复制的核心原理、过程
         *   *  正常情况下(已经连接成功)、增量复制
             *   *  增量复制详细流程
             *  全量复制，异常情况(太久没连上、第一次连接)
             *   *  全量复制详细流程
         *  redis提供的功能
         *   *  主从复制的断点续传
             *  无磁盘复制
             *  过期key处理
         *  哨兵 sentinal
         *   *  功能
             *  原理
             *   *  sdown和odown的转换机制
                 *  哨兵集群的自动发现机制
                 *  slave配置的自动纠正
                 *  quorum 和 majority
                 *  选举算法
             *  2种数据丢失现象及解决方案
             *   *  异步复制导致数据丢失
                 *  脑裂导致数据丢失
                 *  解决方案

## replication架构 ##

### 承载高并发 ###

1.  通过读写分离，读往master节点，读往slave从节点
2.  水平扩容
3.  replication架构–主从架构

### 一些基本概念 ###

#### offset ####

master和salve中都会存有一个offset，可以用来了解主从之间的数据差异。

#### backlog ####

默认1mb，在做复制的时候，会保存一份

用来做全量复制意外中断的时候 做增量复制用的

#### master run id ####

master启动的时候就会生成一个id(相当于一个uuid)，表示的是这个节点的唯一键，如果主节点挂掉又重启了，从节点就会执行全量复制

#### psync ####

从节点发送这个命令去主节点拿数据，psync runid offset

根据这个返回增量复制

#### heartbeat ####

1.  心跳包
2.  主节点10秒一次发给从节点
3.  冲击诶单1s一次发给主节点

#### 异步复制 ####

给从节点的数据，都是在异步线程执行的

### 最基本的功能 ###

1.  **写master，异步写到salve节点**
2.  一个master可以挂多个salve
3.  salve节点在复制新数据的时候，如果查询进来，还是返回旧数据
4.  主节点一定要开启持久化

### 复制的核心原理、过程 ###

1.  从节点配置文件中保存主节点信息，加载到内存中
2.  定时任务：每秒钟检测是否有master需要连接和复制，如果有的话就需要建立连接
3.  发送ping，连接主节点
4.  如果有账号密码，需要发过去
5.  全量复制，将所有的数据发过去
6.  后续所有写操作，也都转发过去  
    ![复制的完整的基本流程][aHR0cHM6Ly9qajdjbS5jb20vaW1nL2Jsb2cvcmVkaXMvcmVkaXMlRTQlQjglQkIlRTQlQkIlOEUlRTUlQTQlOEQlRTUlODglQjYlRTclOUElODQlRTUlOEUlOUYlRTclOTAlODYucG5n]

#### 正常情况下(已经连接成功)、增量复制 ####

1.  2边数据一致，这时候进来一个写请求
2.  redis主线程写到 master，返回
3.  异步线程和salve通信，将这条记录写过去

##### 增量复制详细流程 #####

1.  全量复制过程中，主从连接断掉，当重新连接的时候，会触发增量复制
2.  master会将backlog中获取部分丢失的数据，发送给salve
3.  master根据slave发送的psync中的offset从backlog中获取数据

#### 全量复制，异常情况(太久没连上、第一次连接) ####

1.  主节点生成rdb文件
2.  从节点将rdb文件取到，持久化到本地
3.  从节点使用该rdb文件reload
4.  如果在2.3步骤的过程中主节点有数据变更，会将这些数据用上一个方法复制

##### 全量复制详细流程 #####

1.  主节点生成bgsave，生成一份rdb文件
2.  主节点发送rdb文件给从节点，默认时间是60s判断是否正常发送成功
3.  文件过大的话，这个有可能60s发不完
4.  在发送的这段时间，主节点会将所有的写命令存到内存中，等从节点保存完rdb之后，将这些命令复制给从节点
5.  有个参数，表示如果 环节4的缓存 超过64m，就判定复制失败
6.  从节点接收到rdb之后，清空旧数据，重新加载rdb到内存中，期间使用旧数据对外服务
7.  如果从节点开启aof的rewrite，则会立即重写aof

### redis提供的功能 ###

#### 主从复制的断点续传 ####

1.  主节点中维护一个backlog和一个offset
2.  从节点断掉重连，就从offset继续复制
3.  如果offset不匹配，则触发全量复制 full resynchronization

#### 无磁盘复制 ####

全量复制的时候，主节点不生成rdb文件，而是直接生成到内存中，复制过去

#### 过期key处理 ####

只会是master处理

### 哨兵 sentinal ###

一般是三节点哨兵，2节点哨兵无法进行选举

#### 功能 ####

1.  集群监控
2.  消息通知，实例有故障，发消息通知管理员
3.  故障转移，主备切换
4.  配置中心，主备切换之后，通知给从节点

#### 原理 ####

##### sdown和odown的转换机制 #####

1.  sdown，是主观宕机，哨兵ping不通(设置中的一个毫秒时间数)主机主节点就认定失败
2.  odown，客观宕机，quorum个哨兵觉得master宕机，就是觉得宕机了

##### 哨兵集群的自动发现机制 #####

1.  redis中的发布订阅
2.  每个哨兵都订阅，sentinal——channel
3.  每2秒钟，哨兵都往这个channel中写入：自己的节点信息及监控的信息

##### slave配置的自动纠正 #####

1.  纠正slave的配置信息
2.  master如果改变，则需要改变slave上面的配置信息
3.  每个配置信息都有一个版本号，如果版本号比当前的新，则更新

##### quorum 和 majority #####

1.  quorum用来判定某个master是否宕机
2.  majority用来授权主备切换

##### 选举算法 #####

1.  quorum个哨兵判定master宕机，majority同意主备切换
2.  按照以下顺序进行选举
    
    1.  设定了优先级的
    2.  offset数据
    3.  runid

#### 2种数据丢失现象及解决方案 ####

##### 异步复制导致数据丢失 #####

master节点在主线程写完数据，异步复制过程中挂掉了，这部分数据丢失

##### 脑裂导致数据丢失 #####

某个master和 salve-哨兵 网络连接错误，导致slave选举成 master，这时候集群中有2个master。

client 还往master中写数据，等到 master和slave连接恢复的时候，master转换成slave，会从新master同步数据，这时候，原来的master数据就丢失了

##### 解决方案 #####

1.  参数

min-slaves-to-write 1
    min-slaves-max-lag 10

1.  表示至少有一个slave，数据复制和同步的延迟不能超过10s
2.  如果主节点和从节点之间的通信或者数据偏移量超过10s，则判定master宕机

[aHR0cHM6Ly9qajdjbS5jb20vaW1nL2Jsb2cvcmVkaXMvcmVkaXMlRTQlQjglQkIlRTQlQkIlOEUlRTUlQTQlOEQlRTUlODglQjYlRTclOUElODQlRTUlOEUlOUYlRTclOTAlODYucG5n]: /images/20211126/b8f8127d36d74ff190597f8b5c5b64f3.png