redis 主从及哨兵Sentinel学习

一、主从复制

Redis支持主从复制功能，可以通过执行slaveof（Redis5以后改成replicaof）或者在配置文件中设置slaveof(Redis5以后改成replicaof)来开启复制功能。

主从配置

主Redis配置，无需特殊配置
从Redis配置，修改从服务器上的 redis.conf 文件：

# slaveof <masterip> <masterport> 
# 表示当前【从服务器】对应的【主服务器】的IP是192.168.10.135，端口是6379。 
replicaof 127.0.0.1 6379

原理与实现

Redis 2.8以前

Redis的同步功能分为同步(sync)和命令传播(command propagate)。

1）同步操作：

1. 通过从服务器发送到SYNC命令给主服务器
2. 主服务器生成RDB文件并发送给从服务器，同时发送保存所有写命令给从服务器
3. 从服务器清空之前数据并执行解释RDB文件
4. 保持数据一致（还需要命令传播过程才能保持一致）
   

2）命令传播操作：

同步操作完成后，主服务器执行写命令，该命令发送给从服务器并执行，使主从保存一致。

缺陷

• 没有全量同步和增量同步的概念，从服务器在同步时，会清空所有数据。
• 主从服务器断线后重复制，主服务器会重新生成RDB文件和重新记录缓冲区的所有命令，并全量同步到从服务器上。

Redis 2.8以后

在Redis 2.8之后使用PSYNC命令，具备完整重同步和部分重同步模式。

• Redis 的主从同步，分为全量同步和增量同步。
• 只有从机第一次连接上主机是全量同步。
• 断线重连有可能触发全量同步也有可能是增量同步（ master 判断 runid 是否一致）。
• 除此之外的情况都是增量同步。
  

全量同步

Redis 的全量同步过程主要分三个阶段：

1. 同步快照阶段： Master 创建并发送快照RDB给 Slave ， Slave 载入并解析快照。 Master 同时将此阶段所产生的新的写命令存储到缓冲区。
2. 同步写缓冲阶段： Master 向 Slave 同步存储在缓冲区的写操作命令。
3. 同步增量阶段： Master 向 Slave 同步写操作命令。

增量同步

• Redis增量同步主要指Slave完成初始化后开始正常工作时， Master 发生的写操作同步到 Slave 的过程。
• 通常情况下， Master 每执行一个写命令就会向 Slave 发送相同的写命令，然后 Slave 接收并执行。

二、哨兵模式

哨兵（sentinel）是Redis的高可用性(High Availability)的解决方案：

由一个或多个sentinel实例组成sentinel集群可以监视一个或多个主服务器和多个从服务器。

当主服务器进入下线状态时，sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证redis的高可用性。

1. 部署方案

2. 实战

1. 创建6个文件夹
   
2. 安装redis，复制redis.conf
   
3. 修改redis.conf文件

修改redis.conf 
# 将`daemonize`由`no`改为`yes` 
daemonize yes 
# 默认绑定的是回环地址，默认不能被其他机器访问 
# bind 127.0.0.1
 # 是否开启保护模式，由yes该为no 
 protected-mode no

4. 依次复制master的内容到其他文件夹中，然后修改相关的端口
   
5. 我们需要先拷贝sentinel.conf到哨兵的目录下，之前的redis.conf就不需要了
   
6. 哨兵的配置文件如下，大部分都是默认配置，重点在端口、daemonize、sentinel monitor的修改

# 哨兵sentinel实例运行的端口 默认26379
port 26379
# 将`daemonize`由`no`改为`yes`
daemonize yes
# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提
供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒，改成3秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 3000
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步，
这个数字越小，完成failover所需的时间就越长，
但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master
那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，
slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000

7. 启动
   在redis-sentinel目录下 ./redis-sentinel sentinel.conf

3. 执行流程

启动并初始化Sentinel

Sentinel是一个特殊的Redis服务器，不会进行持久化。Sentinel实例启动后，每个Sentinel会创建2个连向主服务器的网络连接。

• 命令连接：用于向主服务器发送命令，并接收响应；
• 订阅连接：用于订阅主服务器的—sentinel—:hello频道。
  

获取主服务器信息

Sentinel默认每10s一次，向被监控的主服务器发送info命令，获取主服务器和其下属从服务器的信息。

获取从服务器信息

当Sentinel发现主服务器有新的从服务器出现时，Sentinel还会向从服务器建立命令连接和订阅连接。在命令连接建立之后，Sentinel还是默认10s一次，向从服务器发送info命令，并记录从服务器的信息。

向主服务器和从服务器发送消息(以订阅的方式)

默认情况下，Sentinel每2s一次，向所有被监视的主服务器和从服务器所订阅的—sentinel—:hello频道上发送消息，消息中会携带Sentinel自身的信息和主服务器的信息。

PUBLISH _sentinel_:hello "< s_ip > < s_port >< s_runid >< s_epoch > < m_name > <m_ip >< m_port ><m_epoch>"

我们在客户端执行psubscribe _*可以订阅哨兵的hello频道，然后收到以下的信息

接收来自主服务器和从服务器的频道信息

当Sentinel与主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅连接，向服务器发送以下命令：

subscribe —sentinel—:hello

Sentinel彼此之间只创建命令连接，而不创建订阅连接，因为Sentinel通过订阅主服务器或从服务器同一个hello频道，就可以感知到新的Sentinel的加入，而一旦新Sentinel加入后，相互感知的Sentinel通过命令连接来通信就可以了。

检测主观下线状态

Sentinel每秒一次向所有与它建立了命令连接的实例(主服务器、从服务器和其他Sentinel)发送PING命令

实例在down-after-milliseconds毫秒内返回无效回复(除了+PONG、-LOADING、-MASTERDOWN外)

实例在down-after-milliseconds毫秒内无回复（超时）

Sentinel就会认为该实例主观下线(SDown)

检查客观下线状态

当一个Sentinel将一个主服务器判断为主观下线后
Sentinel会向同时监控这个主服务器的所有其他Sentinel发送查询命令

SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>

其他Sentinel回复

<down_state>< leader_runid >< leader_epoch >

判断它们是否也认为主服务器下线。如果达到Sentinel配置中的quorum数量的Sentinel实例都判断主服务器为主观下线，则该主服务器就会被判定为客观下线(ODown)。

选举Leader Sentinel

当一个主服务器被判定为客观下线后，监视这个主服务器的所有Sentinel会通过选举算法（raft），选出一个Leader Sentinel去执行failover（故障转移）操作。

故障转移

当选举出Leader Sentinel后，Leader Sentinel会对下线的主服务器执行故障转移操作，主要有三个步骤：

1. 它会将失效 Master 的其中一个 Slave 升级为新的 Master , 并让失效 Master 的其他 Slave 改为复制新的 Master ；
2. 当客户端试图连接失效的 Master 时，集群也会向客户端返回新 Master 的地址，使得集群可以使用现在的 Master 替换失效 Master 。
3. Master 和 Slave 服务器切换后， Master 的 redis.conf 、 Slave 的 redis.conf 和sentinel.conf 的配置文件的内容都会发生相应的改变，即， Master 主服务器的 redis.conf 配置文件中会多一行 replicaof 的配置， sentinel.conf 的监控目标会随之调换。

主服务器的选择

哨兵leader根据以下规则从客观下线的主服务器的从服务器中选择出新的主服务器。

1. 过滤掉主观下线的节点
2. 选择slave-priority最高的节点，如果由则返回没有就继续选择
3. 选择出复制偏移量最大的系节点，因为复制偏移量越大则数据复制的越完整，如果由就返回了，没有就继续
4. 选择run_id最小的节点，因为run_id越小说明重启次数越少