「已注销」1. Elasticsearch分布式架构解析
Elasticsearch作为分布式搜索引擎的基石，其架构设计决定了它处理海量数据的能力。与单机版搜索引擎不同，分布式架构需要解决数据分布、请求路由、节点协作等一系列复杂问题。
1.1 集群与节点角色
一个Elasticsearch集群由多个节点(Node)组成，每个节点在启动时会自动加入集群。节点根据承担的角色不同分为：
-
主节点(Master-eligible node)：负责集群范围内的轻量级操作，如创建/删除索引、跟踪节点状态、决定分片分配等。生产环境建议设置3个专用主节点以避免脑裂问题。
-
数据节点(Data node)：存储分片数据，执行与数据相关的操作（CRUD、搜索、聚合等）。这是资源消耗最大的节点类型，需要足够的CPU、内存和磁盘IO。
-
协调节点(Coordinating node)：接收客户端请求，将请求路由到正确的分片，收集结果后返回给客户端。所有节点默认都是协调节点，但在大规模集群中可设置专用协调节点。
-
Ingest节点：在索引文档前执行预处理管道。例如，可以使用Ingest节点添加字段、解析JSON等。
提示：通过设置
node.roles可以精确控制节点角色。例如配置node.roles: [ data, ingest ]表示该节点同时承担数据和预处理职责。
1.2 分片(Shard)机制详解
分片是Elasticsearch实现水平扩展的核心机制。当创建一个索引时，可以指定主分片(Primary Shard)数量，这个数量决定了索引能存储的最大数据量（因为单个分片存储的数据量有限）。
分片特性：
- 每个分片都是一个完整的Lucene索引，可以独立处理查询请求
- 主分片数量在索引创建后无法修改（除非使用Reindex API重建索引）
- 副本分片(Replica Shard)是主分片的拷贝，提供数据冗余和读取吞吐量
- 分片分配遵循均匀分布原则，避免单个节点负载过高
分片数量权衡：
- 分片过少会导致：单分片数据量过大、无法充分利用集群资源、扩容困难
- 分片过多会导致：资源开销增大、查询延迟增加（需要合并更多分片的结果）
- 通用建议：单个分片数据量控制在30-50GB，对于时间序列数据可按日期滚动创建索引
1.3 分布式写入流程
当文档被索引时，Elasticsearch需要确定它应该存储在哪个分片上。这个过程涉及两个关键步骤：
-
路由计算：默认使用文档ID的哈希值决定目标分片，公式为：
code复制shard_num = hash(_routing) % number_of_primary_shards其中
_routing默认为文档_id，也可以自定义路由值。这意味着相同路由值的文档会被存储到同一个分片。 -
写入协调：
- 客户端请求发送到协调节点
- 协调节点根据路由计算确定主分片位置
- 将请求转发给主分片所在的数据节点
- 主分片执行写入操作后，并行将写入请求转发给所有副本分片
- 等待所有副本分片响应（可通过
wait_for_active_shards参数控制）
注意：副本分片的写入是异步的，这意味着短时间内可能出现主副分片数据不一致的情况。对于关键业务，可以通过设置
refresh=wait_for等待写入可见。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 路由策略与分片控制
2.1 自定义路由优化
默认的文档路由策略可能导致分片间数据分布不均，特别是在业务数据有天然分区的情况下（如用户ID、租户ID等）。通过自定义路由可以显著提升查询效率：
json复制PUT my-index/_doc/1?routing=user123
{
"title": "Document for user123",
"content": "..."
}
路由使用场景：
- 用户数据隔离：将同一用户的所有文档路由到相同分片，查询时指定路由可避免全分片扫描
- 时间序列数据：使用日期作为路由值，便于冷热数据分离
- 多租户系统：以租户ID为路由，实现租户数据的物理隔离
路由使用注意事项：
- 路由字段值需要足够分散，避免数据倾斜
- 查询时必须指定相同的路由值才能命中目标分片
- 可以在索引模板中设置`rou