集群模式

集群模式一：主从共享数据的部署方式。
一台消息服务器进行存储，Master和slaves共享同一个消息存储服务器，读写分离。

集群模式二：主从同步部署方式（类似副本）

消息直接打进Master，和Redis原理差不多。单写多读。

 

集群模式三：多主集群同步部署方式

多主集群确实意味着存在多个可以同时接收写操作的 Master 节点。在这种架构下：

• 所有 Master 节点都能处理读写请求，不存在 “主从” 角色之分（如 MySQL Group Replication、MongoDB 的多主模式）。
• 写操作会在多个 Master 间同步，确保数据一致性（同步方式分同步复制和异步复制）。

与主从复制（Master-Slave）的区别

传统主从架构中：

• Master 专司写操作，Slave 仅负责读操作（读写分离）。
• Slave 数据来自 Master 的异步复制，存在延迟（如 MySQL 主从、Redis 主从）。

 

而多主集群中：

• 所有节点均可写，写操作会同步到其他节点。
• 典型场景：分布式数据库（如 CockroachDB、TiDB）、消息队列（如 Kafka 的分区多副本）。

• 优点：写操作可以分布到多个节点，提升整体写入吞吐量，避免单点瓶颈。
• 缺点：数据同步和冲突解决复杂，存在 “脑裂” 风险。

集群模式四：多主集群转发部署模式

在多主集群的转发部署模式中，活跃 Master（Active Master）指的是当前正在处理写请求的主节点，而其他主节点可能处于同步状态或备用状态。简单来说，活跃 Master 就像餐厅里的 “值班经理”，只有它能直接处理顾客的 “下单”（写操作），其他经理（主节点）则负责同步数据或临时接管工作。

一、活跃 Master 的核心定义

1. 唯一性：
   在转发模式中，同一时刻只有一个活跃 Master处理写请求，避免多主同时写入导致的数据冲突（如 “写后读” 不一致）。例如，MySQL Group Replication 通过 Paxos 协议选举唯一活跃 Master。
2. 动态切换：
   当活跃 Master 故障时，其他主节点会通过选举机制（如 Raft 协议）产生新的活跃 Master。例如，CockroachDB 使用 Raft 协议选举领导者节点作为活跃 Master，负责数据复制和一致性。
3. 请求转发：
   转发层（如 MaxScale、ProxySQL）会将写请求强制路由到活跃 Master，读请求则分发到其他节点。例如，MariaDB MaxScale 通过配置router_options = master将写请求固定到活跃 Master。

二、活跃 Master 的判定机制

1. 心跳检测与租约（Lease）

• 心跳机制：
  活跃 Master 定期向其他节点发送心跳信号（如 Redis Sentinel 的 PING 命令），其他节点通过心跳判断其存活状态。若心跳超时（如超过cluster-node-timeout配置），则触发选举。
• 租约机制：
  活跃 Master 持有一个 “租约”（如 ZooKeeper 的临时节点），租约过期后自动释放权限，其他节点可重新选举。例如，HBase 通过 ZooKeeper 选举活跃 HMaster，并通过租约防止脑裂。

2. 仲裁协议（Quorum）

• 多数派投票：
  选举需超过半数节点同意（如 3 节点集群需至少 2 票）。例如，MySQL Group Replication 要求多数节点确认后才将新节点晋升为活跃 Master。
• 防脑裂设计：
  仲裁机制确保分裂后的子集群无法形成多个活跃 Master。例如，Redis 通过min-replicas-to-write参数限制写操作，避免旧主节点在脑裂后继续写入。

3. 元数据存储

• 分布式 KV 存储：
  活跃 Master 的状态存储在 ZooKeeper、etcd 等组件中。例如，HBase 将活跃 HMaster 的信息存储在 ZooKeeper 的/hbase/master节点，转发层通过监听该节点获取状态。
• 动态路由表：
  转发层（如 Nginx）根据元数据实时更新路由规则。例如，MaxScale 通过查询 MySQL 节点的SHOW STATUS获取主从状态，动态调整写请求的目标节点。

集群模式五：Master-slave与Breoker-cluster（多主多从）

在分布式系统中，Master-Slave 和 Broker-Cluster 是两种不同的架构模式，分别用于不同的场景。

一、Master-Slave 架构

1. 核心定义

• 主从分工：
  一个 Master 节点负责处理写操作，多个 Slave 节点复制 Master 的数据并处理读请求。
  • 写路径：客户端 → Master → 写入数据 → 同步到 Slave。
  • 读路径：客户端 → 直接访问 Slave（减轻 Master 负载）。
• 典型场景：
  数据库读写分离（如 MySQL 主从复制、Redis 主从模式）、文件系统备份（如 NFS 主从）。

二、Broker-Cluster 架构

1. 核心定义

• Broker 角色：
  Broker 是消息中间件（如 Kafka、RabbitMQ）中的核心组件，负责接收、存储和转发消息。
  • 集群特性：多个 Broker 组成集群，通过分区（Partition）和副本（Replica）实现高可用和水平扩展。
  • 无主从之分：Broker 节点地位平等，通过 ZooKeeper 或内部协调机制管理元数据。
• 典型场景：
  异步消息队列、事件流处理（如实时日志收集、订单异步处理）。

三、典型场景示例

1. Master-Slave 应用

• 场景：电商商品详情页的读请求。
  • 架构：MySQL 主库处理写（订单、库存），从库集群处理读（商品详情查询）。
  • 优势：通过增加从库扩展读性能，减轻主库压力。

2. Broker-Cluster 应用

• 场景：用户注册后发送欢迎邮件。
  • 架构：用户服务 → Kafka Topic → 邮件服务消费消息。
  • 优势：解耦业务逻辑，即使邮件服务故障也不影响注册流程。