播面 ZooKeeper 中Follower 和 Observer 的区别是什么？
在 ZooKeeper 集群中，Follower 和 Observer 都是用来处理客户端读请求并同步 Leader 数据的角色，但它们在投票权和对写性能的影响上有本质的区别。
简单来说：Observer 是没有投票权的 Follower。
以下是详细的区别对比：
1. 核心区别：投票权 (Voting Rights)
这是两者最根本的区别。ZooKeeper 使用 ZAB 协议（ZooKeeper Atomic Broadcast）来保证数据一致性，这涉及到两个场景的投票：
- Follower：拥有投票权。
- 写请求投票： 当 Leader 收到写请求（Proposal）时，Follower 会参与投票。只有收到半数以上（Quorum）节点的 ACK，Leader 才会提交该事务。
- 选举投票： 当 Leader 挂掉时，Follower 会参与新 Leader 的选举投票。
- Observer：没有投票权。
- 它不参与写请求的“过半数”确认过程。
- 它不参与 Leader 的选举过程。
- 它仅仅是“观察” Leader 的状态，并接收 Leader 发送的
INFORM消息来同步数据。
2. 对写性能的影响 (Write Performance)
由于 ZooKeeper 的写操作需要集群中“过半数”节点确认才能成功，集群规模的大小直接影响写性能。
- Follower： 增加 Follower 的数量会降低写性能。
- 原因：Leader 需要等待更多的 Follower 反馈 ACK，网络通信和同步的开销变大。
- Observer： 增加 Observer 的数量不影响写性能。
- 原因：Leader 不需要等待 Observer 的确认，只要核心的 Leader + Followers 构成的法定人数（Quorum）确认即可。
3. 对读性能的影响 (Read Performance)
- Follower & Observer： 两者都能提升读性能。
- 客户端可以直接连接 Follower 或 Observer 进行读取。增加这两类节点都可以分担读流量，提高集群的并发读能力。
4. 可用性与容灾 (Availability)
- Follower： 影响集群的可用性。
- ZooKeeper 集群存活的条件是“剩余节点数 > N/2”。如果过多的 Follower 挂掉，导致存活节点不足半数，集群将停止服务。
- Observer： 不影响集群的可用性（只要 Leader 和 Follower 正常）。
- Observer 挂掉不会影响集群的运行，只会减少提供读服务的节点数量。
总结对比表
| 特性 | Follower | Observer |
|---|---|---|
| 处理读请求 | 是 | 是 |
| 处理写请求 | 转发给 Leader | 转发给 Leader |
| 参与写操作投票 | 是 (计入 Quorum) | 否 |
| 参与 Leader 选举 | 是 | 否 |
| 增加节点对写性能影响 | 降低 | 无影响 |
| 增加节点对读性能影响 | 提升 | 提升 |
| 适用场景 | 构建核心高可用集群 | 跨机房部署、读多写少需极高并发读取的场景 |
为什么需要 Observer？
引入 Observer 主要是为了解决 “扩展性” (Scalability) 问题。
在没有 Observer 之前，如果你想提高 ZooKeeper 的读吞吐量，必须增加 Follower。但增加 Follower 会导致写操作变慢（因为投票节点多了）。这造成了“读性能”和“写性能”的矛盾。
Observer 打破了这种矛盾： 它允许你在不牺牲写性能的前提下，通过无限增加 Observer 节点来线性扩展读性能。此外，Observer 非常适合跨数据中心（跨机房）部署，因为它们不需要参与高延迟的跨机房投票过程，却能提供本地读取服务。