Redis主从复制与哨兵模式

最新推荐文章于 2024-08-13 17:55:06 发布

liucy007

最新推荐文章于 2024-08-13 17:55:06 发布

阅读量384

点赞数

分类专栏： Redis 文章标签： redis 服务器数据库

本文链接：https://blog.csdn.net/liucy007/article/details/121201210

版权

Redis 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

一，主从复制

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

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

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

作用
1，读写分离
一主多从，主从同步
主负责写，从负责读
提升Redis的性能和吞吐量
主从的数据一致性问题
2，数据容灾
从机是主机的备份
主机宕机，从机可读不可写
默认情况下主机宕机后，从机不可为主机
利用哨兵可以实现主从切换，做到高可用

新版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：从服务器当前的复制偏移量

主要作用有三个：

1. 检测主从的连接状态
replconf ack <replication_offset>
#ack :应答
#replication_offset：从服务器当前的复制偏移量检测主从服务器的网络连接状态通过向主服务器发送INFO replication命令，可以列出从服务器列表，可以看出从最后一次向主发送命令距离现在过了多少秒。lag的值应该在0或1之间跳动，如果超过1则说明主从之间的连接有故障。
2. 辅助实现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值。
3. 检测命令丢失
如果因为网络故障，主服务器传播给从服务器的写命令在半路丢失，那么当从服务器向主服务器发送REPLCONF ACK命令时，主服务器将发觉从服务器当前的复制偏移量少于自己的复制偏移量，然后主服务器就会根据从服务器提交的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数
据，并将这些数据重新发送给从服务器。（补发）网络不断增量同步：网断了，再次连接时

哨兵模式

哨兵（sentinel）是Redis的高可用性(High Availability)的解决方案：
由一个或多个sentinel实例组成sentinel集群可以监视一个或多个主服务器和多个从服务器。当主服务器进入下线状态时，sentinel可以将该主服务器下的某一从服务器升级为主服务器继续提供服务，从而保证redis的高可用性。
部署方案
在这里插入图片描述
搭建配置
在一台机器上采用伪分布式的方式部署。（生产环境应该是多台机器）
根据上面的部署方案搭建如下：
采用安装的方式，正常安装和配置
Redis-Master ：127.0.0.1 6379

#1 安装redis5.0
mkdir redis-master
cd /var/redis-5.0.5/src/
make install PREFIX=/var/redis-ms/redis-master
cp /var/redis-5.0.5/redis.conf /var/redis-ms/redis-master/bin
#2 修改redis.conf
# 将`daemonize`由`no`改为`yes`
daemonize yes
# 默认绑定的是回环地址，默认不能被其他机器访问
# bind 127.0.0.1
# 是否开启保护模式，由yes该为no
protected-mode no

Redis-Slaver1：127.0.0.1 6380

#安装redis-slaver1
mkdir redis-slaver1
cp -r /var/redis-ms/redis-master/* /var/redis-ms/redis-slaver1
#修改配置文件
vim /var/redis-ms/redis-slaver1/redis.conf
port 6380
replicaof 127.0.0.1 6379

Redis-Slaver2：127.0.0.1 6381

#安装redis-slaver2
mkdir redis-slaver2
cp -r /var/redis-ms/redis-master/* /var/redis-ms/redis-slaver2
#修改配置文件
vim /var/redis-ms/redis-slaver2/redis.conf
port 6381
replicaof 127.0.0.1 6379

Redis-Sentinel1:127.0.0.1 26379

#安装redis-sentinel1
mkdir redis-sentinel1
cp -r /var/redis-ms/redis-master/* /var/redis-ms/redis-sentinel1
#拷贝sentinel.conf 配置文件并修改
cp /var/redis-5.0.5/sentinel.conf /var/redis-ms/redis-sentinel1
# 哨兵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

Redis-Sentinel2:127.0.0.1 26380

#安装redis-sentinel2
mkdir redis-sentinel2
cp -r /var/redis-ms/redis-sentinel1/* /var/redis-ms/redis-sentinel2
#修改sentinel.conf
vim /var/redis-ms/redis-sentinel2/sentinel.conf
port 26380

Redis-Sentinel3:127.0.0.1 26381

#安装redis-sentinel3
mkdir redis-sentinel3
cp -r /var/redis-ms/redis-sentinel1/* /var/redis-ms/redis-sentinel3
#修改sentinel.conf
vim /var/redis-ms/redis-sentinel3/sentinel.conf
port 26381

在这里插入图片描述

执行流程

启动并初始化Sentinel
Sentinel是一个特殊的Redis服务器不会进行持久化
Sentinel实例启动后
每个Sentinel会创建2个连向主服务器的网络连接
命令连接：用于向主服务器发送命令，并接收响应；
订阅连接：用于订阅主服务器的—sentinel—:hello频道。
在这里插入图片描述
获取主服务器信息
Sentinel默认每10s一次，向被监控的主服务器发送info命令，获取主服务器和其下属从服务器的信息。

127.0.0.1:6379> info

获取从服务器信息
当Sentinel发现主服务器有新的从服务器出现时，Sentinel还会向从服务器建立命令连接和订阅连接。
在命令连接建立之后，Sentinel还是默认10s一次，向从服务器发送info命令，并记录从服务器的信息。
在这里插入图片描述
向主服务器和从服务器发送消息(以订阅的方式)
默认情况下，Sentinel每2s一次，向所有被监视的主服务器和从服务器所订阅的—sentinel—:hello频道上发送消息，消息中会携带Sentinel自身的信息和主服务器的信息。
接收来自主服务器和从服务器的频道信息
当Sentinel与主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅连接，向服务器发送以下命令：

subscribe —sentinel—:hello

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

检测主观下线状态
Sentinel每秒一次向所有与它建立了命令连接的实例(主服务器、从服务器和其他Sentinel)发送PING命令
实例在down-after-milliseconds毫秒内返回无效回复(除了+PONG、-LOADING、-MASTERDOWN外)
实例在down-after-milliseconds毫秒内无回复（超时）
Sentinel就会认为该实例主观下线(SDown)
检查客观下线状态
当一个Sentinel将一个主服务器判断为主观下线后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选举
1，系统启动后，全部节点初始化为Follower，term为0。
2，节点如果收到了RequestVote或者AppendEntries，就会保持自己Follower身份
3，节点如果一段时间内没收到AppendEntries消息，在该节点的超时时间内还没发现Leader，Follower就会转换成Candidate，自己开始竞选Leader。
一旦转化为Candidate，该节点立即开始下面几件事情：
（1）增加自己的term。
（2）启动一个新的定时器。
（3）给自己投一票。
（4）向所有其他节点发送RequestVote，并等待其他节点的回复。
（5）如果在计时器超时前，节点收到多数节点的同意投票，就转换成Leader。同时向所有其他节点发送AppendEntries，告知自己成为了Leader。
（6）每个节点在一个term内只能投一票，采取先到先得的策略，Candidate前面说到已经投给了自己，
（7）Follower会投给第一个收到RequestVote的节点。
（8）Raft协议的定时器采取随机超时时间，这是选举Leader的关键。
在同一个term内，先转为Candidate的节点会先发起投票，从而获得多数票。

Sentinel的leader选举流程

1、某Sentinel认定master客观下线后，该Sentinel会先看看自己有没有投过票，如果自己已经投过票给其他Sentinel了，在一定时间内自己就不会成为Leader。
2、如果该Sentinel还没投过票，那么它就成为Candidate。
3、Sentinel需要完成几件事情：
（1）更新故障转移状态为start
（2）当前epoch加1，相当于进入一个新term，在Sentinel中epoch就是Raft协议中的term。
（3）向其他节点发送 is-master-down-by-addr 命令请求投票。命令会带上自己的epoch。
（4）给自己投一票（leader、leader_epoch）
4、当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；（通过判断epoch）
5、Candidate会不断的统计自己的票数，直到他发现认同他成为Leader的票数超过一半而且超过它配置的quorum（法定人数），这时它就成为了Leader。
6、其他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 的监控目标会随之调换。