本文主要是介绍Redis(二)：主从、哨兵、集群，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

5 主从同步

Redis 单节点存在单点故障问题，为了解决单点问题，一般都需要对 Redis 配置从节点，然后使用哨兵来监听主节点的存活状态，如果主节点挂掉，从节点能继续提供缓存功能。

5.1. Redis 主从复制简介

Redis 支持将数据同步到多台从库上，这种特性对提高读取性能非常有益。

1) master 可以有多个 slave。

2) 除了多个 slave 连到相同的 master 外，slave 也可以连接其它 slave 形成图状结构。

3) 主从复制不会阻塞 master。也就是说当一个或多个 slave 与 master 进行初次同步数据时，master 可以继续处理客户端发来的请求。相反 slave 在初次同步数据时则会阻塞，不能处理客户端的请求。

4) 主从复制可以用来提高系统的可伸缩性，我们可以用多个 slave 专门用于客户端的读请求，比如 sort 操作可以使用 slave 来处理，也可以用来做简单的数据冗余。

5) 可以在 master 禁用数据持久化，只需要注释掉 master 配置文件中的所有 save 配置，然后只在 slave 上配置数据持久化。

5.2. Redis 主从架构搭建

修改redis.conf，配置主从复制

#Redis 5.0之前
#slaveof 192.168.1.1 6379 #指定 master 的 ip 和端口
​
#Redis 5.0之后
replicaof 192.168.1.1 6379 # 从192.168.1.1 6379的redis实例复制数据
replica‐read‐only yes # 配置从节点只读 

5.3. Redis 主从复制的过程介绍

Redis 2.8 之前使用 sync runId offset同步命令，Redis 2.8 之后使用 psync runId offset命令。两者不同在于，Sync 命令仅支持全量复制过程，Psync 支持全量和部分复制。

• runId：每个 Redis 节点启动都会生成唯一的 uuid，每次 Redis 重启后，runId 都会发生变化。

• offset：主节点和从节点都各自维护自己的主从复制偏移量 offset，当主节点有写入命令时，offset=offset+命令的字节长度。

  从节点在收到主节点发送的命令后，也会增加自己的 offset，并把自己的 offset 发送给主节点。

  这样，主节点同时保存自己的 offset 和从节点的 offset，通过对比 offset 来判断主从节点数据是否一致。

• repl_backlog_size：保存在主节点上的一个固定长度的先进先出队列，默认大小是 1MB。

Psync 的执行流程，从节点发送 psync runId offset命令，主节点有三种响应：

• FULLRESYNC：第一次连接，进行全量复制

• CONTINUE：进行部分复制

• ERR：不支持 psync 命令，进行全量复制

5.3.1 全量复制

1 当设置好 slave 服务器后，slave 会建立和 master 的长连接，然后发送 psync runId offset 命令同步数据；

（第一次发送psync ? -1 命令，不知道主节点的 runId，所以为?，因为是第一次复制，所以 offset=-1。主节点发现从节点是第一次复制，返回 FULLRESYNC {runId} {offset}，runId 是主节点的 runId，offset 是主节点目前的 offset。从节点接收主节点信息后，保存到 info 中。）

2 无论是第一次同步建立的连接还是连接断开后的重新连接，master 都会启动一个后台进程，执行bgsave将数据库rdb快照保存到文件中，同时 master 主进程会开始收集新的写命令并缓存起来；

3 后台进程完成写文件后，master 就发送文件给 slave；

4 slave 将文件保存到磁盘上，清理自己的数据库数据，然后加载到内存恢复数据库rdb快照到 slave 上；

5 接着 master 就会把缓存的命令转发给 slave；

6 执行buffer里的写命令到内存；

7 后续 master 收到的写命令都会通过开始建立的长连接发送给slave。

从master到slave的同步数据的命令和从客户端发送的命令使用相同的协议格式。

当 master 和 slave 的连接断开时， slave 可以自动重新建立连接。如果 master 同时收到多个 slave 发来的同步连接命令，只会启动一个进程来写数据库镜像，然后发送给所有 slave。

5.3.2 断点续传

当master和slave断开重连后，一般都会对整份数据进行复制。但从redis2.8版本开始，redis改用可以支持部分数据复制的命令PSYNC去master同步数据，slave与master能够在网络连接断开重连后只进行部分数据复制(断点续传)。

master会在其内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它所有的slave都维护了复制的数据下标offset和master的进程id，因此，当网络连接断开后，slave会请求master继续进行未完成的复制，从所记录的数据下标offset开始。

如果master进程id变化了，或者从节点数据下标offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。

5.3.3 主从复制风暴

如果有很多从节点，为了缓解主从复制风暴(多个从节点同时复制主节点导致主节点压力过大)，可以让部分从节点与从节点(与主节点同步)同步数据

5.4 主从复制的问题

单纯的主从架构，一旦主节点宕机，把从节点配置成为新的主节点，需要修改客户端的主节点地址，还需要命令所有从节点去复制新的主节点，整个过程需要人工干预。

在哨兵架构下，当主节点宕机，基本上不用人工干预，自动恢复。

6 哨兵

6.1 哨兵架构

搭建几个新的redis实例，作为sentinel哨兵。sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。

哨兵架构下client端不再直接连接主节点，而是连接哨兵服务，哨兵监听所有的节点信息，所以哨兵会把主节点信息返回给client。client端第一次拿到主节点信息后 ，之后就直接访问主节点。

当哨兵发现主节点宕机后，会自动选举新的主节点，并把新的主节点信息推送给client端。redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息。

6.2 哨兵架构搭建

1、复制一份sentinel.conf文件 
cp sentinel.conf sentinel‐26379.conf 
​
2、将相关配置修改为如下值： 
port 26379 6 daemonize yes 
pidfile "/var/run/redis‐sentinel‐26379.pid" 
logfile "26379.log" 
dir "/usr/local/redis‐5.0.3/data" 
# sentinel monitor <master‐redis‐name> <master‐redis‐ip> <master‐redis‐port> <quorum>
# quorum是一个数字，指明当有多少个sentinel认为一个master失效时(值一般为：sentinel总数/2 + 1)，master才算真正失效 
sentinel monitor mymaster 192.168.0.60 6379 2 # mymaster这个名字随便取，客户端访问时会用到
​
3、启动sentinel哨兵实例 
src/redis‐sentinel sentinel‐26379.conf 
​
4、查看sentinel的info信息 
src/redis‐cli ‐p 26379 
127.0.0.1:26379>info 
可以看到Sentinel的info里已经识别出了redis的主从 
​
可以自己再配置两个sentinel，端口26380和26381，注意上述配置文件里的对应数字都要修改

6.3 哨兵工作原理

1.每个 Sentinel 以每秒一次的频率，向它所知的主服务器、从服务器以及其他的 Sentinel 实例发送一个 PING 命令

2.如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 所指定的值，那么这个实例会被 Sentinel 标记为主观下线

3.如果一个主服务器被标记为主观下线，那么正在监视这个服务器的所有 Sentinel 节点，要以每秒一次的频率确认主服务器的确进入了主观下线状态

4.如果一个主服务器被标记为主观下线，并且有足够数量的 Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个主服务器被标记为客观下线

5.一般情况下，每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。当一个主服务器被标记为客观下线时，Sentinel 向下线主服务器的所有从服务器发送 INFO 命令的频率，会从 10 秒一次改为每秒一次。

6.Sentinel 和其他 Sentinel 协商客观下线的主节点的状态，如果处于 SDOWN 状态，则投票自动选出新的主节点，将剩余从节点指向新的主节点进行数据复制

7.当没有足够数量的 Sentinel 同意主服务器下线时，主服务器的客观下线状态就会被移除。当主服务器重新向 Sentinel 的 PING 命令返回有效回复时，主服务器的主观下线状态就会被移除。

7 集群

7.1 集群架构

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率

redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。Redis集群不需要sentinel哨兵∙也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单

7.2 集群搭建

redis集群需要至少三个master节点，搭建三个master节点，并且给每个master再搭建一个slave节点，总共6个redis节点，这里用三台机器部署6个redis实例，每台机器一主一从，搭建集群的步骤如下：

第一步：在第一台机器的/usr/local下创建文件夹redis‐cluster，然后在其下面分别创建2个文件夾如下 
​
（1）mkdir ‐p /usr/local/redis‐cluster 
​
（2）mkdir 8001 8004 
​
第一步：把之前的redis.conf配置文件copy到8001下，修改如下内容： 
​
（1）daemonize yes 
​
（2）port 8001（分别对每个机器的端口号进行设置） 
​
（3）pidfile /var/run/redis_8001.pid # 把pid进程号写入pidfile配置的文件 
​
（4）dir /usr/local/redis‐cluster/8001/（指定数据文件存放位置，必须要指定不同的目录位置，不然会 
​
丢失数据） 
​
（5）cluster‐enabled yes（启动集群模式） 
​
（6）cluster‐config‐file nodes‐8001.conf（集群节点信息文件，这里800x最好和port对应上） 
​
（7）cluster‐node‐timeout 10000 
​
（8）# bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通 
​
过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可） 
​
(9)protected‐mode no （关闭保护模式） 
​
(10)appendonly yes 
​
如果要设置密码需要增加如下配置： 
​
(11)requirepass zhuge (设置redis访问密码) 
​
(12)masterauth zhuge (设置集群节点间访问密码，跟上面一致) 
​
第三步：把修改后的配置文件，copy到8004，修改第2、3、4、6项里的端口号，可以用批量替换： 
​
:%s/源字符串/目的字符串/g 
​
第四步：另外两台机器也需要做上面几步操作，第二台机器用8002和8005，第三台机器用8003和8006 
​
第五步：分别启动6个redis实例，然后检查是否启动成功 
​
（1）/usr/local/redis‐5.0.3/src/redis‐server /usr/local/redis‐cluster/800*/redis.conf 
​
（2）ps ‐ef | grep redis 查看是否启动成功 
​
第六步：用redis‐cli创建整个redis集群(redis5以前的版本集群是依靠ruby脚本redis‐trib.rb实现) 
​
下面命令里的1代表为每个创建的主服务器节点创建一个从服务器节点 
​
#执行这条命令需要确认三台机器之间的redis实例要能相互访问，可以先简单把所有机器防火墙关掉，如果不 
​
#关闭防火墙则需要打开redis服务端口和集群节点gossip通信端口16379(默认是在redis端口号上加1W) 
​
#关闭防火墙 
​
#systemctl stop firewalld # 临时关闭防火墙 
​
#systemctl disable firewalld # 禁止开机启动 
​
#注意：下面这条创建集群的命令大家不要直接复制，里面的空格编码可能有问题导致创建集群不成功 
​
（1）/usr/local/redis‐5.0.3/src/redis‐cli ‐a zhuge ‐‐cluster create ‐‐cluster‐replicas 1 1 
​
92.168.0.61:8001 192.168.0.62:8002 192.168.0.63:8003 192.168.0.61:8004 192.168.0.62:8005 192. 
​
168.0.63:8006 
​
第七步：验证集群：39 （1）连接任意一个客户端即可：./redis‐cli ‐c ‐h ‐p (‐a访问服务端密码，‐c表示集群模式，指定ip地址和端口号） 
​
如：/usr/local/redis‐5.0.3/src/redis‐cli ‐a zhuge ‐c ‐h 192.168.0.61 ‐p 800* 
​
（2）进行验证： cluster info（查看集群信息）、cluster nodes（查看节点列表） 
​
（3）进行数据操作验证 
​
（4）关闭集群则需要逐个进行关闭，使用命令： 
​
/usr/local/redis‐5.0.3/src/redis‐cli ‐a zhuge ‐c ‐h 192.168.0.60 ‐p 800* shutdown 

7.3 集群原理分析

Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。

当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个 key 时，可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整。

槽位定位算法

Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位。

HASH_SLOT = CRC16(key) mod 16384

Redis集群选举原理分析

当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master可能会有多个slave，从而存在多个slave竞争成为master节点的过程， 其过程如下：

1.slave发现自己的master变为FAIL

2.将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST 信息3.其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack

4.尝试failover的slave收集master返回的FAILOVER_AUTH_ACK

5.slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举成功的)

6.slave广播Pong消息通知其他集群节点。

从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举，而是有一定延迟，一定的延迟确保我们等待FAIL状态在集群中传播，slave如果立即尝试选举，其它masters或许尚未意识到FAIL状态，可能会拒绝投票

•延迟计算公式：

DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms

•SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方

式下，持有最新数据的slave将会首先发起选举（理论上）。

集群脑裂数据丢失问题

redis集群没有过半机制会有脑裂问题，网络分区导致脑裂后多个主节点对外提供写服务，一旦网络分区恢复，会将其中一个主节点变为从节点，这时会有大量数据丢失。

规避方法可以在redis配置里加上参数(这种方法不可能百分百避免数据丢失，参考集群leader选举机制)：

min‐replicas‐to‐write 1 //写数据成功最少同步的slave数量，这个数量可以模仿大于半数机制配置，比如集群总共三个节点可以配置1，加上leader就是2，超过了半数

注意：这个配置在一定程度上会影响集群的可用性，比如slave要是少于1个，这个集群就算leader正常也不能提供服务了，需要具体场景权衡选择。

Redis集群为什么至少需要三个master节点，并且推荐节点数为奇数？

因为新master的选举需要大于半数的集群master节点同意才能选举成功，如果只有两个master节点，当其中一个挂了，是达不到选举新master的条件的。

奇数个master节点可以在满足选举该条件的基础上节省一个节点，比如三个master节点和四个master节点的集群相比，大家如果都挂了一个master节点都能选举新master节点，如果都挂了两个master节点都没法选举新master节点了，所以奇数的master节点更多的是从节省机器资源角度出发说的。

这篇关于Redis(二)：主从、哨兵、集群的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！