1. 当你的Elasticsearch开始"喘粗气"

三周前还能每秒处理5000条日志的集群，现在处理300条都开始卡顿。这就像你家楼下的早餐店，原本5分钟就能取到豆浆油条，现在排半小时队还拿不到号。最近接手的一个智能家居项目就遇到了这种情况：设备状态写入延迟从20ms飙升到1200ms，用户投诉量直接翻了三倍。

示例现象（技术栈：Elasticsearch 7.17 + Kibana）：

// 某智能门锁写入耗时监控（单位：毫秒）
{
  "2023-08-01": {"avg": 28, "p95": 35},
  "2023-08-15": {"avg": 152, "p95": 380},
  "2023-09-01": {"avg": 890, "p95": 1250}
}
// 注释：p95表示95%请求的耗时低于该值

2. 揭开性能衰减的神秘面纱

2.1 数据碎片：存储空间的"头皮屑"

每次删除/更新操作都会产生碎片残留，就像书架上被撕掉几页的书本。某电商平台曾因频繁更新商品库存，3个月后索引碎片率达到42%，查询速度降低60%。

2.2 索引膨胀：不可承受之"胖"

未优化的Mapping就像衣柜里塞满的冬装，当某社交APP的私信索引达到500GB时，写入延迟开始呈指数级增长。

示例问题Mapping（技术栈：Elasticsearch 7.x）：

PUT chat_messages
{
  "mappings": {
    "properties": {
      "content": {"type": "text", "analyzer": "ik_max_word"},
      "create_time": {"type": "date"},
      "is_read": {"type": "boolean"},
      // 错误示范：所有字段都开启doc_values
      "sender_ip": {"type": "ip", "doc_values": true} 
    }
  }
}
// 注释：doc_values会占用额外存储空间

3. 性能救火队的工具箱

3.1 冷热分层：给数据找个合适的家

就像把当季衣服挂外面，过季的收进储物箱。某智慧城市项目使用该方案后，写入吞吐量提升3倍。

示例配置（技术栈：Elasticsearch 7.9+）：

PUT _ilm/policy/hot_warm_policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {"max_size": "50gb"},
          "set_priority": {"priority": 100}
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "forcemerge": {"max_num_segments": 1},
          "set_priority": {"priority": 50}
        }
      }
    }
  }
}
// 注释：热节点保留7天，之后迁移到温节点

3.2 定期Force Merge：给索引做"大扫除"

某在线教育平台每月执行一次Force Merge后，索引体积缩小35%，写入速度恢复初始水平的85%。

示例操作（技术栈：Elasticsearch 6.8+）：

POST /logs-2023.08/_forcemerge?max_num_segments=1
# 注意：避免在业务高峰期操作

4. 实战中的十八般武艺

4.1 日志分析场景

某金融系统采用如下方案：

  • 按小时创建索引
  • 开启慢日志监控
  • 使用gzip压缩 结果：日志写入QPS稳定在1.2万/秒

4.2 电商搜索场景

优化方案：

  • 商品详情与搜索索引分离
  • 禁用非必要字段的norms
  • 使用keyword类型处理固定枚举值 成效：促销期间搜索延迟稳定在200ms内

5. 技术方案的AB面

5.1 冷热分层

优点：成本降低40%，写入性能提升 缺点：需要SSD和HDD混合部署

5.2 Force Merge

优点：立竿见影见效快 缺点：合并期间可能影响查询性能

6. 老司机留下的警示牌

  1. 别在周五下午做Force Merge（除非想周末加班）
  2. ILM策略要先在测试环境"试驾"
  3. Mapping设计要像装修房子——提前规划
  4. 监控磁盘IOPS比盯着CPU更有用

7. 写在最后

维护Elasticsearch就像照顾一盆名贵兰花：需要定期修剪（Force Merge）、换盆（索引滚动）、调整位置（冷热分层）。某物流公司通过综合运用这些方法，让运行3年的集群依然保持日均2000万次的稳定写入。记住，好的索引维护不是急救药，而是每日维生素——预防永远比治疗更重要。