ES副本同步原理：多节点数据写入后发生了什么
在多节点Elasticsearch集群里，索引数据的副本一致性主要靠主分片负责写入、副本分片同步确认、以及多数派选举机制三层配合来兜底先让主分片落盘成功，再同步给副本，最后等多数派确认才返回成功。如果其中任何一环断了，集群会主动降级，而不是给你一个假的“写入成功”。
ES的数据同步远比表面看起来复杂，咱们从写入路径开始看，一条文档进来，先到主分片，写入内存缓冲区和translog日志，这时候还没到磁盘，默认每秒刷新一次，把缓冲区的数据生成一个Lucene分段，变成可查询状态，副本分片也在同步这份数据，但它只同步操作,不需要等主分片刷新完成。
这个流程决定了副本同步的底层逻辑：先写日志，再同步操作，然后异步刷盘，不光是ES，Kafka、RocketMQ用副本同步基本都是这个套路，只是ES因为要兼顾实时搜索,还多了一层refresh机制。
主分片如何保证副本数据不丢
主分片有个硬性要求：写操作必须等副本返回成功才向客户端确认，这个“成功”不是指副本已经刷盘，而是指副本的translog已经写入成功，数据进了内存态，这样即使节点宕机,也能从translog恢复。
默认配置下，写入副本数不小于1个，也就是说主分片至少要有一个副本成功写入translog，才肯给客户端返回成功，这个操作叫wait_for_active_shards，默认值是1，对应的是主分片自己，但实际上写入副本也是强制的,这个细节很多人没注意到。
同步确认机制与in-sync副本集合
每个索引分片组里有一个in-sync副本集合，简称ISR，只有在这个集合里的副本，才被允许参与主分片选举和数据恢复，ES通过定期检查每个副本的translog位置来判断它有没有掉队，如果某个副本长期没跟上主分片,就会被踢出ISR。
ES的同步一致性是“最终一致”和“读己之写”的混合体，实时性要求高的读请求，可以设置_preference=primary，直接打主分片；没那么敏感的读请求，走副本就行，行业共识认为，大多数业务场景不需要每一条查询都强制打主分片,否则副本就失去了负载均衡的意义。
为什么我的es集群出现查询数据不一致
这是最经典的排查问题，也是ES社区里被问得最多的场景，查询数据不一致,多数情况下和以下三个原因有关。
- refresh间隔还没到：数据写入了，但还没生成分段，搜索不到，注意这不是“丢了”，而是“没可见”。
- 主分片和副本不在同一个节点：网络延迟导致副本同步滞后,读到了旧的副本数据。
- 走了副本分片：副本分片处于恢复中或者被剔出ISR,读请求落到一个落后过多的副本上。
排查时先看集群状态，用GET _cluster/health确认status是不是green，如果存在unassigned shards，那说明有副本分片没分配成功，读请求自动绕到主分片或者另一个副本上，这种情况数据不会丢，但如果你连接的是极少数的副本节点,短时间内可能读不到最新数据。
多节点es集群脑裂问题怎么规避
脑裂是高可用集群的头号隐患，ES也不例外，当两个节点互相认为对方挂了，都会尝试把自己变成主节点，这时候如果旧主还没退出，就会出现两个主节点同时写入同一个索引的情况,副本同步链路直接乱套。
规避方案很简单：把discovery.zen.minimum_master_nodes设为可用节点数的一半加一，比如3个节点就设为2，5个节点就设为3，这个参数的意义在于，选举必须过半数，谁都不可能单方面称王，同时要配合discovery.zen.ping.unicast.hosts列出所有候选主节点。
还有一个常被忽视的点：如果集群里所有节点都具备master资格（默认配置就是这样），那脑裂概率会指数级上升，业内专家指出，生产环境一定要区分master-eligible节点和data节点,用专属主节点把职责隔离。
网络分区与副本分配异常的表现
网络抖动时，副本分片会进入UNASSIGNED状态，控制台或日志里会反复出现failed to obtain in-memory shard lock之类的提示，出现这种情况，多半是主节点和其他节点的连接断了,主节点暂时无法把分片分配给目标节点。
处理思路是：先看网络，再看磁盘水位，如果节点磁盘超过90%水线，ES会主动停止分配副本，这时候即使集群看起来活着,副本同步也是停滞的。
多节点es集群的副本同步策略配置实操
在实际操作里，索引副本数的设置、写入确认级别的设置，比理论重要得多,这里给出一套经得起检验的配置路径。
设置副本数和最小活跃副本数
创建一个索引时,用如下命令指定副本数：
PUT /my_index
{
"settings": {
"index.number_of_replicas": 2,
"index.write.wait_for_active_shards": 2
}
}
index.number_of_replicas控制副本数量，index.write.wait_for_active_shards控制写入时最少需要多少个活跃分片副本，把后者设为2，意味着主分片加一个副本都活着才允许写入，代价是写入耗时变高,因为要多等一个网络往返。
另一个更细的参数是index.recovery.initial_shards，当副本分片重新分配到新节点时，决定是否允许使用ingest节点,生产环境一般保持默认即可。
调整replica的位置和分片分配过滤
_cluster/reroute命令可以手动移动分片，但要注意：如果集群有自动均衡机制，你手动移完之后它可能又被重新分配回去，正确做法是用index.routing.allocation.include和exclude参数做分配过滤,把某些索引的副本固定在特定节点组上。
比如把冷数据的副本放到廉价大容量节点，用标签隔离,这样可以避免热节点磁盘被打满。
同步冲突的检测与规避
副本同步避免不了冲突，ES用的策略是版本号加乐观锁，每次写操作都会带上版本号，如果主分片发现请求里的版本号小于当前版本，直接拒绝写入并返回409冲突,这个机制在并发写入同一文档时尤其重要。
实际操作里，建议为关键业务文档指定external版本类型，用业务侧的时间戳作为版本依据,这样比ES默认的内部版本号更贴近真实语义。
调整副本数对查询一致性的影响
调副本数不是加减节点的简单算术题，它对整个集群的资源分配、写入吞吐和查询延迟都有连锁影响。
增加副本数带来的查询吞吐提升与副作用
副本越多，搜索的并发承载能力越强，因为查询可以分散到多份副本上分摊压力，比如一个索引有3个主分片、每个主分片2个副本,那么可以承载的查询并发量大约是单副本的3倍。
副作用同样存在。副本多一份，就意味着写入操作要多同步一份数据，translog的复制压力直接翻倍，如果集群带宽或磁盘IO本身有瓶颈,增加副本反而会让写入性能明显下滑。
操作路径：
PUT /my_index/_settings，设置index.number_of_replicas为期望值，执行后ES会自动触发副本分片的分配,不需要重启集群。
减少副本数的数据丢失风险
减少副本数要格外谨慎，如果你把副本从2降到0，一旦唯一的主分片所在节点宕机，这段数据就彻底丢了，这不是查询延迟的问题,而是物理消失的问题。
集群的可用性完全依赖副本冗余，据Elastic官方文档说明，生产环境至少保留1个副本，高危系统建议保留2个，如果是因为磁盘空间不够而想删副本，优先级应该是先扩磁盘,而不是牺牲数据安全。
副本重新分配时的网络与IO占用
ES在触发副本重分配时，会在节点之间传输整个分片的数据，这个传输过程会占用大量内网带宽和磁盘IO，如果集群正在处理业务高峰期流量,此时调整副本数可能导致查询超时。
实操建议是：在业务低峰期调整副本数，并且用cluster.routing.allocation.node_concurrent_recoveries参数限制并发恢复的分片数量，比如同时最多恢复2个分片,保护集群的稳定性。
关于索引数据副本同步的常见问题
es副本同步原理和Kafka副本机制有什么区别？
ES和Kafka都是主写副本同步的逻辑，核心区别在于同步粒度，Kafka的副本同步是分区分段的，以HW和LEO为水位标记，同步效率更高，适合高吞吐日志场景；ES的副本同步更强调实时搜索可见性，刷盘之后还要refresh才能被搜索到，同步链路更长，简单说，Kafka保的是写不丢，ES还要保写后立即可查，两者的权衡点不同。
需要强制查询走主分片时怎么操作？
在检索API里加上?preference=_primary参数即可：
GET /my_index/_search?preference=_primary
{
"query": { "match_all": {} }
}
这种写法的代价是主分片压力上升，查询并发能力下降，适合读一致性要求较高的场景,比如刚写完立即回查的订单支付结果确认。
分片发生重新分配后，副本同步会不会中断？
分片重新分配时，主分片正常服务不受影响，但旧副本分片的同步会被打断，ES会重新在新的节点上构建完整副本，构建期间，搜索请求不会路由到尚未完成同步的新副本上,因此查询结果不会返回半初始化状态的数据。