为何分布式系统中写请求需选主而读请求无需选主？
这问题问到点子上了——核心差异其实藏在写操作和读操作的本质目标，以及分布式系统在「一致性」和「性能/可用性」之间的权衡逻辑里，咱们结合Zookeeper拆解来看：
一、先搞懂：写请求为什么必须依赖选主+共识（比如Paxos/ZAB）？
写操作的核心是修改系统全局状态，分布式环境下最怕的就是「状态分裂」——比如两个节点同时处理同一个key的写，最后一部分节点认A值，一部分认B值，整个集群就乱了。
选主（Leader Election）的作用就是先确定一个「唯一权威节点」，所有写请求必须经过它：
- 在Zookeeper里，写请求只能发给Leader，Leader会通过ZAB协议（Paxos的工程实现）把写提案同步给集群内的Follower节点；
- 只有当过半Follower确认收到并持久化了这个写操作，Leader才会提交该操作，然后通知客户端写成功。
这一套流程的本质是通过共识算法，让集群内多数节点认可这个修改——就算少数节点挂了，只要多数节点存活，数据就不会丢失，整个集群的状态也能保持一致。如果跳过选主，允许任意节点处理写，必然会出现脑裂、数据冲突的问题，完全违背了分布式系统的可靠性要求。
二、读请求为什么不需要选主/共识？
读操作的核心是获取当前状态，它不会修改任何数据，所以不需要协调所有节点达成一致——这是最关键的点。
Zookeeper默认的读策略是允许从任意节点（Leader或Follower）读取，这么做的好处是：
- 分散读流量，提升系统的吞吐量和可用性，毕竟不用所有请求都挤到Leader节点；
- 降低延迟，客户端可以就近访问最近的节点。
当然你可能会问：那会不会读到旧数据？比如Leader刚写完一个值，Follower还没同步完，这时候读Follower就拿到旧值了？
没错，这就是Zookeeper默认的「最终一致性」策略，但它也提供了可选的强一致读方案：
- 你可以在读之前调用
sync()接口，强制让当前节点同步Leader的最新状态； - 或者直接把读请求指定发给Leader，这样就能确保读到最新的已提交数据。
本质上，读操作不需要选主，是因为它没有「修改全局状态」的需求——你只需要获取某个节点的当前状态，至于这个状态是不是最新的，完全取决于你的一致性优先级：要性能就默认读任意节点，要强一致就读Leader（但这时候也不需要重新选主，因为Leader已经存在了）。
三、你可能忽略的Zookeeper关键逻辑
这里纠正一个常见误解：选主不是每次写请求都要触发的！Leader Election只在集群启动、Leader节点故障下线的时候才会执行，平时写请求只是发给已经存在的Leader，走ZAB同步流程——你之前可能把「写请求必须走Leader」和「每次写都要选主」混淆了。
另外Zookeeper还默认保证了：
- 会话一致性：同一个客户端的读请求会被路由到同一个节点，不会出现“这次读到A，下次读到更旧的B”的时序错乱；
- 顺序一致性：所有写操作是全局有序的，读操作能看到之前所有已经提交的写操作的结果（如果读的是Leader的话）。
总结一下
- 写请求需要选主+共识：为了避免分布式状态分裂，必须通过唯一权威节点发起修改，再通过共识同步到多数节点，保证全局状态的一致性；
- 读请求不需要：因为不修改状态，优先考虑性能和可用性，同时提供可选的强一致读方案，平衡一致性和性能的需求。
内容的提问来源于stack exchange，提问作者Shibasis Sengupta
