本章学习内容如下
- 什么是 Redis Cluster
- Redis Cluster 配置
- Redis 集群的一些理论知识
- Redis 集群选举的基本原理
在 Redis 3.0 之前的版本想要实现集群一般都是借助哨兵sentinel 工具来监控 master 节点的状态, 如果 master 节点异常, 则会做主从切换, 将某一台 slave 作为 master, 哨兵的配置会略微复杂, 并且性能和高可用性等各方面表现一般, 特别是在主从切换的瞬间存在访问瞬断的情况, 而且哨兵模式只有一个主节点对外提供服务, 没法支持很高的鬓发, 且单个主节点的内存也不宜设置的过大, 否则在做持久化的时候, 文件会特别大, 影响数据恢复或主从同步的效率. 然后Redis在3.0 之后, 提供了 Redis Cluster 集群模式.
访问瞬断: 在哨兵模式中, 当主节点发生故障时, 哨兵会自动将从节点提升为主节点. 在提升过程中, 客户端可能会无法访问 Redis 服务器.
1. 什么是 Redis Cluster
简单来说, Redis 集群是一个由多个主从节点群组成的分布式服务器群, 它具有复制, 高可用和分片特性. Redis 集群不需要哨兵sentine也能完成节点移除和故障转移的功能. 需要将每个节点设置成集群模式, 这种集群模式没有中心节点, 可以水平扩展, 根据官方文档成可以线性扩展到上万个节点(官方推荐不要超过 1000 个节点). Redis 集群的性能和高可用性均优于之前的哨兵sentine 模式, 且集群配置较为简单.
下面用三个虚拟机来配置下. 都是一主一从结构
2. Redis Cluster 配置
- 在
192.168.50.88这台机器上创建文件夹redis-cluster, 然后在其下面分别再创建8001, 8004文件夹
mkdir -p /usr/local/redis-cluster
cd /usr/local/redis-cluster
mkdir 8001
mkdir 8004
- 复制一份
redis.conf配置文件到 8001 下. 修改如下内容
daemonize yes
port 8001 #分别对每个机器的端口号进行设置
pidfile /var/run/redis_8001.pid #把pid进程号写入pidfile配置的文件
dir /usr/local/redis‐cluster/8001/ #指定数据文件存放位置，必须要指定不同的目录位置，不然会 丢失数据
cluster‐enabled yes #启动集群模式
cluster‐config‐file nodes‐8001.conf #集群节点信息文件，这里 800x 最好和 port 对应上
cluster‐node‐timeout 10000
protected‐mode no #关闭保护模式
appendonly yes
#如果要设置密码需要增加如下配置：
requirepass zhangsan #设置redis访问密码
masterauth zhangsan #设置集群节点间访问密码，跟上面一致
# bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通 过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）
- 将 8001 修改后的配置文件复制到 8004下, 并且修改带有端口号的设置.可以批量修改.
#例如要将 8001 全部修改为 8004
:%s/8001/8004/g
- 继续上面的操作,在剩余两台虚拟机上进行操作, 第二台设备是 8002, 8005, 第三台设备是 8003, 8006.
- 分别启动6个
redis实例, 然后检查是否启动成功
/usr/local/src/redis-6.2.14/src/redis-server /usr/local/redis-cluster/8001/redis.conf
/usr/local/src/redis-6.2.14/src/redis-server /usr/local/redis-cluster/8002/redis.conf
/usr/local/src/redis-6.2.14/src/redis-server /usr/local/redis-cluster/8003/redis.conf
/usr/local/src/redis-6.2.14/src/redis-server /usr/local/redis-cluster/8004/redis.conf
/usr/local/src/redis-6.2.14/src/redis-server /usr/local/redis-cluster/8005/redis.conf
/usr/local/src/redis-6.2.14/src/redis-server /usr/local/redis-cluster/8006/redis.conf
然后再检查是否启动成功, 显示以下信息表示启动成功
ps -ef | grep redis
root 7448 1 0 03:50 ? 00:00:00 /usr/local/src/redis-6.2.14/src/redis-server *:8001 [cluster]
root 7455 1 0 03:50 ? 00:00:00 /usr/local/src/redis-6.2.14/src/redis-server *:8004 [cluster]
- 使用
redis-cli创建整个redis集群.
/usr/local/src/redis-6.2.14/src/redis-cli -a zhangsan --cluster create --cluster-replicas 1 192.168.50.88:8001 192.168.50.117:8002 192.168.50.171:8003 192.168.50.88:8004 192.168.50.117:8005 192.168.50.171:8006
# 上面命令中的 1 表示为每个创建的主节点都创建一个从节点.
# 执行这条命令需要确认三台机器之间的redis实例要能相互访问，可以先简单把所有机器防火墙关掉，如果不
# 关闭防火墙则需要打开redis服务端口和集群节点gossip通信端口16379(默认是在redis端口号上加1W)
# systemctl stop firewalld 关闭防火墙
# systemctl disable firewalld # 禁止开机启动
默认将前面
- 验证集群
连接任意一个客户端
/usr/local/src/redis-6.2.14/src/redis‐cli -a zhansgan -c -h 192.168.50.88 -p 8001
进行验证
cluster info 查看集群信息
cluster nodes 查看节点列表
- 关闭集群, 需要逐个进行关闭.
/usr/local/src/redis-6.2.14/src/redis‐cli -a zhansgan -c -h 192.168.50.88 -p 8001 shutdown
3. Redis 集群的一些理论知识
Redis Cluster 将所有的数据划分为 16384 个 slots(槽位), 每个节点负责其中一部分槽位. 槽位的信息存储于每一个节点中.
当 Redis Cluster 的客户端来连接集群时, 它也会得到一份集群的槽位配置信息并将其缓存在客户端本地. 这样当客户端要查找某个 key 时, 可以直接定位到目标节点. 同时因为槽位的信息可能会存在客户端与服务器不一致的情况, 还需要纠正机制来实现槽位信息的校验调整.
3.1 槽位定位算法
Redis Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值. 然后用这个整数值对 16384 进行取模来得到具体的槽位.
HASH_SLOT = CRC16(key) mod 16384
3.2 跳转重定位
当客户端向一个错误的节点发出了指令, 该节点会发现指令的 key 所在的槽位不归自己管理, 这时它会向客户端发送一个特殊的跳转指令并挈带一个目标操作的节点地址, 告诉客户端去连这个节点去获取数据.
客户端收到指令后除了跳转到正确的节点上去操作, 还会同步更新纠正本地的槽位映射表缓存, 后续所有 key 将使用新的槽位映射表
3.3 Redis 集群节点间的通信机制
Redis Cluster 节点间采用的是 gossip 协议进行通信.
维护集群的元数据有两种方式: 集中式和 gossip
元数据包含: 集群的节点信息, 主从角色, 节点数量, 各节点共享的数据等.
-
集中式
- 优点
元数据更新和读取的时效性非常好, 一旦元数据出现变更立即就会更新到集中式的存储中, 其他节点读取的时候立即就可以感知到. - 缺点
所有的元数据的更新压力全部集中在一个地方, 可能导致元数据的存储压力.
- 优点
-
gossip:
gossip协议包含多种消息, 包含ping, pong, meet, fail等.- ping: 每个节点都会频繁给其他节点发送
ping, 其中包含自己的状态还有自己维护的集群元数据, 互相通过ping交换元数据(类似自己感知到的集群节点增加和移除 hash, slot信息等) - meet: 某个节点发送
meet给新加入的节点, 让新节点加入集群中, 然后新节点就会开始与其他节点进行通信. - pong: 对
ping和meet消息的返回, 包含自己的状态和其他信息, 也可以用于信息广播和更新. - fail: 某个节点判断另一个节点
fail之后, 就发送fail指令给其他节点, 通知其他节点, 指定的节点宕机了.
- ping: 每个节点都会频繁给其他节点发送
gossip 优点: 元数据的更新比较分散, 不是集中在一个地方. 更新请求会陆陆续续, 打到所有节点上去更新, 有一定的延时, 降低了压力.
gossip 缺点: 元数据更新延时可能会导致集群的一些操作会有一些滞后.
每个节点都有一个专门用于节点间
gossip通信的端口, 就是自己提供服务器的端口号 +10000, 比如1001, 那么用于这个节点间通讯的就是 11001 端口.
每个节点每隔一段时间都会往另外几个节点发送ping消息, 同事其他几个节点收到ping消息之后返回pong消息.
3.4 网络抖动
现实的机房网络经常会发生各种各样的小问题, 比如网络抖动就是非常常见的一种现象, 突然之间部分连接变得不可访问, 然后很快又恢复正常.
为了解决这种问题, Redis Cluster 提供另一种选项 cluster-node-timeout, 表示当某个节点持续在设定的 timeout的时间失联时, 才可以认定该节点出现故障, 需要进行主从切换, 如果没有这个选项, 网络都懂会导致主从频繁切换(数据的重新复制).
4. Redis 集群选举的基本原理
学习原理前, 需要先了解一个词 epoch
redis 用了和 Raft 算法 term(任期) 类似的概念, 在 Redis 中叫做 epoch (纪元), epoch 是一个无符号的 64位整数, 一个节点的 epoch 是从0开始的. 如果一个节点接收到的 epoch 比自己的大, 则将自己的 epoch 更新为接收到的 epoch.
一个 slave 发起选举的前置条件:
- 它的
master为fail状态. - 它的
master至少负责了一个slot槽位 -
slave和master的复制链接断开时间不超过给定的值.(值可配置, 目的是确保 slave上的数据足够完整. 所以不能任由一个 slave 长时间不可用, 需要通过监控将异常的 slave 及时恢复,)
- 发起选举前,
slave先给自己的epoch既currentEpoch增一, 然后通过FAILOVE_AUTH_REQUEST广播, 发送给集群中的每个master请求其它给自己投票. -
slave发起投票后, 会等待至少两倍NODE_TIMEOUT时长, 来接收投票结果.(无论NODE_TIMEOUT是何值, 至少会等待 2 秒). -
master接收到广播后会给slave响应FAILOVER_AUTH_ACK, 并且在NODE_TIMEOUT * 2时间内不会给同一master的其他slave投票. - 如果
slave收到FAILOVER_AUTH_ACK响应的epoch, 则会直接丢弃. 一旦slave收到多数master的FAILOVER_AUTH_ACK, 则会声明自己赢得了选举. - 如果
slave在两倍的NODE_TIMEOUT时间内 (至少2秒) 未赢得选举, 则放弃本次选举. 然后在四倍NODE_TIMEOUT时间 (至少4秒) 后重新发起选举.
注意事项
只有master为 fail 状态时, slave 才会发起选举, 但并不是master为 fail 时立即发起, 而是有一定的延迟, 一定的延迟可以避免多个 slaves 同时发起选举.(至少延迟0.5秒后才会发起选举), 也可以确保 master 的 fail 状态在整个集群内传开, 否则可能只有小部分的 master 知晓, slave 如果立即尝试选举, 其他 master 或许会拒绝投票.
500 milliseconds + random delay between 0 and 500 milliseconds + SLAVE_RANK * 1000 milliseconds
slave 的 SLAVE_RANK 是一个与 master 复制数有关的值, 具有最新复制时, SLAVE_RANK 的值为 0 ,第二则为1, 以此类推. rank越小代表已复制的数据越新. 这种方式下, 持有最新最新数据的 slave 将会首先发起选举.
在 slave赢得选举后, 会向集群内的所有节点广播 pong, 以尽快完成重新配置, 主要体现在 node.conf 的更新.
5. 集群脑裂数据丢失问题
集群脑裂通常发生在分布式系统中, 当网络出现问题或节点之间的通信中断时, 可能会导致集群中的不同部分无法相互通信, 在 redis 集群中, 这可能导致不同的节点组成多个独立的小集群, 每个小集群可能都认为自己是整个集群的有效部分, 但它们无法互相通信, 可能会导致数据不一致和服务不可用的情况.
例:
初始状态：一个包含6个Redis节点的集群，使用Redis Cluster进行管理。这些节点分布在不同的服务器上，负责存储和处理数据。
网络分区：突然发生了网络问题，导致集群内的三个节点（节点A、B、C）无法与另外三个节点（节点X、Y、Z）进行通信。这可能是由于网络拥塞、硬件故障或其他网络问题引起的。
节点分裂：由于网络分区，集群分裂为两个子集群。节点A、B、C在一个子集群内，而节点X、Y、Z在另一个子集群内。两个子集群之间无法相互通信。
自我宣称为主节点：在子集群A中，节点A可能会自我宣称为主节点（因为它认为其他两个节点失效），并继续接收和处理客户端的写入请求。
同样的情况发生在子集群B中：节点X也可能在另一个子集群B中自我宣称为主节点，尝试处理写入请求。
数据不一致：由于两个子集群中的节点相互无法通信，它们开始处理不同的写入请求，可能会导致数据不一致。例如，对于相同的键，节点A和节点X分别接收并修改了不同的值。
客户端请求混乱：客户端可能会向不同的子集群发送读取或写入请求，但由于两个子集群无法相互通信，这些请求可能会得到不同或矛盾的响应，导致服务不可用或数据的混乱. 一旦网络分区回复, 会将其中一个主节点变为从节点, 这时会有大量数据丢失.
规避方式是可以在 redis 配置文件中加上参数(这种方式无法百分百避免数据丢失)
min‐replicas‐to‐write 1
这个参数用于指定在进行写操作时, 至少需要将数据复制到子节点的数目. 主要是用来确保写入操作时数据的可靠性和持久性.
