一、需求分析与技术选型

1.1 商品搜索核心需求

电商场景下，商品搜索引擎需满足三大核心需求：实时性（库存/价格变动秒级同步）、准确性（多维度过滤与排序）、高并发（支撑百万级QPS）。以某头部电商为例，其商品库超5亿条，每日搜索请求达数十亿次，对ES集群的稳定性与扩展性提出极高要求。

1.2 技术选型依据

Elasticsearch凭借其分布式架构、近实时搜索、灵活的数据模型成为首选。对比Solr，ES在写入性能、集群管理（如自动分片、副本恢复）方面更优；而ClickHouse等OLAP引擎虽擅长分析，但缺乏全文检索能力。最终选择ES 7.x版本，兼顾稳定性与新特性（如ECK运维工具）。

二、集群规划与硬件配置

2.1 节点角色分配

采用数据节点（Data）、协调节点（Coordinating）、主节点（Master）分离架构：

• 数据节点：32核128G内存，配置SSD盘（IOPS≥50K），负责存储与查询
• 协调节点：16核64G内存，屏蔽客户端直接访问数据节点
• 主节点：8核32G内存，3节点集群避免脑裂

2.2 分片策略设计

分片数计算公式：
分片数 = 最大数据量(GB) / 单分片容量(GB) * 副本系数
示例：若单商品平均1KB，5亿商品≈500GB，按单分片50GB计算，需10个主分片+2副本，共30个分片。实际配置中，将分片数设为节点数的整数倍（如每节点承载3个分片），避免资源倾斜。

三、数据建模与索引优化

3.1 字段类型选择

关键字段设计示例：

{
  "mappings": {
    "properties": {
      "title": { "type": "text", "analyzer": "ik_max_word" },  // 中文分词
      "price": { "type": "scaled_float", "scaling_factor": 100 },  // 价格精确到分
      "category_ids": { "type": "keyword" },  // 分类ID数组
      "sales": { "type": "long" },  // 销量用于排序
      "update_time": { "type": "date", "format": "epoch_millis" }  // 毫秒级时间戳
    }
  }
}

3.2 索引优化技巧

• 动态模板：对description等长文本字段禁用norms，节省存储
• 嵌套对象：商品规格（如颜色/尺寸）使用nested类型，避免扁平化查询错误
• 索引生命周期：热数据（近30天）使用高频索引，冷数据归档至低成本存储

四、高可用与容灾设计

4.1 数据冗余策略

• 跨机房复制：通过ES的cross-cluster-replication实现双活
• 快照备份：每日全量快照至S3，增量日志保留7天
• 熔断机制：当节点CPU>85%时，自动拒绝写请求，防止雪崩

4.2 查询链路优化

• 缓存层：在协调节点部署Redis，缓存热门商品ID列表
• 异步刷新：对非实时数据（如商品详情）设置refresh_interval=30s
• 降级策略：当ES不可用时，自动切换至MySQL分页查询

五、性能调优实战

5.1 写入性能优化

• 批量写入：使用Bulk API，单批1000条文档，耗时<50ms
• 线程池调整：

  thread_pool.write.size: 32  # 写入线程数=CPU核心数*2
  thread_pool.write.queue_size: 1000  # 避免队列堆积

• 索引合并：设置index.merge.scheduler.max_thread_count=1（SSD场景）

5.2 查询性能优化

• 过滤缓存：对category_id等高频过滤字段使用doc_values
• 排序优化：对price等数值字段启用fielddata，避免script_score计算
• 分页控制：深度分页（>10000条）改用search_after替代from/size

六、监控与运维体系

6.1 核心指标监控

• 集群健康度：green/yellow/red状态、未分配分片数
• 查询性能：search.latency（P99<200ms）、query_total
• 资源使用：JVM堆内存（<70%）、磁盘IOPS（<80%）

6.2 自动化运维

• 扩容脚本：通过ECK API动态添加节点，自动平衡分片
• 滚动重启：分批次重启节点，确保至少一个副本可用
• 告警规则：当circuit_breaker触发时，立即通知运维团队

七、进阶功能实现

7.1 拼写纠错

基于completion建议器实现：

PUT /products/_search
{
  "suggest": {
    "did_you_mean": {
      "text": "iphon",
      "term": {
        "field": "title",
        "suggester": "my_suggester"
      }
    }
  }
}

7.2 相关性调权

使用bool查询组合多字段权重：

{
  "query": {
    "bool": {
      "should": [
        { "match": { "title": { "query": "手机", "boost": 3 }}},
        { "match": { "keywords": { "query": "手机", "boost": 2 }}}
      ]
    }
  }
}

八、总结与避坑指南

1. 分片过大：单分片超过50GB会导致恢复时间过长，建议控制在20-30GB
2. 字段映射错误：误将text类型用于精确匹配，导致term查询失效
3. 线程池耗尽：未限制批量写入大小，引发EsRejectedExecutionException
4. 冷热数据混部：将历史数据索引与热数据放在同一节点，影响查询性能

通过上述方法，某电商平台成功构建了支撑亿级商品的ES搜索引擎，日均处理查询请求120亿次，P99延迟控制在180ms以内。实际部署时，建议先在测试环境模拟压测（如使用Rally工具），再逐步灰度上线。