上一篇【第43篇】Elasticsearch搜索过程原理——分词、查询树与BM25评分下一篇【第45篇】Elasticsearch分布式检索原理——Query Then Fetch两阶段搜索摘要Elasticsearch的分布式能力是其区别于传统搜索引擎的核心竞争力。本文聚焦分布式索引原理从分片路由公式shard hash(_routing) % number_of_primary_shards出发解释为什么主分片数量创建后不可更改这一经典问题并通过自定义routing参数演示将相关文档路由到同一分片的实战技巧。接着以完整的ASCII流程图追踪文档写入的全流程客户端→协调节点→主分片→副本分片→响应并深入解析wait_for_active_shards参数、translog的WAL机制以及Lucene Segment的flush流程。关键词Elasticsearch分布式索引、分片路由公式、translog、主分片、写入流程。一、分布式架构基础Elasticsearch是一个构建在Lucene之上的分布式搜索引擎。它的分布式特性基于以下四大基石机制作用关键技术分片Shard将完整数据切割为N份存储在不同节点上突破单节点资源限制路由公式计算目标分片副本Replica数据冗余备份节点宕机后快速恢复提升查询吞吐量主分片写入后同步到副本集群发现Discovery新节点自动发现集群并加入无需手动配置种子节点自动探测负载均衡Relocate自动均衡分片分布节点增删时无需人工干预分片重分配机制在进入技术细节之前先建立几个核心概念主分片Primary Shard数据的权威副本写入操作必须先经过主分片副本分片Replica Shard主分片的完整拷贝用于容错和分担查询负载协调节点Coordinating Node接收客户端请求的节点负责请求路由和结果汇总二、分片路由公式深度解析2.1 路由公式Elasticsearch通过以下公式决定文档存储在哪个分片中shard_num hash(_routing) % num_primary_shards 其中 _routing 路由值默认取文档的 _id 值 hash() MurmurHash3 哈希函数保证均匀分布 % 取模运算 num_primary_shards 主分片数量创建时指定不可变2.2 为什么number_of_shards创建后不能改变这是Elasticsearch新手最常问的问题之一。答案就藏在路由公式的取模运算中假设主分片数为3 doc_001 → hash(doc_001) % 3 某个值 → 分配到分片 0/1/2 如果把主分片数改为4 doc_001 → hash(doc_001) % 4 完全不同的值 → 分配到错误的分片取模运算的除数一旦改变所有文档的Hash取模结果都会重新分布导致原有路由关系全部失效。Lucene分片一旦创建就不可分割因此Elasticsearch不支持动态修改主分片数量。★ 伸缩性的正确姿势 - 水平扩展读能力 → 增加副本分片动态调整无需重建索引 - 水平扩展写能力 → 通过 Reindex API 创建新索引并修改分片数 - 预分配策略 → 创建时预留一定余量如预期增长10倍则多分配一些分片2.3 routing参数将相关文档路由到同一分片在某些业务场景下我们希望将相关联的文档存储在同一个分片中。例如将同一个用户的所有订单文档路由到同一分片便于后续聚合计算和父子关联查询。// 创建支持自定义routing的索引PUT/orders{settings:{number_of_shards:3,number_of_replicas:1},mappings:{properties:{user_id:{type:keyword},product:{type:text},amount:{type:double},created_at:{type:date}}}}// 插入文档时指定routing参数使用 user_id 作为路由值POST/orders/_doc/1001?routinguser_42{user_id:user_42,product:iPhone 14 Pro Max,amount:8999.00,created_at:2026-05-22}POST/orders/_doc/1002?routinguser_42{user_id:user_42,product:AirPods Pro,amount:1799.00,created_at:2026-05-22}// 查询时必须指定相同的routingGET/orders/_search?routinguser_42{query:{match:{user_id:user_42}}}使用固定routing参数的好处减少搜索分片数只需搜索一个分片无需广播到所有分片保证关联性父子文档可确保在同一分片提升聚合性能局部聚合无需协调代价是数据分布可能不均匀如果某些routing值的数据量远大于其他值查询时必须记住并使用相同的routing值三、文档写入全流程从客户端到磁盘当一个文档通过POST /index/_doc被写入Elasticsearch时它要经历一个精确编排的多阶段流程。3.1 完整写入流程ASCII图客户端 协调节点 主分片节点 副本分片节点 │ │ │ │ │ ① POST /index/_doc│ │ │ │───────────────────│ │ │ │ │ │ │ │ │ ② 路由计算 │ │ │ │ hash(doc_id) % N │ │ │ │ 确定目标分片 │ │ │ │ │ │ │ │ ③ 转发写请求 │ │ │ │───────────────────│ │ │ │ │ │ │ │ │ ④ 写入 Translog │ │ │ │ (WAL, 先写日志) │ │ │ │ │ │ │ │ ⑤ 写入内存Buffer │ │ │ │ (倒排索引构建) │ │ │ │ │ │ │ │ ⑥ 同步到副本分片 │ │ │ │───────────────────│ │ │ │ │ │ │ │ │ ⑦ 写入Translog │ │ │ │ 写入内存Buffer │ │ │ │ │ │ │ ⑧ 副本报告成功 │ │ │ │───────────────────│ │ │ │ │ │ │ ⑨ 主分片报告成功 │ │ │ │───────────────────│ │ │ │ │ │ │ ⑩ 返回写入成功 │ │ │ │───────────────────│ │ │ │ │ │ │3.2 分步详解步骤①-②请求接收与路由客户端向任意节点发送写入请求。这个接收请求的节点承担了协调节点的角色。协调节点通过路由公式计算文档应该落在哪个主分片上shard hash(doc_1001) % 3 1 → 该文档应写入分片1步骤③转发到主分片所在节点协调节点查询集群元数据找到分片1的主分片所在节点假设为Node3将请求转发过去。步骤④写入Translog先写日志Write-Ahead Logging这是关键步骤。在内存中修改索引之前先将操作记录到Translog事务日志中。这是为了防止节点宕机导致内存数据丢失——即使Elasticsearch进程崩溃重启后可以从Translog中恢复尚未持久化的数据。Translog机制的核心价值 正常写入内存Buffer → Translog → 后续异步Flush → 磁盘Segment 节点宕机内存数据丢失 → 从Translog恢复 → 数据不丢步骤⑤写入内存Buffer文档内容被解析并构建倒排索引暂存在JVM堆内存的Index Buffer中。此时数据还没有持久化到磁盘但Translog中已有记录。步骤⑥-⑧同步到副本分片主分片将写请求并发地转发给所有副本分片。副本分片同样先写Translog再构建内存索引。当所有副本分片都成功响应后主分片才确认写入成功。步骤⑨-⑩响应返回主分片向协调节点报告写入成功协调节点再将结果返回给客户端。3.3 wait_for_active_shards参数在分布式环境中副本同步是需要时间的。wait_for_active_shards参数控制写入操作在返回成功前必须等待多少个分片被激活// 示例必须等待至少2个分片主分片1个副本确认POST/shop/_doc?wait_for_active_shards2{title:iPhone 14 Pro,price:7999}// 常用配置值// wait_for_active_shards1 默认值仅主分片即可// wait_for_active_shardsall 所有分片主全部副本// wait_for_active_shardsN 至少N个分片配置值数据安全性写入延迟适用场景1默认★★☆☆☆★★★★★低一般业务容忍极短暂不一致all★★★★★★★☆☆☆高金融/交易核心零容忍丢失N ≥ 2★★★★☆★★★☆☆中平衡安全性与性能四、Translog 与 Flush 机制4.1 TranslogElasticsearch的WALTranslogTransaction Log是Elasticsearch实现数据持久性的关键组件。它是一种**预写日志Write-Ahead Log, WAL**机制灵感来自数据库的redo log。Translog工作流程图 写入请求 │ ▼ ┌─────────────┐ 同步刷盘每次写入 ┌──────────────┐ │ 内存Buffer │ ◄────────────────────────── │ Translog │ │ (倒排索引) │ │ (磁盘文件) │ └──────┬──────┘ └──────┬───────┘ │ │ │ 定期刷新默认1秒 │ 达到阈值时清空 ▼ │ ┌──────────────┐ │ │ 文件系统缓存 │ │ │ (OS Cache) │ │ └──────┬───────┘ │ │ sync间隔默认5秒 │ ▼ ▼ ┌──────────────┐ Flush清空后 ┌──────────────┐ │ 磁盘Segment │ ◄──────────────────────────── │ Translog │ │ (持久化) │ │ 被截断 │ └──────────────┘ └──────────────┘4.2 Translog相关配置// 索引级Translog配置PUT/shop/_settings{index.translog.durability:request,// 默认值每次请求后fsyncindex.translog.sync_interval:5s,// async模式下的同步间隔index.translog.flush_threshold_size:512mb// translog达到该大小后触发flush}// durability的两种模式// request - 每次写入后fsync数据安全性最高延迟略高// async - 异步刷盘性能最优但可能丢失sync_interval内的数据4.3 Flush流程从内存到磁盘Flush是将内存中的文档持久化为Lucene Segment的过程。触发条件包括Translog大小达到阈值index.translog.flush_threshold_size默认512MB定时触发默认每30分钟自动flush一次手动触发POST /index/_flushFlush执行时内存Buffer中的文档被写入新的Segment文件到磁盘文件系统缓存被同步fsync到物理磁盘旧的Translog被清空开始写入新的Translog// 手动触发FlushPOST/shop/_flush// 强制刷新立即将内存数据写入Segment但不做fsyncPOST/shop/_refresh// 查看Translog状态GET/shop/_stats/translog?pretty4.4 refresh vs flush vs fsync 区别操作作用频率对搜索的影响refresh将内存Buffer写入新Segment打开Segment供搜索默认1秒/次新文档立即可搜索flush执行refreshfsync清空Translog30分钟或512MB不直接影响搜索fsync确保文件系统缓存同步到物理磁盘Flush时触发保证数据持久化五、Lucene Segment的合并机制5.1 什么是SegmentLucene中的索引由多个不可变的**Segment段**组成。每次refresh都会创建一个新的Segment随着时间推移索引中会积累大量小Segment。写入时间线 t1: refresh → Segment_1 小 t2: refresh → Segment_2 小 t3: refresh → Segment_3 小 ... t100: 积累了100个小Segment 问题 - 搜索时需要打开所有Segment文件句柄开销大 - 每个Segment独立存储Term字典内存占用高 - 删除文档只是标记为删除占用空间5.2 Segment合并MergeLucene在后台自动执行Segment合并将多个小Segment合并为一个大Segment并在此过程中物理删除已标记删除的文档。// 查看索引的Segment信息GET/shop/_segments?pretty// 手动触发强制合并生产环境谨慎使用POST/shop/_forcemerge?max_num_segments1// 查看Merge进度GET/_cat/segments/shop?vhindex,segment,size,docs.count5.3 Force Merge注意事项强制合并会消耗大量CPU和I/O资源建议在业务低峰期执行只对不再写入的只读索引执行max_num_segments1表示合并为最优单个Segment六、总结与最佳实践核心要点回顾分片路由公式shard hash(_routing) % num_primary_shards决定了文档的存储位置主分片数量因此在索引创建后不能修改。文档写入流程严格遵循协调节点路由→主分片写入Translog→内存Buffer构建索引→同步副本→返回成功。Translog的WAL机制是数据不丢失的保证。wait_for_active_shards参数在数据安全性和写入延迟之间提供了灵活的平衡点根据业务场景合理配置。refresh控制搜索可见性flush控制数据持久性两者服务于不同的目标要区分使用场景。最佳实践清单实践建议详细说明合理规划分片数单分片建议10-50GB总文档数不超过2^31创建时预留增长空间使用routing优化查询将强相关的文档路由到同一分片减少搜索分片数Translog配置评估金融场景使用request模式日志场景可用async模式控制refresh频率大量写入时调大refresh_interval如30s减少Segment创建压力避免频繁ForceMerge仅在只读索引上执行且选择业务低峰期副本数合理配置副本数≥1保证可用性读多场景可增加副本分担查询监控Segment数量单分片Segment保持50以内超出时考虑合并上一篇【第43篇】Elasticsearch搜索过程原理——分词、查询树与BM25评分下一篇【第45篇】Elasticsearch分布式检索原理——Query Then Fetch两阶段搜索
