Zookeeper 架构中 Leader、Follower 和 Observer 有什么区别？

Zookeeper 是主从协同架构，但角色边界很清楚：Leader 负责写请求排序、事务提案和提交协调；Follower 负责本地读、转发写请求、参与选举和投票；Observer 只同步数据和服务读请求，不参与选举，也不计入写入多数派。设计重点不是所有节点都可写，而是用少量投票节点保证一致性，再用 Observer 扩展读能力。

追问

写请求怎么流转？

客户端连到 Follower 时，写请求会被转发给 Leader，由 Leader 生成事务提案并广播。超过半数 Follower ACK 后才提交。

Observer 为什么能提升读性能？

Observer 不参加投票，增加它不会提高多数派门槛，也不会拖慢 Leader 等待 ACK 的路径。它适合承接跨机房或大规模客户端读流量。

为什么常用奇数个投票节点？

3 个节点能容忍 1 个故障，5 个能容忍 2 个。4 个投票节点也只能容忍 1 个故障，却多了同步和运维成本。

配置容易踩什么坑？

每台机器的 myid 必须和 server.X 对应。Observer 需要在节点配置里声明 peerType=observer，并在集群配置中标成 observer。

跨机房部署合适吗？

投票节点不建议跨高延迟机房，网络抖动会放大成选举和会话超时。远端读流量可考虑 Observer。