Elasticsearch 分布式协调算法演进全景：从 Zen Discovery 到 7.0+ 新协调子系统 这篇文章只讨论 Elasticsearch 集群协调层，也就是谁是 master、哪些 master-eligible 节点有投票权、cluster state 如何提交与发布、节点加入和离开时系统如何保持安全与可用。它不讨论文档写入如何从 primary 复制到 replica，也不讨论 peer recovery、translog、global checkpoint 或 CCR。 如果把 ES 看成两层系统，可以先记住这条总分界线：协调层（本文主题） peer discovery -> master election -> voting configuration -> cluster state publish/commit 数据复制层（本文特意区分出去） primary shard -> replica shard -> seq_no/global checkpoint -> recovery/retention lease 很多关于 ES 一致性的误解，都来自把这两层混在一起。7.0 前后被重写的是前者，不是后者。背景与问题边界 Elasticsearch 的 master-eligible 节点需要一起完成两件最基础的事：选出一个 master。对新的 cluster state 达成一致，并把它提交出去。 这里的 cluster state 指的是集群元数据和路由元数据，例如：节点成员关系索引和模板元数据shard routing tablevoting configurationcluster blocks 它不是 Lucene segment，也不是主分片上的文档变更日志。也就是说：“谁是当前 primary shard” 这个结论在 cluster state 里。“某条写请求怎样从 primary 复制到 replica” 这个执行过程不在 cluster coordination 里。 这个边界非常关键，因为它直接决定了一个事实：即使 ES 采用了更接近 Raft 的集群协调算法，也不会自动把文档复制路径变成 Raft 日志复制。术语与模型 为了避免后文混乱，先固定几个术语。协调层对象master-eligible node：能参与选主和投票的节点。master：当前负责发布 cluster state 的节点。voting configuration：哪些 master-eligible 节点的票数被计算在内。quorum：投票配置中“超过一半”的响应集合。cluster state publication：master 把一个新 cluster state 发给其他节点并等待提交。commit / apply commit：先形成法定提交，再在各节点应用已提交的 cluster state。数据层对象primary shard / replica shardReplicationOperation / TransportReplicationActionReplicationTrackerpeer recovery / retention lease / seq_no / global checkpoint 它们属于索引写入和副本复制路径，不属于本文所说的 cluster coordination。7.0 之前的 Zen Discovery 7.0 之前，ES 的主协调实现通常被社区称为 Zen Discovery，也经常被叫做 Zen1。从 6.8.23 的源码可以直接看到它的核心骨架：ZenDiscoveryElectMasterServiceNodeJoinControllerPublishClusterStateActionMasterFaultDetectionNodesFaultDetection 这套机制不是“没有 quorum”，恰恰相反，它也用 quorum 思想；问题在于 quorum 依赖 discovery.zen.minimum_master_nodes 这个外部人工配置，而不是让投票成员和提交规则成为集群内部、可提交、可持久化的一部分。发现与选主流程 从 ZenDiscovery.startInitialJoin() 到 innerJoinCluster()，旧流程可以抽成下面这条链路：ZenPing 发现节点 -> findMaster() -> 如果发现活跃 master，则尝试 join 该 master -> 如果没有活跃 master，则在候选者中选出“最好”的 master -> 本地当选后等待足够的 master joins -> 成为 maste…