Redis 实现高可用 主从、哨兵、集群（Cluster）

前言

高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，通常是指，通过设计减少系统不能提供服务的时间。

高可用的工作方式

（1）主从方式 （非对称方式）
工作原理：主机工作，备机处于监控准备状况；当主机宕机时，备机接管主机的一切工作，待主机恢复正常后，按使用者的设定以自动或手动方式将服务切换到主机上运行，数据的一致性通过共享存储系统解决。
（2）双机双工方式（互备互援）
工作原理：两台主机同时运行各自的服务工作且相互监测情况，当任一台主机宕机时，另一台主机立即接管它的一切工作，保证工作实时，应用服务系统的关键数据存放在共享存储系统中。
（3）集群工作方式（多服务器互备方式）
工作原理：多台主机一起工作，各自运行一个或几个服务，各为服务定义一个或多个备用主机，当某个主机故障时，运行在其上的服务就可以被其它主机接管。
---- 以上摘自百度百科

CAP原理

C：Consistency，一致性
A：Availability，可用性
P：Partition tolerance，分区容忍性
CAP 原理总结下来就是：当网络分区发生时，一致性和可用性二者不可得兼。

Redis 的主从数据是异步同步的，所以分布式的 Redis 系统并不满足一致性要求，当客户端在 Redis 的主节点修改了数据后，立即返回，即使在主从网络断开的情况下，主节点依旧可以正常对外提供修改服务，Redis 满足可用性。
Redis 保证最终一致性，从节点会努力追赶主节点，如果网络断开，主从节点的数据将会出现大量不一致，但一旦网络恢复，从节点会采用多种策略努力追赶，继续尽力保持数据和主节点一致。

配置主从

一个 master 节点 两个 slave 节点
部署在不同的机器上，端口都为 6379

节点	角色	IP	端口
node1	主节点	192.168.1.142	6379
node2	从节点	192.168.1.143	6379
node3	从节点	192.168.1.144	6379

主节点配置

bind 0.0.0.0
port 6379
logfile "redis.log"
# 设置 RDB 持久化
dbfilename "dump.rdb"
#启用守护进程
daemonize yes
# 指定存储至本地数据库时是否压缩数据 默认为 yes
rdbcompression yes
# 节点密码
requirepass 123456
# 设置主节点密码 防止 此主节点降为 从节点时 获取不到新的主节点的数据
masterauth 123456

从节点配置

• 配置文件的方式
  在从节点的配置文件 redis.conf 中指定主节点的信息（如主节点的登录密码，主从复制相关的参数）

bind 0.0.0.0
port 6380
logfile "redis.log"
dbfilename "dump.rdb"
daemonize yes
rdbcompression yes
slaveof 192.168.1.142 6379
requirepass 123456
masterauth 123456
# 从redis2.6开始，从节点默认是只读的
slave-read-only yes

可以发现主节点与从节点的配置文件相比 只是多了 slaveof 192.168.1.142 6379 这个配置

• 启动命令中指定
  不在配置文件中配置，使用 redis-server 命令，在启动从节点时，通过参数 -slaveof 指定主节点

./redis-server --slaveof 192.168.1.142 6379

• redis-cli的命令行执行 slaveof
  上面两种方法都可以不用，都采用主节点的配置文件，正常启动 redis，然后通过 redis-cli 的命令行执行 slaveof 192.168.1.142 6379 指定主节点是谁。
  先启动 主节点，再起从节点

./redis-server /usr/local/redis-6.2.5/redis.conf 

系统运行时，如果作为 master 的 node1 挂掉了，可以在 node2 节点上手动执行命令 slaveof no one ，将 node2 变成新的 master；在 node3 上执行 slaveof 192.168.1.34 6380 将这个从节点的主节点指向的这个新的 master 也就是 node2 ；同时，挂掉的原 master 启动后作为新的 slave 也指向新的 master 上

主从模式的拓扑结构

1.一主一从

最简单的拓扑结构，一般适用于没有太大的并发场景。当 master 宕机时， slave 提供故障转移支持

2. 一主多从

适用于并发量较大的场景，一般都是读多写少。客户端可以将读命令发送到 salve 节点 分担 master 节点压力。
实现读写分离架构，当然也保证了高可用。但是该架构需要避免复制风暴。

3.树状结构

slave 节点除了在 master 复制数据，也可以在其他 slave 节点复制数据。 主要是通过引用复制中间层，降低 master 节点的负载和需要传送给从节点的数据量，这种架构可以避免复制风暴，但是延长了数据一致性。

优缺点

优点：
高可靠性：一方面，采用双机主备架构，能够在主库出现故障时进行主备切换，从库提升为主库提供服务，保证服务平稳运行；另一方面，开启数据持久化功能和配置合理的备份策略，能有效的解决数据误操作和数据异常丢失的问题。
读写分离策略：从节点可以扩展主库节点的读能力，有效应对大并发量的读操作。
缺点：
故障恢复复杂，如果没有 Redis HA 系统，当主库节点出现故障时，需要手动将一个从节点晋升为主节点，同时需要通知业务方变更配置，并且需要让其他从库节点去复制新主库节点，整个过程需要人为干预，比较繁琐。

主库的写能力受到单机的限制，可以考虑分片。
主库的存储能力受到单机的限制，可以考虑 Pika。

原生复制的弊端在早期的版本中也会比较突出，如：Redis 复制中断后，Slave 会发起 psync，此时如果同步不成功，则会进行全量同步，主库执行全量备份的同时可能会造成毫秒或秒级的卡顿。

Redis Sentinel（哨兵）

主从模式下，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，造成一段时间内服务不可用。实际生产中，都会考虑使用哨兵模式，一旦 master 宕机，哨兵会自动选举 master 并将其他的 slave 指向新的 master。
Redis Sentinel 是社区版本推出的原生高可用解决方案，其部署架构主要包括两部分：Redis Sentinel 集群和 Redis 数据集群。
其中 Redis Sentinel 集群是由若干 Sentinel 节点组成的分布式集群，可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel 的节点数量要满足 2n+1（n>=1）的奇数个。

哨兵配置文件配置 sentinel.conf

在 /usr/local/redis-6.2.5 中

# 禁止保护模式
protected-mode no
daemonize yes
port 26379
# 配置监听的主服务器，这里sentinel monitor代表监控，mymaster代表服务器的名称，可以自定义，
#192.168.1.142 代表监控的主服务器，6379代表端口，2代表只有两个或两个以上的哨兵认为主服务器不可用的时候，才会进行failover操作。
sentinel monitor mymaster 192.168.1.142 6379 2
# sentinel author-pass 定义服务的密码，mymaster是服务名称，123456是Redis服务器密码
sentinel auth-pass mymaster 123456

启动哨兵

./redis-sentinel /usr/local/redis-6.2.5/sentinel.conf

解决Redis哨兵集群哨兵之间无法感应问题

启动 redis 哨兵集群后 查看sentinel.conf 可以发现

哨兵启动之后，sentinel.conf 配置文件会被自动重写，主要有以下几点：

• 自动移除主节点的密码
• 增加了一个 sentinel myid （唯一标识）
• 追加了 redis 数据服务的 slave 的信息
• 追加了其它哨兵节点的信息

我这里是由于启动了第一个哨兵后，将配置文件复制到另外两台机器上，导致 myid 重复，修改一下 myid 即可。

优缺点

优点
哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
主从可以自动切换，系统更健壮，可用性更高。
缺点
具有主从模式的缺点，每台机器上的数据是一样的，内存的可用性较低。
Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂

Redis Cluster

在大数据高并发场景下，单个 Redis 实例 往往会显得捉襟见肘。首先体现在内存上，单个 Redis 的内存不宜过大，内存太大会导致 rdb 文件过大，进一步导致主从同步时全量同步时间过长，在实例重启恢复时也会消耗很长的数据加载时间，特别是在云环境下，单个实例内存大小往往都是受限的。其次体现在 CPU 的利用率上，单个 Redis 实例只能利用单个核心，单个核心要完成海量数据的存取和管理工作，压力会非常大。

Redis Cluster 是社区版推出的 Redis 分布式集群解决方案，主要解决 Redis 分布式方面的需求，比如，当遇到单机内存，并发和流量等瓶颈的时候，Redis Cluster 能起到很好的负载均衡的目的。

Redis Cluster 集群节点最小配置 6 个节点以上（3 主 3 从），其中主节点提供读写操作，从节点作为备用节点，不提供请求，只作为故障转移使用。

Redis Cluster 采用虚拟槽分区，所有的键根据哈希函数映射到 0～16383 个整数槽内，每个节点负责维护一部分槽以及槽所映射的键值数据

配置 Cluster

机器规划

机器名称	角色	IP	端口
node1	master 1	192.168.1.142	6379
node2	master 2	192.168.1.143	6379
node3	master 3	192.168.1.144	6379
node4	slave 1	192.168.1.148	6379
node5	slave 2	192.168.1.146	6379
node6	slave 3	192.168.1.147	6379

服务器设置

时区调整，时间校准

yum install ntp // 安装ntp服务
systemctl enable ntpd // 开机启动服务
systemctl start ntpd // 启动服务
timedatectl set-timezone Asia/Shanghai // 更改时区
timedatectl set-ntp yes // 启用ntp同步

开启端口

firewall-cmd --list-ports
firewall-cmd --zone=public --add-port=6379/tcp --permanent
firewall-cmd --reload

配置 redis.conf

为了方便后续运维，这里创建一些文件夹，用于存储 redis 在运行中产生的数据

mkdir -p /usr/local/redis-6.2.5/run
mkdir -p /usr/local/redis-6.2.5/log
mkdir -p /usr/local/redis-6.2.5/data
mkdir -p /usr/local/redis-6.2.5/conf

配置 redis.conf 放到 /usr/local/redis-6.2.5/conf 目录

redis.conf 如下

bind 0.0.0.0
port 6379
#pid存储目录
pidfile /usr/local/redis-6.2.5/run/redis_6379.pid 
#日志存储目录  
logfile /usr/local/redis-6.2.5/log/redis_6379.log  
#数据存储目录
dir /usr/local/redis-6.2.5/data/
dbfilename "dump.rdb"
# 节点密码
requirepass 123456
# 设置主节点密码 防止 此主节点降为 从节点时 获取不到新的主节点的数据
masterauth 123456
#守护进程
daemonize yes
# 指定是否在每次更新操作后进行日志记录，防止断电造成数据丢失
appendonly yes
# 指定存储至本地数据库时是否压缩数据，默认为 yes
rdbcompression yes

# 开启redis的集群模式
cluster-enabled yes
#是否需要每个节点都可用，集群才算可用,关闭
cluster-require-full-coverage no
# 配置集群模式下的配置文件名称和位置 nodes-6379.conf 这个文件是集群启动后自动生成的，不需要手动配置。
cluster-config-file nodes-6379.conf

创建 shell 脚本用于启停服务

cd /usr/local/redis-6.2.5/run

启动脚本

# vi cluster_start.sh
../src/redis-server  ../conf/redis.conf
# chmod +x cluster_start.sh

关闭脚本

# vi cluster_shutdown.sh
../src/redis-cli -a 123456 shutdown save  2>/dev/null
# chmod +x cluster_shutdown.sh

启动完毕后，节点 不可用

集群的hash槽没有提供，需要将这些实例合并成一个集群

创建集群

在 redis3.0 和 4.0 版本中，创建集群还是使用 redis-trib.rb 方式去创建，但是在 5.0 之后，可以直接使用 redis-cli 直接创建集群，本文 redis 版本为 6.2.5，所以创建集群的方式为 redis-cli 方式直接创建。

redis-cli --cluster create 192.168.1.142:6379 192.168.1.143:6379 192.168.1.144:6379 192.168.1.148:6379 192.168.1.146:6379 192.168.1.147:6379 -a 123456 --cluster-replicas 1

–cluster-replicas 1 参数表示希望每个主服务器都有一个从服务器，这里则代表 3 主 3 从，前 3 个代表 3 个 master，后 3 个代表 3 个slave

如果 你执行完 这个命令后，日志 一直在 waitting

那么便是由于 redis 集群总线的端口被防火墙拦截了，开启即可

redis 集群总线端口为 redis 端口加上 10000，若 redis 6379 端口为通讯端口，则 16379 端口为集群总线端口

查看集群状态

cluster info

查看集群节点

cluster nodes