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

Redis

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. 后续所有写操作，也都转发过去
   

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

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

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