Redis 学习五 高可用集群

2024-01-07  本文已影响0人  __Y_Q

本章学习内容如下

  1. 什么是 Redis Cluster
  2. Redis Cluster 配置
  3. Redis 集群的一些理论知识
  4. 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 配置

  1. 在 192.168.50.88 这台机器上创建文件夹 redis-cluster, 然后在其下面分别再创建8001, 8004 文件夹
mkdir -p /usr/local/redis-cluster
cd /usr/local/redis-cluster
mkdir 8001
mkdir 8004
  1. 复制一份 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，注释掉即可）
  1. 将 8001 修改后的配置文件复制到 8004下, 并且修改带有端口号的设置.可以批量修改.
#例如要将 8001 全部修改为 8004
:%s/8001/8004/g
  1. 继续上面的操作,在剩余两台虚拟机上进行操作, 第二台设备是 8002, 8005, 第三台设备是 8003, 8006.
  2. 分别启动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]
  1. 使用 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 # 禁止开机启动

默认将前面

  1. 验证集群
    连接任意一个客户端
/usr/local/src/redis-6.2.14/src/redis‐cli -a zhansgan -c -h 192.168.50.88 -p 8001

进行验证

cluster info 查看集群信息

集群信息

cluster nodes 查看节点列表

节点列表
  1. 关闭集群, 需要逐个进行关闭.
/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 通信的端口, 就是自己提供服务器的端口号 +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 发起选举的前置条件:

  1. 发起选举前, slave 先给自己的 epoch 既 currentEpoch 增一, 然后通过 FAILOVE_AUTH_REQUEST 广播, 发送给集群中的每个 master 请求其它给自己投票.
  2. slave 发起投票后, 会等待至少两倍 NODE_TIMEOUT 时长, 来接收投票结果.(无论 NODE_TIMEOUT 是何值, 至少会等待 2 秒).
  3. master 接收到广播后会给 slave 响应 FAILOVER_AUTH_ACK, 并且在 NODE_TIMEOUT * 2 时间内不会给同一 master 的其他 slave 投票.
  4. 如果 slave 收到 FAILOVER_AUTH_ACK 响应的 epoch, 则会直接丢弃. 一旦 slave 收到多数 master 的 FAILOVER_AUTH_ACK, 则会声明自己赢得了选举.
  5. 如果 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 集群中, 这可能导致不同的节点组成多个独立的小集群, 每个小集群可能都认为自己是整个集群的有效部分, 但它们无法互相通信, 可能会导致数据不一致和服务不可用的情况.
例:

规避方式是可以在 redis 配置文件中加上参数(这种方式无法百分百避免数据丢失)

 min‐replicas‐to‐write 1

这个参数用于指定在进行写操作时, 至少需要将数据复制到子节点的数目. 主要是用来确保写入操作时数据的可靠性和持久性.

上一篇 下一篇

猜你喜欢

热点阅读