Redis高可用方案（一）：主从复制与哨兵机制
“高可用性”（High Availability） 通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。CAP的A AP模型
单机的Redis是无法保证高可用性的，当Redis服务器宕机后，即使在有持久化的机制下也无法保证不丢失数据。
所以我们采用Redis多机和集群的方式来保证Redis的高可用性。
单进程+单线程 + 多机 （集群）
主从复制
Redis支持主从复制功能，可以通过执行slaveof（Redis5以后改成replicaof）或者在配置文件中设置 slaveof(Redis5以后改成replicaof)来开启复制功能。
当然这里slave最好还是采用奇数的个数，方便后面的投票选举。
（传递复制）
- 主对外从对内，主可写从不可写
- 主挂了，从不可为主
主从配置
主Redis配置
无需特殊配置
从Redis配置
修改从服务器上的 redis.conf 文件：
# slaveof <masterip> <masterport>
# 表示当前【从服务器】对应的【主服务器】的IP是192.168.10.135，端口是6379。
replicaof 127.0.0.1 6379
作用
读写分离
- 一主多从，主从同步
- 主负责写，从负责读
- 提升Redis的性能和吞吐量
- 主从的数据一致性问题
数据容灾
- 从机是主机的备份
- 主机宕机，从机可读不可写
- 默认情况下主机宕机后，从机不可为主机，需要利用哨兵实现主从切换
- 利用哨兵可以实现主从切换，做到高可用
原理与实现
复制流程
保存主节点信息
当客户端向从服务器发送slaveof(replicaof) 主机地址（127.0.0.1） 端口（6379）时：从服务器将主机 ip（127.0.0.1）和端口（6379）保存到redisServer的masterhost和masterport中。
Struct redisServer{
char *masterhost;//主服务器ip
int masterport;//主服务器端口
} ;
从服务器将向发送SLAVEOF命令的客户端返回OK，表示复制指令已经被接收，而实际上复制工作是在OK返回之后进行。
建立socket连接
slaver与master建立socket连接
slaver关联文件事件处理器
该处理器接收RDB文件（全量复制）、接收Master传播来的写命令（增量复制）
主服务器accept从服务器Socket连接后，创建相应的客户端状态。相当于从服务器是主服务器的Client端。
发送ping命令
Slaver向Master发送ping命令
1、检测socket的读写状态
2、检测Master能否正常处理
Master的响应：
1、发送“pong” , 说明正常
2、返回错误，说明Master不正常
3、timeout，说明网络超时
权限验证
主从正常连接后，进行权限验证
主未设置密码（requirepass=“”） ，从也不用设置密码（masterauth=“”）
主设置密码(requirepass!=""),从需要设置密码(masterauth=主的requirepass的值)
或者从通过auth命令向主发送密码
发送端口信息
在身份验证步骤之后，从服务器将执行命令REPLCONF listening-port ，向主服务器发送从服务器的监听端口号。
同步数据
Redis 2.8之后分为全量同步和增量同步
1.同步数据（第一次）—RDB文件
2.命令传播（增量）—命令的传播：主服务器执行的命令会在从服务器上再执行 一次
命令传播
当同步数据完成后，主从服务器就会进入命令传播阶段，主服务器只要将自己执行的写命令发送给从服务器，而从服务器只要一直执行并接收主服务器发来的写命令。
同步数据集
Redis 2.8以前使用SYNC命令同步复制
Redis 2.8之后采用PSYNC命令替代SYNC
旧版本
Redis 2.8以前
实现方式
Redis的同步功能分为同步(sync)和命令传播(command propagate)。
1）同步操作：
- 通过从服务器发送到SYNC命令给主服务器
- 主服务器生成RDB文件并发送给从服务器，同时发送保存所有写命令给从服务器
- 从服务器清空之前数据并执行解释RDB文件
- 保持数据一致（还需要命令传播过程才能保持一致）
2）命令传播操作：
同步操作完成后，主服务器执行写命令，该命令发送给从服务器并执行，使主从保存一致。
缺陷
- 没有全量同步和增量同步的概念，从服务器在同步时，会清空所有数据。
- 主从服务器断线后重复制，主服务器会重新生成RDB文件和重新记录缓冲区的所有命令，并全量同步到从服务器上
新版本
Redis 2.8以后
实现方式
在Redis 2.8之后使用PSYNC命令，具备完整重同步和部分重同步模式。
-
Redis 的主从同步，分为全量同步和增量同步。
-
只有从机第一次连接上主机是全量同步。
-
断线重连有可能触发全量同步也有可能是增量同步（ master 判断 runid 是否一致）。
-
除此之外的情况都是增量同步
全量同步
Redis 的全量同步过程主要分三个阶段：
同步快照阶段： Master 创建并发送快照RDB给 Slave ， Slave 载入并解析快照。Master同时将此阶段所产生的新的写命令存储到缓冲区。
同步写缓冲阶段： Master 向 Slave 同步存储在缓冲区的写操作命令。
同步增量阶段： Master 向 Slave 同步写操作命令。
增量同步
- Redis增量同步主要指Slave完成初始化后开始正常工作时， Master 发生的写操作同步到 Slave 的过程。
- 通常情况下， Master 每执行一个写命令就会向 Slave 发送相同的写命令，然后 Slave 接收并执行。
心跳检测
在命令传播阶段，从服务器默认会以每秒一次的频率向主服务器发送命令：
replconf ack <replication_offset>
#ack :应答
#replication_offset：从服务器当前的复制偏移量
主要作用有三个：
-
检测主从的连接状态
- 检测主从服务器的网络连接状态
通过向主服务器发送INFO replication命令，可以列出从服务器列表，可以看出从最后一次向主发送命令距离现在过了多少秒。lag的值应该在0或1之间跳动，如果超过1则说明主从之间的连接有故障。 - 辅助实现min-slaves
Redis可以通过配置防止主服务器在不安全的情况下执行写命令
min-slaves-to-write 3 （min-replicas-to-write 3 ）
min-slaves-max-lag 10 （min-replicas-max-lag 10）
上面的配置表示：从服务器的数量少于3个，或者三个从服务器的延迟（lag）值都大于或等于10秒时，主服务器将拒绝执行写命令（因此此时可能从服务器没有办法进行数据同步）。这里的延迟值就是上面INFOreplication命令的lag值。
- 检测主从服务器的网络连接状态
-
检测命令丢失
如果因为网络故障，主服务器传播给从服务器的写命令在半路丢失，那么当从服务器向主服务器发送REPLCONF ACK命令时，主服务器将发觉从服务器当前的复制偏移量少于自己的复制偏移量，然后主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数
据，并将这些数据重新发送给从服务器。（补发） 网络不断
增量同步：网断了，再次连接时
哨兵模式
哨兵（sentinel）是Redis的高可用性(High Availability)的解决方案：
由一个或多个sentinel实例组成sentinel集群可以监视一个或多个主服务器和多个从服务器。
当主服务器进入下线状态时，sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证redis的高可用性。
部署方案
执行流程
启动并初始化Sentinel
Sentinel是一个特殊的Redis服务器
不会进行持久化（即相当于不存数据）
Sentinel实例启动后
每个Sentinel会创建2个连向主服务器的网络连接
命令连接： 用于向主服务器发送命令，并接收响应；
订阅连接： 用于订阅主服务器的—sentinel—:hello频道。
获取主服务器信息
Sentinel默认每10s一次，向被监控的主服务器发送info命令，获取主服务器和其下属从服务器的信息。
127.0.0.1:6379> info
# Server
redis_version:5.0.5
os:Linux 3.10.0-229.el7.x86_64 x86_64
run_id:a4e06ab61b4116660aa37b85079ed482b0b695b1
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=1571684,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=1571551,lag=1
master_replid:366322125dd7dc9bc95ed3467cfec841c112e207
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1571684
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:523109
repl_backlog_histlen:1048576
获取从服务器信息
当Sentinel发现主服务器有新的从服务器出现时，Sentinel还会向从服务器建立命令连接和订阅连接。
在命令连接建立之后，Sentinel还是默认10s一次，向从服务器发送info命令，并记录从服务器的信息。
# Server
redis_version:5.0.5
os:Linux 3.10.0-229.el7.x86_64 x86_64
run_id:e289b3286352aaf8cc9f1ac7ebcc6d36131b8321
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:1699595
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:366322125dd7dc9bc95ed3467cfec841c112e207
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1699595
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:651020
repl_backlog_histlen:1048576
向主服务器和从服务器发送消息(以订阅的方式)
默认情况下，Sentinel每2s一次，向所有被监视的主服务器和从服务器所订阅的—sentinel—:hello频道上发送消息，消息中会携带Sentinel自身的信息和主服务器的信息。
PUBLISH _sentinel_:hello "< s_ip > < s_port >< s_runid >< s_epoch > < m_name > < m_ip >< m_port ><m_epoch>"
接收来自主服务器和从服务器的频道信息
当Sentinel与主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅连接，向服务器发送以下命令：
subscribe —sentinel—:hello
Sentinel彼此之间只创建命令连接，而不创建订阅连接，因为Sentinel通过订阅主服务器或从服务器，就可以感知到新的Sentinel的加入，而一旦新Sentinel加入后，相互感知的Sentinel通过命令连接来通信就可以了。
为什么Sentinel之间只需要建立命令连接？
虽然sentinel集群中各个sentinel都互相连接彼此来检查对方的可用性以及互相发送消息。但是你不用在任何一个sentinel配置任何其它
的sentinel的节点。因为sentinel利用了master的发布/订阅机制去自动发现其它也监控了统一master的sentinel节点。 通过向名为__sentinel__:hello的管道中发送消息来实现。
同样，你也不需要在sentinel中配置某个master的所有slave的地址，sentinel会通过询问master来得到这些slave的地址的 （比如在获取主服务器信息的图中显示了所有的slave）。 每个sentinel通过向每个master和slave的发布/订阅频道__sentinel__:hello每秒发送一次消息，来宣布它的存在。 每个sentinel也订阅了每个master和slave的频道__sentinel__:hello的内容，来发现未知的sentinel，当检测到了新的sentinel，则将其加入到自身维护的master监控列表中。
每个sentinel发送的消息中也包含了其当前维护的最新的master配置。如果某个sentinel发现 自己的配置版本低于接收到的配置版本，则会用新的配置更新自己的master配置。 在为一个master添加一个新的sentinel前，sentinel总是检查是否已经有sentinel与新的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>
current_epoch: 选举号，该sentinel认为主服务器下线
其他Sentinel回复
<down_state>< leader_runid >< leader_epoch >
因为其它sentinel也在监听主服务器，所以也会保留主服务器的响应状态信息， 所以这里就是等待其它sentinel返回自己对主机下线状态的判断。
如果达到Sentinel配置中的quorum数量的Sentinel实例都判断主服
务器为主观下线，则该主服务器就会被判定为客观下线(ODown)。
选举Leader Sentinel
当一个主服务器被判定为客观下线后，监视这个主服务器的所有Sentinel会通过选举算法（raft），选出一个Leader Sentinel去执行failover（故障转移）操作。
哨兵leader选举
Raft
Raft协议是用来解决分布式系统一致性问题的协议。
Raft协议描述的节点共有三种状态：Leader, Follower, Candidate。
term：Raft协议将时间切分为一个个的Term（任期），可以认为是一种“逻辑时间”。
选举流程：
Raft采用心跳机制触发Leader选举
系统启动后，全部节点初始化为Follower，term为0。
节点如果收到了RequestVote或者AppendEntries，就会保持自己的Follower身份
节点如果一段时间内没收到AppendEntries消息，在该节点的超时时间内还没发现Leader，Follower就会转换成Candidate，自己开始竞选Leader。
一旦转化为Candidate，该节点立即开始下面几件事情：
- 增加自己的term。
- 启动一个新的定时器。
- 给自己投一票
- 向所有其他节点发送RequestVote，并等待其他节点的回复。
如果在计时器超时前，节点收到多数节点的同意投票，就转换成Leader。同时向所有其他节点发送AppendEntries，告知自己成为了Leader。
(些消息的传递就是通过发布/订阅模式实现的)
每个节点在一个term内只能投一票，采取先到先得的策略，Candidate前面说到已经投给了自己，
Follower会投给第一个收到RequestVote的节点。
Raft协议的定时器采取随机超时时间，这是选举Leader的关键。
在同一个term内，先转为Candidate的节点会先发起投票，从而获得多数票。
即谁先成为选举人，谁就最有可能成为Leader。
Sentinel的leader选举流程
-
某Sentinel认定master客观下线后，该Sentinel会先看看自己有没有投过票，如果自己已经投过票给其他Sentinel了，在一定时间内自己就不会成为Leader。
-
如果该Sentinel还没投过票，那么它就成为Candidate。
-
Sentinel需要完成几件事情：
- 更新故障转移状态为start
- 当前epoch加1，相当于进入一个新term，在Sentinel中epoch就是Raft协议中的term。
- 向其他节点发送 is-master-down-by-addr 命令请求投票。命令会带上自己的epoch。
- 给自己投一票（leader、leader_epoch）
-
当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；（通过判断epoch）
-
Candidate会不断的统计自己的票数，直到他发现认同他成为Leader的票数超过一半而且超过它配置的quorum，这时它就成为了Leader。
-
其他Sentinel等待Leader从slave选出master后，检测到新的master正常工作后，就会去掉客观下线的标识。
故障转移
当选举出Leader Sentinel后，Leader Sentinel会对下线的主服务器执行故障转移操作，主要有三个步骤：
- 它会将失效 Master 的其中一个 Slave 升级为新的 Master , 并让失效 Master 的其他 Slave 改为复制新的 Master ；
- 当客户端试图连接失效的 Master 时，集群也会向客户端返回新 Master 的地址，使得集群可以使用现在的 Master 替换失效 Master 。
- Master 和 Slave 服务器切换后， Master 的 redis.conf 、 Slave 的 redis.conf 和 sentinel.conf 的配置文件的内容都会发生相应的改变，即， Master 主服务器的 redis.conf 配置文件中会多一行 replicaof 的配置， sentinel.conf 的监控目标会随之调换。
主服务器的选择
哨兵leader根据以下规则从客观下线的主服务器的从服务器中选择出新的主服务器。
- 过滤掉主观下线的节点
- 选择slave-priority最高的节点，如果由则返回没有就继续选择
- 选择出复制偏移量最大的系节点，因为复制偏移量越大则数据复制的越完整，如果由就返回了，没有就继续
- 选择run_id最小的节点，因为run_id越小说明重启次数越少
154
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
