1、简介

Redis中的高可用方案其实有以下集中：

• 1、Redis主从复制（一主一从，一主多从）
• 2、Redis主从复制+哨兵模式（比如：一主+两从+三哨兵）
• 3、Redis集群模式（下一篇文章编写）
• 4、Redis集群+主从模式（下一篇文章编写）

Redis主从复制，主要是为了做读写分离，写数据从主库操作，读数据从从库读取。但是普通的主从如果主服务器挂了，从服务器不会自动切换为主服务器。

Redis主从复制 +哨兵模式就是解决主服务器挂掉之后，哨兵监控到挂了之后，重新发起选举操作，让某台从服务器变为主服务器。从而继续提供服务。

Redis集群模式，就是将数据分片存储到不同的服务器，真正的达到了分布式存储，不像主从复制一样，存在存储上限。但是集群之后每个节点如果挂掉，存储的数据就会丢失。

Redis集群+主从模式，集群的每一个节点下面，都可以挂多台从服务器，从而让每个节点都是高可用的。

这些模式后面会一一讲到。

2、Redis主从复制

Redis是支持主从复制的，Redis开启主从复制的方式

• 1、通过执行slaveof命令(Redis5.0之后改成了replicaof)开启主从复制.
• 2、在配置文件中配置slaveof(Redis5.0之后改成了replicaof)开启主从复制

主从复制部署图

2.1、主从配置

首先我们需要安装主服务器redis

下载编译redis

# 下载
wget http://download.redis.io/releases/redis-5.0.0.tar.gz

# 解压
tar -zxvf redis-5.0.0.tar.gz

# 创建一主一从文件夹
mkdir master_slave_01

# 创建目录，并编译
mkdir -p /opt/redis/baseredis
make install PREFIX=/opt/redis/baseredis

# 复制一份编译好的命令，分别作为主从
cp -r /opt/redis/baseredis /opt/redis/master_slave_01/master
cp -r /opt/redis/baseredis /opt/redis/master_slave_01/slave

# 复制配置文件
cp /opt/redis/redis-5.0.0/redis.conf /opt/redis/master_slave_01/master/redis.conf
cp /opt/redis/redis-5.0.0/redis.conf /opt/redis/master_slave_01/slave/redis.conf

# 防火墙添加端口 并重启生效
firewall-cmd --zone=public --add-port=6379/tcp --permanent
firewall-cmd --zone=public --add-port=6380/tcp --permanent
systemctl restart firewalld.service

2.1.1、主Redis配置

可以设置后台启动，密码等，因为redis不设置密码，并且开放到外网的话是非常危险的，很容易导致被黑客攻击。所以我们这里会设置密码

# 注释掉bind 127.0.0.1

# 开启守护进程模式 后台启动
daemonize yes

# 开启保护模式
protected-mode yes

# 主服务器设置密码
requirepass abcAbc123.

2.1.2、从Redis配置

# 注释掉bind 127.0.0.1
### 跟主服务器一样的修改部分+以下部分

# 修改端口
port 6380

# 配置主从复制
# replicaof <masterip> <masterport> 主服务器IP和端口
replicaof 10.0.0.5 6379

# masterauth <master-password> 主服务器密码
masterauth abcAbc123.

启动主从

cd /opt/redis/master_slave_01

# 启动主从服务
cd /opt/redis/master_slave_01/master && ./bin/redis-server redis.conf
cd /opt/redis/master_slave_01/slave && ./bin/redis-server redis.conf

查看进程

[root@VM-0-5-centos slave]# ps -ef |grep redis
root     23130     1  0 22:45 ?        00:00:00 ./bin/redis-server *:6379
root     23260     1  0 22:45 ?        00:00:00 ./bin/redis-server *:6380
root     23290 27887  0 22:45 pts/0    00:00:00 grep --color=auto redis

主从测试

# 连接主服务器 做写操作
[root@VM-0-5-centos master]# ./bin/redis-cli -h 10.0.0.5 -p 6379
# 首先我们一个key的值，发现需要认证，说明我们的密码生效了
10.0.0.5:6379> set name test_zhangsan
(error) NOAUTH Authentication required.
10.0.0.5:6379> auth abcAbc123.
OK
10.0.0.5:6379> set name test_zhangsan
OK

# 在从服务器查询
[root@VM-0-5-centos slave]# ./bin/redis-cli -h 10.0.0.5 -p 6380
# 不认证之前获取数据
10.0.0.5:6380> get name
(error) NOAUTH Authentication required.

# 认证之后后去数据
10.0.0.5:6380> auth abcAbc123.
OK
10.0.0.5:6380> get name
"test_zhangsan"

主从复制操作就结束了，接下来看一下主从复制到底是个什么原理。

2.3、主从复制原理

配置主从很简单，主服务器不用做过多的变更。

2.3.1、从服务器保存主服务器信息

当客户端向从服务器发送slaveof（replicaof）主机地址（127.0.0.1） 端口（6379）时，从服务器将主服务器ip 端口保存到redisServer的masterhost和masterport中。

struct redisServer {
    char *masterhost;               /* master主服务器IP地址 */
    int masterport;                 /* master主服务器端口号 */
}    

从服务器向发送slaveof命令的客户端返回一个OK，表示复制指令已经被接受，而实际上复制是在返回OK之后进行的。

2.3.2、从服务器与主服务器建立socket连接

从服务器(slave)保存主服务器(master)信息之后，就会与master建立连接。用于传输命令/RDB文件，接受来自master传播过来的写命令。

主服务器接受(accept)了从服务器的连接后，会创建相应的客户端状态，就相当于从服务器是主服务器的客户端。

2.3.3、发送ping/pong检查网络状态

slave向master发送ping命令，master回应一个pong，表示正常，返回错误，则表示master不正常，返回timeout，说明网络超时。

2.3.4、验证密码

如果主服务器没有使用requirepass设置密码，则无需设置masterauth（主服务器密码）。

如果主服务器使用requirepass设置密码了，则需要设置masterauth（主服务器密码），跟requirepass的值保持一致。或者使用auth向主服务器发送命令。

2.3.4、向主服务器发送从服务器的监听端口

在验证密码结束之后，从服务器将会执行命令replconf 监听端口，向主服务器发送从服务器监听的端口号。

2.3.5、数据同步复制与命令传播

同步数据指的是第一次开启主从复制之后，会把已经存在的数据一次性全部同步给从服务器(包括全量和增量同步)，同步结束之后，每执行一个命令就会斤西瓜同步，也就是命令传播阶段。

Redis 2.8之前只有全量同（使用sync命令同步, redis 2.8之后使用psync命令代替sysnc）步，之后就增加了增量同步。

Redis2.8之前的数据同步

• 1、通过从服务器发送sync命令给主服务器
• 2、主服务器生成rdb文件并发送给从服务器，同时发送发送期间产生的写命令发送给从服务器
• 3、从服务器清空之前的数据，然后解析执行RDB文件

Redis2.8之前的命令传播

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

这种方式，没有增量和全量的说法，每次从服务器同步数据时，都会先清空从服务器原来的所有数据。

Redis2.8之后的数据同步

Redis 2.8之后使用psync命令，它具备了全量同步和增量同步模式。 只有从服务器第一次连接主服务器时才会全量同步。断线重连有可能触发增量和全量(断开时还没同步数据，就相当于重新全量同步)。

全量同步

• 1、同步快照阶段：master创建并发送rdb快照给slave，slave载入并解析rdb文件。master将此阶段产生的新写命令存储到缓冲区。
• 2、同步写缓冲区阶段：master向slave同步在缓冲区的写操作命令。
• 3、同步增量阶段：master向slave同步写操作命令

增量同步

Redis的增量同步主要是指slave完成初始化之后开始正常工作时，master发生的写操作同步到slave的过程，一般是，master每执行一个写命令，就发送给slave相同的命令，然后slave执行，也就是命令传播。

2.4、心跳检测

在命令传播阶段，从服务器会以每秒一次的频率向主服务器发送命令。

#ack 应答 replication_offset 从服务器当前的复制偏移量
replconf <replication_offset> 

replconf ack作用

• 1、检查主从的连接状态，向主服务器发送info replication命令，列出从服务器列表，可以看出最后一次发送命令的时间。和当前时间超过1表示超过1s没有连接上，就判定连接有故障。
• 2、辅助实现min-slaves，redis可盈通过配置防止主服务器在不安全情况下执行写命令。

# 从服务器的数量少于3个
min-replicas-to-write 3
# 三个从服务器的延迟（lag）值都大于或等于10s
min-replicas-max-lag 10

从服务器满足以上任意请求，主服务器就会拒绝执行写命令。

• 3、检测命令丢失
• 因为网络故障，主服务器传播给从服务器的命令可能丢失，从服务器发送replconf ack时，主服务器发现从服务器当前的复制偏移量少于自己的偏移量，然后主服务器根据从服务器提交的偏移量，在复制积压缓冲区中找到从服务器缺少的数据，并将这些数据补发给从服务器。

3、哨兵模式

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

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

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

3.1、搭建哨兵模式

# 复制一份一主一从
cp master_slave_01/ master_slave_02 -r

cd master_slave_02

mv slave slave1

cp -r slave1 slave2

编辑slave2中的redis.conf文件，修改端口为6381.

准备哨兵

# 复制一份master的数据
cp /opt/redis/redis-5.0.0/sentinel.conf sentinel1/

# 复制一份sentinel.conf 
cp /opt/redis/redis-5.0.0/sentinel.conf sentinel1/

修改sentinel.conf

# 开启保护模式
protected-mode yes

# 设置端口 默认26379
port 26379

# 开启后台模式
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 10.0.0.5 6379 2

# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提 供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster abcAbc123.

# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000

# 这个配置项指定了在发生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

启动主从和哨兵

cd /opt/redis/master_slave_02/master/ ; ./bin/redis-server redis.conf
cd /opt/redis/master_slave_02/slave1/ ; ./bin/redis-server redis.conf
cd /opt/redis/master_slave_02/slave2/ ; ./bin/redis-server redis.conf

cd /opt/redis/master_slave_02/sentinel1/ ; ./bin/redis-sentinel sentinel.conf
cd /opt/redis/master_slave_02/sentinel2/ ; ./bin/redis-sentinel sentinel.conf
cd /opt/redis/master_slave_02/sentinel3/ ; ./bin/redis-sentinel sentinel.conf

查看启动状态

[root@VM-0-5-centos sentinel3]# ps -ef |grep redis
root     23130     1  0 Sep06 ?        00:00:58 ./bin/redis-server *:6379
root     23260     1  0 Sep06 ?        00:01:00 ./bin/redis-server *:6380
root     23457     1  0 21:59 ?        00:00:00 ./bin/redis-server *:6381
root     23639     1  0 22:00 ?        00:00:00 ./bin/redis-sentinel *:26379 [sentinel]
root     23677     1  0 22:00 ?        00:00:00 ./bin/redis-sentinel *:26380 [sentinel]
root     23700     1  0 22:00 ?        00:00:00 ./bin/redis-sentinel *:26381 [sentinel]
root     23722 18174  0 22:00 pts/0    00:00:00 grep --color=auto redis

3.2、Redis哨兵模式原理

3.2.1、初始化sentinel

Sentinel是一个特殊的Redis服务器，它不会进行持久化，sentinel实例化后，每个sentinel会跟主服务器创建两个连接。一个是命令连接，一个是订阅连接。

• 1、命令连接：用于向主服务器发送命令并接受响应
• 2、订阅连接：用于订阅主服务器的--sentinel--频道

3.2.2、获取主从服务器信息

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

# 输入密码
127.0.0.1:6379> auth abcAbc123.
OK
127.0.0.1:6379> info
# Replication 主从复制信息
role:master
connected_slaves:2
slave0:ip=10.0.0.5,port=6380,state=online,offset=237886,lag=1
slave1:ip=10.0.0.5,port=6381,state=online,offset=237886,lag=1
master_replid:9940e7aafe067dc1ebb0f6c9bd70a39df0b29ca6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:238017
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:238017

可以看出，我们有两台从服务器，端口好分别是6380，6381.

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

# Replication 主从复制信息
# 角色为slave
role:slave
# 主服务器ip和端口
master_host:10.0.0.5
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:280900
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:9940e7aafe067dc1ebb0f6c9bd70a39df0b29ca6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:280900
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:280900

sentinel以订阅方式向主从发送信息

默认情况下，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与主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅连接，向服务器发送以下命令。

subscribe —sentinel—:hello

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

3.2.3、sentinel主观/客观下线

Sentinel每秒一次向所有与它建立了命令连接的实例(主服务器、从服务器和其他Sentinel)发送PING命令。实例在down-after-milliseconds毫秒内返回无效回复(除了+PONG、-LOADING、-MASTERDOWN外)，或实例在down-after-milliseconds毫秒内无回复（超时），Sentinel就会认为该实例主观下线(SDown)。

当一个Sentinel将一个主服务器判断为主观下线后，Sentinel会向同时监控这个主服务器的所有其他Sentinel发送查询命令。判断其他sentinel去尝试连接master，根据结果判断它们是否也认为主服务器下线。

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

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

3.2.4、sentinel的leader选举

选举使用的是raft算法，raft算法就是专门来解决分布式一致性问题的一种算法。

Raft描述的节点共有三种状态：Leader, Follower, Candidate。Raft协议将时间切分为一个个的Term（任期），可以认为是一种“逻辑时间”。

raft算法

Raft采用心跳机制触发Leader选举，系统启动后，全部节点初始化为Follower，term为0。

节点如果收到了RequestVote或者AppendEntries，就会保持自己的Follower身份。

节点如果一段时间内没收到AppendEntries消息，在该节点的超时时间内还没发现Leader，Follower就会转换成Candidate，自己开始竞选Leader。

一旦转化为Candidate，该节点立即开始下面几件事情：

• 1、增加自己的term
• 2、启动一个新的定时器
• 3、给自己投一票
• 4、向所有其他节点发送RequestVote，并等待其他节点的回复

如果在计时器超时前，节点收到多数节点的同意投票，就转换成Leader。同时向所有其他节点发送AppendEntries，告知自己成为了Leader。

每个节点在一个term内只能投一票，采取先到先得的策略，Candidate前面说到已经投给了自己， Follower会投给第一个收到RequestVote的节点。

Raft协议的定时器采取随机超时时间，这是选举Leader的关键，在同一个term内，先转为Candidate的节点会先发起投票，从而获得多数票。

选举流程

• 1、某Sentinel认定master客观下线后，该Sentinel会先看看自己有没有投过票，如果自己已经投过票给其他Sentinel了，在一定时间内自己就不会成为Leader。
• 2、如果该Sentinel还没投过票，那么它就成为Candidate
• 3、Sentinel需要完成几件事情
• 更新故障转移状态为start
• 当前epoch加1，相当于进入一个新term，在Sentinel中epoch就是Raft协议中的term
• 向其他节点发送 is-master-down-by-addr 命令请求投票。命令会带上自己的epoch。
• 给自己投一票（leader、leader_epoch）
• 4、当其它哨兵收到此命令时，可以同意或者拒绝它成为leader（通过判断epoch）
• 5、Candidate会不断的统计自己的票数，直到他发现认同他成为Leader的票数超过一半而且超过它配置的quorum，这时它就成为了Leader。
• 6、其他Sentinel等待Leader从slave选出master后，检测到新的master正常工作后，就会去掉客观下线的标识。

3.2.5、sentinel的故障转移

选举之后，新的master出现了，那么就需要将原本指向旧master的从服务器，指向新的master。

• 1、 它会将失效Master的其中一个Slave升级为新的Master , 并让失效Master的其他Slave改为新的Master
• 2、当客户端试图连接失效的Master时，集群也会向客户端返回新Master的地址，使得集群可以使用现在的Master替换失效Master
• 3、Master和Slave服务器切换后，Master和Slave的redis.conf和sentinel.conf配置文件会被修改,就是指向新的master.

4、小结

Redis的主从+哨兵模式，在我们数据量比较小的时候，还是个比较实用的高可用方案。它的优势有哪些呢？

• 1、主服务器负责写，从服务器负责读，实现了读写分离。
• 2、既然读写分离了，通常Redis的读请求远大于写请求，所以多个从节点提升了读性能和读的吞吐量。
• 3、主从复制解决的主从数据一致性问题
• 4、从服务器是主服务器的一个备份，相当于多了一层备份。
• 5、主机宕机，从服务器可读不可写，从服务器不可切换成主服务器，而哨兵模式解决了该问题。

除了总的存储数据受单机限制，主从+哨兵已经可以保证高性能，高可用了。

5、相关文章

本人还写了Redis的其他相关文章，有兴趣的可以点击查看！

• <<Redis弱事务性与Lua脚本原子性分析>>
  
• <<Redis持久化机制分析>>
  
• <<Redis的事件处理机制分析>>
  
• <<Redis客户端和服务端如何通信？>>
  
• <<Redis的淘汰机制分析>>
  
• <<Redis的底层数据结构分析>>
  
• <<Redis的8种数据类型，什么场景使用？>>
  
• <<缓存是什么？缓存有哪些分类？使用它的代价是什么？>>
  
• <<缓存的6种常见的使用场景>>