redis主从架构和集群---java-EW帮帮网

主从架构和集群

Redis 的主从架构和集群（Redis Cluster）是两种不同的分布式部署方式。

主从架构（Master-Slave Replication）是一种简单的复制机制，一个主节点（Master）负责写操作，多个从节点（Slave）同步主节点的数据，只负责读操作。
Redis 集群是一种分布式架构，通过数据分片（sharding）将数据分散到多个节点，每个节点负责一部分数据，同时支持高可用和自动故障转移。
主从是集群的基础，Redis 集群内部每个 Master 和其 Slave 之间，实际上就是主从复制的关系。

是描述主节点（Master）将数据同步到从节点（Slave）的过程，Redis 的主从复制分为两个阶段：全量同步和增量同步。

触发场景：

流程：

结果：从节点的数据与主节点完全一致。
全量同步

增量同步允许从服务器从断点处继续同步，而不是每次从头开始同步。

关键机制

断线重连的增量同步

从节点断开：
- 从节点网络中断，偏移量停在 120。
主节点继续写：
- 客户端发送：SET city “Beijing”（20 字节）。
- 主节点偏移量变为 140，缓冲区追加 SET city “Beijing”。
从节点重连：
- 从节点发送 PSYNC <runid> 120。
主节点检查：
- 偏移量 120 在缓冲区内。
- 从缓冲区提取 120 到 140 的命令：SET city “Beijing”。
- 主节点发送给从节点。
从节点执行：
- 执行 SET city “Beijing”，偏移量变为 140。
结果：
- 主从一致：name: “Alice”, age: 25, city: “Beijing”。

在这里插入图片描述

哨兵模式（Sentinel）是 主从架构 下的一个增强机制，而不是直接属于集群模式。

哨兵模式是一组运行 redis-sentinel 的进程，负责监控 Redis 主从节点的健康状态，管理故障转移和配置更新。如果发现主节点挂了，它就会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。

哨兵是一个额外的进程，可以在已有的 redis 上配置，也可以在独立机器上运行哨兵（更推荐，不会哨兵节点一起挂）

机器 A: Master (6379) + Sentinel1 (26379)
机器 B: Slave1 (6380) + Sentinel2 (26380)
机器 C: Slave2 (6381) + Sentinel3 (26381)

主节点下线 ：每个哨兵定期向主节点发送 PING，规定时间没回这个哨兵就认为主节点挂了。该哨兵向其他哨兵询问：“你们觉得主节点下线了吗？”。如果达到法定人数，主节点就被标记为“客观下线”。
选举领导者哨兵 ：哨兵发现主节点挂了就请其他哨兵选自己当领导者，其他哨兵遵循 “先到先得” 的原则投票，最后票高者得。
领导者哨兵选新节点 ：领导者选一个新主节点，通知其他哨兵和从节点。
选择标准：【1.配置优先级—>2.复制偏移量 offset 大—>3.运行 ID看随机】

16384 个槽分配给多个 Master，key 通过 CRC16 哈希映射到槽。每个 Master 有 Slave，主故障时 Slave 自动晋升 。

接下来的问题就是，这些哈希槽怎么被映射到具体的 Redis 节点上的呢？有两种方案：

平均分配：在使用 cluster create 命令创建 Redis 集群时，Redis 会自动把所有哈希槽平均分布到集群节点上。比如集群中有 9 个节点，则每个节点上槽的个数为 16384/9 个。
手动分配：可以使用 cluster meet 命令手动建立节点间的连接，组成集群，再使用 cluster addslots 命令，指定每个节点上的哈希槽个数。

优点

缺点

部署和维护较复杂
集群同步问题： 当某些节点失败或者网络出故障，集群中数据同步的问题也会出现。数据同步的复杂度和工作量随着节点的增加而增加，同步时间也较长，导致一定的读写延迟。