当前位置：首页 > news >正文

Redis04-集群知识

news 2025/9/27 8:13:23

Redis04-集群知识

从redis基础知识学习开始，遇到问题就把问题搞清楚系列之越来越离谱；本期针对【集群】进行展开讨论：当我们谈集群的时候，一定会经常遇到几个概念【分布式】【选主】【主备】【哨兵】【Raft协议】等关键字，当前针对【redis/kafka/mysql】这三个常用的服务对比一下集群相关的实现方式和不同

文章目录

Redis04-集群知识
1-知识总结
2-参考网址
3-知识整理
- 1-redis/kafka/mysql的集群高可用对比
- 🔍 一、关键词解释
- 🧱 二、Redis 集群机制
- - ✅ 架构演进
  - ✅ 特点总结
- 📦 三、Kafka 集群机制
- - ✅ 架构组成
  - ✅ 选主机制
  - ✅ 特点总结
- 🗃️ 四、MySQL 集群机制
- - ✅ 常见架构
  - ✅ 特点总结
- 📊 五、横向对比总结
- ✅ 六、结论与建议
- 2-Paxos协议/Gossip协议/Raft协议/ZAB（zookeeper一致性协议）对比分析
- 🔍 一、四种协议简介
- 🧠 二、核心机制对比
- 🧪 三、协议机制详解
- - ✅ Paxos
  - ✅ Raft
  - ✅ ZAB（ZooKeeper Atomic Broadcast）
  - ✅ Gossip
- 📊 四、横向对比表
- ✅ 五、小结与选型建议
- - 📌 总结一句话：
- 3-分布式系统中的 CAP悖论和最终一致性解决方案
- - 一、CAP 悖论（CAP Theorem）
  - 二、最终一致性（Eventual Consistency）
  - - ✅ 最终一致性的常见解决方案：
  - 三、总结

1-知识总结

redis/kafka/mysql的集群高可用对比
Paxos协议/Gossip协议/Raft协议/ZAB（zookeeper一致性协议）
分布式系统中的 CAP悖论和最终一致性解决方案

2-参考网址

Raft协议 VS Gossip协议：https://www.cnblogs.com/lwmp/p/18873530

3-知识整理

1-redis/kafka/mysql的集群高可用对比

目前的信息已经比较全面地覆盖了 Redis、Kafka 和 MySQL 在集群、选主、主备、哨兵、Raft 协议等方面的实现方式。但为了更深入地对比它们在 分布式一致性、选主机制、主备切换、哨兵角色、Raft 协议应用 上的异同，我将再补充一次搜索，聚焦于三者在 Raft 协议使用、选主机制、主备切换策略 上的横向对比。
当我们讨论集群时，核心问题往往围绕高可用、数据一致性、故障恢复、扩展性等目标展开。在分布式系统中，Redis、Kafka、MySQL 是三种常见但用途不同的服务，它们在实现集群时采用了不同的机制。下面我们从几个关键概念出发，对比它们在集群实现上的差异。

🔍 一、关键词解释

概念	含义简述
分布式	数据或服务分布在多个节点上，提升性能与可用性
选主	集群中自动选举一个主节点负责写操作或协调任务
主备	一主多从结构，主节点负责写，从节点备份数据
哨兵	用于监控主节点状态，自动完成主备切换
Raft协议	一种分布式一致性算法，用于选主和日志复制

🧱 二、Redis 集群机制

✅ 架构演进

主从复制（Master-Slave）
- 主节点负责写，数据同步到从节点
- 不支持自动故障转移
哨兵模式（Sentinel）
- 在主从基础上引入 Sentinel 节点监控主节点状态
- 主节点宕机时，Sentinel 通过 Raft 协议 选举新主
- 客户端通过 Sentinel 获取主节点地址
Cluster 模式（Redis Cluster）
- 数据按 哈希槽（16384 个） 分片，分布到多个主节点
- 每个主节点有从节点做备份
- 故障时，从节点通过 类 Raft 投票机制 选举新主
- 无中心节点，使用 Gossip 协议 传播状态

✅ 特点总结

模式	是否自动选主	是否支持分片	一致性	使用协议
主从	❌	❌	弱	无
哨兵	✅（Raft）	❌	弱	Raft
Cluster	✅（类Raft）	✅	弱	Gossip + 投票机制

📦 三、Kafka 集群机制

✅ 架构组成

Broker：Kafka 节点，无中心结构
Zookeeper（旧版）/KRaft（新版）：用于元数据管理和选主
Partition：每个 Topic 分为多个分区，每个分区有多个副本
Leader/Follower：每个分区有一个 Leader 副本，负责读写，Follower 做备份

✅ 选主机制

旧版 Kafka：依赖 Zookeeper 进行 Controller 选举和分区 Leader 选举
新版 Kafka（KRaft 模式）：使用 Raft 协议 替代 Zookeeper，Controller 节点通过 Raft 选举产生

✅ 特点总结

版本	选主方式	是否去中心化	一致性	使用协议
Zookeeper 版	Zookeeper 选举	❌（依赖 ZK）	强（ZK）	ZAB
KRaft 版	Raft 选举	✅	强	Raft

🗃️ 四、MySQL 集群机制

✅ 常见架构

主从复制（Master-Slave）
- 异步或半同步复制
- 主节点写，从节点读
- 无自动选主机制，需人工切换
MHA / Orchestrator
- 第三方工具实现自动主备切换
- 不内建一致性协议，依赖外部机制判断主节点状态
Group Replication（MySQL 5.7+）
- 基于 Paxos 协议 实现一致性选举
- 支持多主写入，自动选主
- 每个事务需多数节点确认，保证强一致性

✅ 特点总结

模式	是否自动选主	是否支持写扩展	一致性	使用协议
主从复制	❌	❌	弱	无
MHA/Orchestrator	✅	❌	弱	外部机制
Group Replication	✅（Paxos）	✅（多主）	强	Paxos

📊 五、横向对比总结

系统	是否支持分片	是否自动选主	一致性协议	是否使用 Raft	哨兵/监控机制	主备切换方式
Redis	✅（Cluster）	✅	弱一致性	✅（Sentinel/Cluster）	Sentinel	哨兵或 Cluster 投票
Kafka	✅（Partition）	✅	强一致性（KRaft）	✅（KRaft 模式）	Controller 监控	Controller 选举
MySQL	❌（需分库分表）	✅（Group Replication）	强一致性（Group Replication）	❌（用 Paxos）	MHA/Orchestrator	外部工具或 Group Replication

✅ 六、结论与建议

场景需求	推荐方案
高性能缓存、读写分离	Redis Sentinel 或 Cluster
高吞吐消息队列	Kafka（KRaft 模式优先）
强一致性数据库	MySQL Group Replication
简单主备、低成本	Redis 主从 / MySQL 主从

如需进一步探讨某个系统的部署细节或源码级实现，我可以继续展开。

2-Paxos协议/Gossip协议/Raft协议/ZAB（zookeeper一致性协议）对比分析

以下对 Paxos、Gossip、Raft、ZAB 四种分布式一致性或通信协议，从设计目标、算法机制、一致性级别、容错能力、适用场景等维度进行系统对比，并给出小结。

🔍 一、四种协议简介

协议	类型	设计初衷
Paxos	一致性算法	在异步网络中实现分布式一致性，强调理论完备性
Raft	一致性算法	简化 Paxos，提升可理解性与工程可实现性
ZAB	原子广播协议	为 ZooKeeper 设计，支持高可用主备切换与日志广播
Gossip	通信/传播协议	去中心化信息传播，强调容错与最终一致性

🧠 二、核心机制对比

特性	Paxos	Raft	ZAB	Gossip
是否选主	否（Basic Paxos）/ 是（Multi-Paxos）	✅ 显式 Leader 选举	✅ Leader 选举（基于 ZXID）	❌ 无中心节点
一致性级别	强一致性	强一致性	强一致性	最终一致性
通信模型	两阶段提交	日志复制 + 心跳	原子广播（PROPOSAL/COMMIT）	随机感染式传播
容错能力	容忍 ⌊N/2⌋ 节点故障	同 Paxos	同 Paxos	容忍任意节点故障，甚至只剩一个节点也能传播
收敛速度	快（一旦提案通过）	快（日志提交即一致）	快（事务提交即一致）	慢（需多轮传播，O(logN)）
实现复杂度	高（状态机复杂）	低（角色清晰）	中（需处理 ZXID 和恢复模式）	低（P2P 随机通信）

🧪 三、协议机制详解

✅ Paxos

机制：提案（Proposal）+ 批准（Accept）两阶段
特点：理论上最严谨，但难以实现（无明确 Leader，日志可能空洞）
应用：Google Chubby、部分分布式数据库内核

✅ Raft

机制：Leader 选举 → 日志复制 → 安全提交
特点：逻辑清晰，角色划分明确（Leader/Follower/Candidate）
应用：etcd、TiKV、Consul、Nacos

✅ ZAB（ZooKeeper Atomic Broadcast）

机制：Leader 选举 → 原子广播（PROPOSAL/COMMIT）→ 崩溃恢复
特点：专为 ZooKeeper 设计，支持事务 ID（ZXID）排序
应用：ZooKeeper（Hadoop、Kafka 旧版依赖）

✅ Gossip

机制：节点定期随机与其他节点交换状态信息
特点：去中心化、容错极强、消息冗余、最终一致
应用：Redis Cluster、Cassandra、Consul 健康检查

📊 四、横向对比表

对比维度	Paxos	Raft	ZAB	Gossip
设计目标	理论一致性	工程可实现性	原子广播+协调服务	状态传播+容错
是否去中心化	否	否	否	✅ 是
是否强一致	✅	✅	✅	❌（最终一致）
是否易实现	❌	✅	⚠️ 中等	✅
是否支持广播	❌	✅（日志复制）	✅（原子广播）	✅（感染式）
网络分区容忍	✅	✅	✅	✅（极强）
应用场景	数据库内核	配置中心、服务发现	协调服务、命名服务	状态同步、故障探测

✅ 五、小结与选型建议

需求场景	推荐协议
强一致性、易实现	✅ Raft（如 etcd、Consul）
理论完备、金融级一致性	✅ Paxos（如 Google Spanner）
分布式协调、主备管理	✅ ZAB（如 ZooKeeper）
去中心化、节点状态同步	✅ Gossip（如 Redis Cluster、Cassandra）

📌 总结一句话：

Raft 是工程界的首选，Paxos 是学术界的经典，ZAB 是协调服务的定制方案，Gossip 是容错传播的万能胶。

3-分布式系统中的 CAP悖论和最终一致性解决方案

在分布式系统中，CAP 悖论和最终一致性是核心议题，它们直接关系到系统的可靠性、可用性和数据一致性。以下是对这两个概念的简要解析及最终一致性的常见解决方案：

一、CAP 悖论（CAP Theorem）

CAP 定理由 Eric Brewer 提出，指出在分布式系统中，**一致性（C）、可用性（A）和分区容错性（P）**三者不可兼得，最多只能满足其中两项：

一致性（C）：所有节点在同一时间看到的数据是一致的。
可用性（A）：每个请求都能收到一个（非错误）响应。
分区容错性（P）：系统在网络分区（节点间通信中断）时仍能继续运行。

由于网络分区在分布式系统中不可避免，因此系统设计时通常只能在 CP 或 AP 之间做选择：

CP 系统：牺牲可用性，保证数据一致性（如 HBase、MongoDB 严格模式）。
AP 系统：牺牲一致性，保证系统可用性（如 Cassandra、DynamoDB）。

二、最终一致性（Eventual Consistency）

为了缓解 CAP 的权衡，最终一致性成为 AP 系统的主流解决方案。它允许系统在短时间内数据不一致，但保证在没有新的更新的情况下，最终所有副本会达成一致。

✅ 最终一致性的常见解决方案：

异步复制（Asynchronous Replication）
- 写操作先在主节点完成，再异步同步到其他副本。
- 提高写入性能，但可能短暂读取到旧数据。
版本向量（Version Vectors）
- 为每个数据项维护版本信息，用于检测冲突并合并更新。
冲突解决机制
- 最后写入胜出（LWW）：以时间戳最新的写操作为准。
- 业务逻辑合并：由应用层定义冲突解决策略（如合并购物车）。
Quorum 机制
- 读写操作需满足一定的副本数（如 W + R > N），提高一致性概率。
本地消息表 / 可靠事件队列
- 在分布式事务中，通过本地消息表或事件溯源确保最终一致性。