第五章 Redis高可用模式解读笔记

一、Redis复制

1. 主从复制

方式1：

新增redis6380.conf，加入slaveof 192.168.30.156 6379，在6379启动完后再启6380，完成配置；

方式2：redis-server --slaveof 192.168.30.156 6379

1）增加从节点配置文件，设置slave-serve-stale-data yes

slave-serve-stale-data参数设置成yes，主从复制中，从服务器可以响应客户端请求；设置成no，主从复制中，从服务器将阻塞所有请求，有客户端请求时返回“SYNC with master in progress”。

2）查看状态：info replication

192.168.30.156:6380> info replication
# Replication
role:slave
master_host:192.168.30.156
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:1
master_link_down_since_seconds:1573808549
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:4f9015872f6c1e91de4dec4684c3f532de1afce3
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
192.168.30.156:6380>

3）断开主从复制：在slave节点，执行：6380:>slaveof no one

192.168.30.156:6380> info replication
# Replication
role:master
connected_slaves:0
master_replid:6bf7dbe431c4fc1e48054e65c8e6e3349f48fd5d
master_replid2:4f9015872f6c1e91de4dec4684c3f532de1afce3
master_repl_offset:0
second_repl_offset:1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
192.168.30.156:6380>

4）断开后再变成主从复制：

6380:> slaveof 192.168.30.156 6379

5）数据较重要的节点，主从复制时使用密码验证：requirepass

6）从节点建议用只读模式slave-read-only=yes

若从节点修改数据，主从数据不一致。

7）传输延迟：

主从一般部署在不同机器上，复制时存在网络延时问题，redis提供repl-disable-tcp-nodelay参数决定是否关闭TCP_NODELAY，默认为关闭。

参数关闭时：无论大小都会及时发布到从节点，占带宽，适用于主从网络好的场景；

参数启用时：主节点合并所有数据成TCP包节省带宽，默认为40毫秒发一次，取决于内核，主从的同步延迟40毫秒，适用于网络环境复杂或带宽紧张，如跨机房。

2、主从拓扑——支持单层或多层

1）一主一从：用于主节点故障转移从节点，当主节点的“写”命令并发高且需要持久化，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免持久化对主节点的影响。

2）一主多从：针对“读”较多的场景，“读”由多个从节点来分担，但节点越多，主节点同步到多节点的次数也越多，影响带宽，也加重主节点的稳定。

 

3）树状主从：一主多从的缺点（主节点推送次数多压力大）可用此方案解决，主节点只推送一次数据到从节点1，再由从节点2推送到11，减轻主节点推送的压力。

 

3、复制原理

执行slave master port后，与主节点连接，同步主节点的数据。

6380:>info replication：查看主从及同步信息

 

4、数据同步

redis 2.8版本以上使用psync命令完成同步，过程分“全量”与“部分”复制。

全量复制：一般用于初次复制场景（第一次建立SLAVE后全量）。

部分复制：网络出现问题，从节占再次连主时，主节点补发缺少的数据，每次数据增加同步。

心跳：主从长连接心跳，主节点默认每10S向从节点发ping命令，repl-ping-slave-period控制发送频率。

二、哨兵机制

1、为什么要讲哨兵机制？

1）我们学习了redis的主从复制，但如果说主节点出现问题不能提供服务，需要人工重新把从节点设为主节点，还要通知我们的应用程序更新了主节点的地址，这种处理方式不是科学的，耗时费事。

2）同时主节点的写能力是单机的，能力能限。

3）而且主节点是单机的，存储能力也有限。

其中 2，3 的问题在后面 redis 集群课会讲，第 1 个问题我们用哨兵机制来解决

2、主从故障如何故障转移(不满足高可用)

• 主节点(master)故障，从节点 slave-1 端执行 slaveof no one 后变成新主节点
• 其它的节点成为新主节点的从节点，并从新节点复制数据

3、哨兵机制(sentinel)的高可用

哨兵原理：

当主节点出现故障时，由redis sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

 

其实整个过程只需要一个哨兵节点来完成，首先使用Raft算法（感兴趣的可以查一下，其实就是个选举算法）实现选举机制，选出一个哨兵节点来完成转移和通知哨兵有三个定时监控任务完成对各节点的发现和监控：

任务1：

每个哨兵节点每10秒会向主节点和从节点发送info命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到。

 

任务2：

每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的。

 

任务3：

每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据。

 

4、主观下线和客观下线：

主观下线：

刚我知道知道哨兵节点每隔1秒对主节点和从节点、其它哨兵节点发送ping做心跳检测，当这些心跳检测时间超过down-after-milliseconds时，哨兵节点则认为该节点错误或下线，这叫主观下线；这可能会存在错误的判断。

 

客观下线：

当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum(法定人数)个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线。