【Redis 神秘大陆】004 高可用集群

四、Redis 高可用和集群

当你发现这些内容对你有帮助时，为了支持我的工作，不妨给一个免费的⭐Star，这将是对我最大的鼓励！感谢你的陪伴与支持！一起在技术的路上共同成长吧！点击链接：GitHub | Gitee

4.1 基础理论

分布式系统本质是通过低廉的硬件攒在一起以获得更好的吞吐量、性能以及可用性等。一台设备坏了，可以通过负载均衡和路由到 其他设备上。

分布式系统设计有核心四大块：

• 心跳检测： 如何检测你还活着？

• 【注册中心】

• 高可用设计： 如何保证高可用

• 容错性： 服务容错如何处理、怎么做重试

• 负载均衡: 负载均衡策略怎么处理

4.2 架构说明

4.2.1 主从复制

4.2.1.1 基础架构

一主一从

可以直在从节点开启 AOF ，这样可以保证数据安全也能降低持久化对于节点的影响

一主多从

问题原因：

• 读占比较大的场景下，主节点可能会因处理大量读请求而负载过重，影响系统性能和稳定性。
• 写并发量较高的情况下，多个从节点会导致主节点发送写命令的次数增加，增加网络带宽的消耗和主节点负载，影响服务的稳定性。

解决方案：

• 对于读占比较大的场景，可以将读命令发送到从节点上执行，减轻主节点的压力，提高系统整体性能稳定性。
• 尤其对于一些耗时较长的读命令（如keys、sort等），可以选择在从节点上执行，避免慢查询对主节点造成阻塞，影响线上服务的稳定性。
• 针对写并发量较高的场景，需要控制从节点的数量，避免过多的从节点给主节点带来过多的负担，从而影响服务的稳定性。

补充分析：

• 通过读写分离可以充分利用从节点的读性能，提高整体系统的读取效率。
• 但需要注意控制从节点的数量，避免过多的从节点给主节点带来过多的负担，同时也要关注从节点的负载情况，确保从节点能够正常处理读请求。

树状结构

优点：

1. 分散负载：树状结构可以有效地分散主节点的负载，因为数据可以通过多层从节点传输，而不是直接从主节点传输到所有从节点。
2. 减少网络传输：由于数据可以在从节点之间传输，树状结构可以减少数据在网络中的传输量，降低了网络带宽的压力。
3. 增强稳定性：通过引入复制中间层，树状结构可以提高整个系统的稳定性。即使某些从节点发生故障，其上游的主节点仍然可以将数据传输给其他从节点，从而保证数据的可用性。

缺点：

1. 复杂性增加：树状结构引入了复制中间层，增加了整个系统的复杂性，包括配置、管理和监控等方面。
2. 单点故障：如果树状结构的中间层出现故障，可能会影响下游所有从节点的数据复制，从而造成系统的单点故障。
3. 网络延迟：由于数据需要通过多层从节点传输，树状结构可能会增加数据复制的延迟，特别是在网络状况不佳的情况下。

4.2.1.2 基础配置

建立复制

在Redis中，参与复制的实例被分为主节点（master）和从节点（slave）。默认情况下，Redis实例都是主节点。每个从节点只能有一个主节点，但是一个主节点可以拥有多个从节点。复制的数据流是单向的，只能由主节点向从节点复制数据。配置复制有以下三种方式：

1. 在配置文件中加入 slaveof {masterHost} {masterPort}，随Redis启动生效。
2. 在redis-server启动命令后加入 –slaveof {masterHost} {masterPort}，生效。
3. 直接使用命令：slaveof {masterHost} {masterPort}，生效。

举例来说，假设本地启动了两个Redis节点，端口分别为6379和6380，执行以下命令将6380节点设置为6379节点的从节点：

127.0.0.1:6380> slaveof 127.0.0.1 6379

在这个例子中，6379节点是主节点，6380节点是从节点。建立复制关系后，我们可以执行以下命令进行测试：

127.0.0.1:6379> set hello redis
OK
127.0.0.1:6379> get hello
"redis"
127.0.0.1:6380> get hello
"redis"

从这个运行结果可以看出，复制已经成功工作。主节点6379上的任何修改都可以同步到从节点6380中。

断开复制

slaveof命令不仅可以建立复制，还可以在从节点执行 slaveof no one 来断开与主节点的复制关系。例如，执行以下命令可以断开6380节点与主节点的复制关系：

127.0.0.1:6380> slaveof no one

断开复制的主要流程如下：

1. 断开与主节点的复制关系。
2. 从节点晋升为主节点。

断开复制后，从节点并不会丢失原有数据，只是无法再获取主节点上的数据变化。

此外，通过 slaveof 命令还可以实现切换主节点的操作。执行 slaveof {newMasterIp} {newMasterPort} 命令即可，例如将6380节点从原来复制6379节点切换到复制6381节点。

切换主节点的操作流程如下：

1. 断开与旧主节点的复制关系。
2. 与新主节点建立复制关系。
3. 删除从节点当前所有数据。
4. 对新主节点进行复制操作。

在进行切换主节点操作时，务必注意从节点会清空之前所有的数据，因此在线上操作时需要谨慎执行 slaveof 命令，避免指向错误的节点或主节点。

只读模式

Redis从节点的 slave-read-only 配置为 yes，。这意味着从节点上的写操作将被拒绝，从而确保了数据的一致性。

因为从节点只能从主节点复制数据，主节点对于从节点的任何修改都是不可感知的，所以从节点上的修改可能会导致主从数据不一致的情况发生。特别是在线上环境中，强烈建议不要修改从节点的只读模式。如果允许从节点进行写操作，可能会导致数据的混乱和不一致，进而影响系统的可靠性和数据的完整性。

4.2.1.3 核心原理

• nacos 注册中心

private final ScheduledExecutorService scheduler =
     Executors.newScheduledThreadPool(1);
scheduler.schedule(new Runnable() {
       public void run() {
           //发送心跳
           1. 建立连接
           2. 发送内容
       }
     }, 60 * 60, SECONDS);

权限验证： masterauth 参数

• redis.config

数据同步

1. 主节点bgsave时间： 在进行全量复制时，主节点需要执行bgsave命令将当前内存中的数据保存到磁盘上的RDB文件中。这个过程需要占用主节点的CPU和内存资源，并且可能会影响到主节点的性能。
2. RDB文件网络传输时间： 主节点在完成bgsave之后，需要将生成的RDB文件通过网络传输给从节点。这个过程的耗时取决于主从节点之间的网络带宽和延迟，特别是对于数据量较大的情况，传输时间可能会很长。
3. 从节点清空数据时间： 从节点在接收到主节点发送的RDB文件后，需要先清空自身旧数据，然后再加载新的RDB文件。这个过程可能会导致从节点在一段时间内处于不可用状态。
4. 从节点加载RDB的时间： 从节点在清空旧数据后，需要加载新的RDB文件到内存中。这个过程的耗时取决于RDB文件的大小和从节点的性能。
5. 可能的AOF重写时间： 如果主节点开启了AOF持久化功能，它在完成全量复制后可能会执行AOF重写操作，将内存中的写命令重新写入到AOF文件中。这个过程可能会占用主节点的CPU和磁盘IO资源，并且可能会导致主节点的性能下降。

优化参数

4.2.2 哨兵

问题

哨兵的架构

故障转移流程

配置

redis-sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2 
sentinel down-after-milliseconds mymaster 30000 
sentinel parallel-syncs mymaster 1 
sentinel failover-timeout mymaster 180000
redis-sentinel redis-sentinel-26379.conf
redis-server redis-sentinel-26379.conf --sentinel

部署

如果是 4 个节点，当前挂了一台节点： 3/2+1=2

如果是 3 个节点，当前挂了一台节点： 2/2+1=2

• 为什么哨兵至少三个并且是奇数个的 sentinel 节点

• 领导选举需要过半+1，奇数节点能够节省一个节点

可以用哨兵监控多个主节点

优化

4.2.3 Cluster

• 用来解决什么问题，解决大量数据

• 硬件的容量是有限的， 负载均衡、分布式

• 分库分表

• 代理层-》多个副本

代理层： [xx]

• 主从 A
• 主从 B

4.2.3.1 数据分布

方案	优点	缺点	具体方案
节点取余分区HashMap 数组+链表{红黑树}	简单易实现，计算成本低。	节点数量变化时，需要重新计算数据的分布并进行数据迁移，可能导致数据迁移量大。	使用特定的数据（如Redis的键或用户ID），根据节点数量N计算哈希值，用来决定数据映射到哪一个节点上。	hash（key）%N
一致性哈希分区	加入和删除节点只影响哈希环中相邻的节点，对其他节点无影响。	节点变化时，部分数据无法命中，需要手动处理或者忽略这部分数据。	为系统中每个节点分配一个token，并构成一个哈希环，根据key计算hash值，在哈希环中顺时针找到第一个大于等于该哈希值的token节点。
虚拟槽分区ThreadLocal 拉链法 只用了一个数组	方便数据拆分和集群扩展，每个槽映射的数据通常比较均匀。	一般需要使用大范围的槽，可能会导致哈希空间的浪费。	使用哈希函数将数据映射到一个固定范围的整数集合中，称为槽，每个节点负责一定数量的槽

Redis Cluster 就是使用的虚拟槽位分区

4.2.3.2 搭建

#节点端口
port 6379

# 开启集群模式
cluster-enabled yes

# 节点超时时间，单位毫秒
cluster-node-timeout 15000

# 集群内部配置文件
cluster-config-file "nodes-6379.conf"

redis-server conf/redis-6379.conf

cluster meed {ip} {port}

redis-cli -h 127.0.0.1 -p 6379 cluster addslots {0...5461}
redis-cli -h 127.0.0.1 -p 6380 cluster addslots {5462...10922}
redis-cli -h 127.0.0.1 -p 6381 cluster addslots {10923...16383}

cluster replicate cfb28ef1deee4e0fa78da86abe5d24566744411e

也可以直接使用： redis-trib.rb 搭建

4.2.3.3 原理

节点通信

• gessip 协议： 病毒协议

槽位迁移

• 键的遍历应该怎么遍历

• 数据库的迁移

• 线上无感知【不能写入只能读取】

• 数据的对账，知道当前的进度

• 整体数据的对比

请求转发

127.0.0.1:6379> set key:test:2 value-2 
(error) MOVED 9252 127.0.0.1:6380

127.0.0.1:6379> cluster keyslot key:test:2
(integer) 9252


cluster info 
key 进行计算>获取到所有的槽位&节点信息->Map<>

4.2.3.4 故障转移

• 主观下线：指某个节点认为另一个节点不可用，即下线状态，这个状 态并不是最终的故障判定，只能代表一个节点的意见，可能存在误判情况。

• 客观下线：指标记一个节点真正的下线，集群内多个节点都认为该节 点不可用，从而达成共识的结果。如果是持有槽的主节点故障，需要为该节 点进行故障转移。

4.2.3.5 网络分区

大的集群持有半数槽节点可以完成客观下 线并广播fail消息，但是小集群无法接收到fail消息

网络分区会导致分割后的小集群无法收到大集群的fail消息，因此如果故障节点所有的从节点都在小集群内将导致无法完成后续故障转移，因此部署主从结构时需要根据自身机房/机架拓扑结构，降低主从被分区的可能性。

4.2.3.6 节点选举

• 选举延迟最低&数据最新的节点
• 选举周期的概念

4.2.3.7 优化建议

常见问题处理

故障转移

4.3 集群的部署和管理

4.3.1 常用的集群方式

4.3.1.1 客户端 sharding

key在客户端通过一致性hash进 行sharding。

4.3.1.2 proxy

proxy实现对后端缓存服务的集群管理。 Proxy同时也是一个集群。有两种方案管理proxy集群，通过LVS或者客户端实现。如果流量较大，LVS也需要考虑进行集群的管理。proxy方案运维复杂， 扩展性较强，可以在proxy上面实现限流等扩展功能。

LVS（Linux Virtual Server）是一个基于 Linux 内核的开源项目，用于构建高可用性和可伸缩性的服务器集群。它是一个软件负载均衡器，可以将来自客户端的请求分发到多个后端服务器上，以实现负载均衡和高可用性。

4.3.1.3 服务集群

gossip协议

服务端集群：主要是Redis的cluster机制，基于Gossip协议实现

数据分片方法

• Consistent Hashing
• Twemproxy-Twitter +LVS + Keepalived

RedisCluster

• 集群的搭建
• 查询路由
• 数据分片原理
• 高可用和主从切换原理
• 通信协议：RESP