ZooKeeper是多主多从的结构，还是一主多从的结构？

Zookeeper 是一主多从的结构。

具体来说，Zookeeper 集群由一个 Leader（主节点） 和多个 Follower（从节点） 构成，所有节点共同组成一个分布式协调服务。

以下是 Zookeeper 结构的详细说明：

1. Zookeeper 的一主多从架构

1.1 角色划分

• Leader（主节点）

  • 负责处理所有的写请求（事务性请求，如创建节点、删除节点、更新数据）。

  • 确保写操作在所有节点上保持顺序一致性。

  • 负责协调集群的工作，包括管理心跳和故障检测。

  • 只有一个 Leader 节点。

• Follower（从节点）

  • 负责处理读请求（非事务性请求，如获取节点数据）。

  • 接受 Leader 的指令，同步数据。

  • 参与选举过程，投票选举新的 Leader。

  • 有多个 Follower 节点。

• Observer（观察者节点，可选）

  • 仅同步 Leader 的数据，但不参与选举和写操作投票。

  • 用于扩展读取能力，避免影响 Leader 的性能。

  • 适用于需要大量读操作的场景。

1.2 工作机制

• 写请求：

  1. 客户端将写请求发送到任意 Zookeeper 节点。

  2. 如果是 Follower 节点接收到写请求，它会转发给 Leader。

  3. Leader 将写请求转换为事务提案，并广播给所有 Follower。

  4. 多数 Follower（Quorum）确认提案后，Leader 将事务提交，并通知客户端。

• 读请求：

  1. 客户端可以向任意 Zookeeper 节点发送读请求。

  2. 读请求在 Follower 或 Leader 节点直接处理（视配置而定）。

  3. 读取的数据可能稍微滞后（非强一致性），但对于大多数场景足够使用。

2. 为什么是一主多从而不是多主

1. 一致性保障

   • Zookeeper 强调 线性一致性，即所有写操作必须严格按顺序执行。

   • 多主结构会导致写冲突和一致性问题，一主多从可以通过 Leader 来保证全局的写顺序一致性。

2. 性能权衡

   • 多主结构会增加写操作的协调成本（如冲突检测和合并），降低性能。

   • 一主多从通过集中管理写操作，简化了协调逻辑，同时利用从节点分担读操作压力。

3. 选举机制

   • Zookeeper 使用基于 Zab 协议 的 Leader 选举机制，确保在 Leader 故障时，快速选出新的 Leader，维持服务可用性。

3. 一主多从的优缺点

优点

1. 简单高效：

   • 集中化的写操作管理，避免多主协调的复杂性。

   • 支持高并发读操作，从节点可以分担读取压力。

2. 强一致性：

   • 通过 Leader 控制写操作，确保所有节点的顺序一致性。

3. 容错性：

   • 只要超过一半的节点正常工作，集群就能保持服务。

缺点

1. 写性能瓶颈：

   • 所有写操作必须经过 Leader，Leader 的性能和带宽可能成为瓶颈。

2. 单点故障：

   • 如果 Leader 故障，尽管可以快速选出新 Leader，但会有短暂的服务中断。

4. 总结

Zookeeper 是 一主多从 的架构：

• Leader 负责写请求，保证顺序一致性。

• Follower 负责读请求，并同步 Leader 数据。

• 通过这种架构，Zookeeper 在一致性和性能之间取得了平衡，适合协调分布式系统的状态。