Cluster State 如何传播

做的事：真实依次做三件事（创建索引、写入文档、改集群设置），每次之后都查cluster state的version号变化

代码GET /_cluster/state/version # 真实起点 PUT /cs_test {"settings":{"number_of_shards":1,"number_of_replicas":0}} GET /_cluster/state/version POST /cs_test/_doc {"n":1} GET /_cluster/state/version PUT /_cluster/settings {"persistent":{"indices.recovery.max_bytes_per_sec":"50mb"}} GET /_cluster/state/version

验证：创建索引真实让version跳了3（不是1），写入文档后真实又跳了1，改集群设置后真实再跳1

实测 · 本机 Elasticsearch 8.15.0 执行输出

起点: version=708
创建索引后: version=711   ← 真实跳了3，不是1
写入文档后: version=712   ← 真实又跳了1（这一步真实有疑点，后面会验证）
改集群设置后: version=713   ← 真实跳了1

创建索引真实让version一次跳了3，这是因为索引创建在ES内部真实不是单一一次状态变更：真实至少包含"注册索引元数据"和"真实把新分片分配到具体节点上"这两个独立的集群状态更新步骤，每一步真实都会让version真实递增一次。但"写入文档之后version又跳了1"这件事真实有疑点——写入数据按理说不该触碰集群状态，这个+1真实更可能是分片分配收尾的后台状态更新恰好发生在这个时间点，而不是文档写入本身导致的。

真实等集群彻底稳定之后，连续写入两条文档，验证version是否真的会因为纯数据写入而变化

代码真实等待集群状态稳定后: POST /cs_test/_doc {"n":2} GET /_cluster/state/version POST /cs_test/_doc {"n":3} GET /_cluster/state/version

验证：集群稳定之后，连续两次纯数据写入，version真实一次都没有变化

实测 · 本机执行输出

稳定后起点: version=713
写入文档后: version=713   ← 真实一个数字都没变
再写入一条: version=713   ← 真实依然没变

这组真实的后续验证纠正了前面观察到的疑点：在集群状态真实彻底稳定之后，连续两次纯粹的文档写入操作，cluster state的version真实完全没有发生任何变化——这证明了普通的数据写入（index、update、delete具体文档）从设计上就真实不属于cluster state管辖的范畴，cluster state真实只负责维护集群层面的元数据（有哪些索引、每个索引的mapping和settings是什么、每个分片真实被分配到了哪个节点上、集群里有哪些节点），不负责任何具体文档内容的变更。之前观察到的那次"写入文档后version+1"真实只是巧合——分片分配这个异步的后台收尾过程恰好在那个时间点完成，产生了一次跟文档写入本身无关的状态更新。真实理解这个边界很重要：cluster state真实需要在master节点产生新版本后，广播给集群里的每一个节点确认接收，这个广播过程真实有实际的网络和处理开销，如果误以为"每次写入数据都会触发一次cluster state广播"，真实会高估这部分开销对写入吞吐的影响；真实情况是只有索引创建、mapping变更、分片重分配、集群设置变更这类元数据层面的操作才会真实触发cluster state的更新和广播，日常海量的数据写入真实完全不会经过这条路径。

分步演示：cluster state version从索引创建的多次跳变到排除文档写入干扰的完整验证

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。

cluster state只管集群元数据，真实跟具体的文档数据写入完全无关

这一步新验证的操作类型

本文用到的工具

本机真实部署的 Elasticsearch 8.15.0（单节点，tar包直接启动）
真实的 _cluster/state/version API

下一篇 · ELASTICSEARCH 111

节点角色：Master、Data、Ingest、Coordinating