记一次线上es慢查询导致的服务不可用

现象

某日线上业务同学反馈订单列表查询页面一直loding，然后提示请求超时，几分钟之后恢复正常

• 接到报障之后，马上根据接口URL，定位到了请求链路，发现是es查询超时，这里我们的业务订单表数据是由几百万的，所以列表查询用的es，

• 根据请求日志拿到查询es 的参数，在es控制台查询，请求响应时间200ms，初步估计不是这条查询导致，
  

• 在线上搜索同类报错日志，找到了最初报超时的请求记录,4个字段使用统一查询条件的模糊查询，这条查询在es控制台查询时间为6秒左右，询问当时操作的业务同学，是当时复制错误信息，不是正常的搜索请求

  {"commodityName":{"wildcard":"*云汉路线业绩目标： 1W/业绩线索：-----------------------------------需求数：10/拜访目标10/ 拜访路径安排：上午：：：润锦，潮工作室，锐城凯，源衣坊，下午：：：程逸，精盈，鸿逸，徜仕，三通，富顺，悦富。田亮，汉美森服饰。堡伦，————————————末成交访客户：，重磅服饰，荣鑫服饰*","boost":1.0}}},{"wildcard":{"commodityNumbers":{"wildcard":"*云汉路线业绩目标： 1W/业绩线索：-----------------------------------需求数：10/拜访目标10/ 拜访路径安排：上午：：：润锦，潮工作室，锐城凯，源衣坊，下午：：：程逸，精盈，鸿逸，徜仕，三通，富顺，悦富。田亮，汉美森服饰。堡伦，————————————末成交访客户：，重磅服饰，荣鑫服饰*","boost":1.0}}},{"wildcard":{"commodityCode":{"wildcard":"*云汉路线业绩目标： 1W/业绩线索：-----------------------------------需求数：10/拜访目标10/ 拜访路径安排：上午：：：润锦，潮工作室，锐城凯，源衣坊，下午：：：程逸，精盈，鸿逸，徜仕，三通，富顺，悦富。田亮，汉美森服饰。堡伦，————————————末成交访客户：，重磅服饰，荣鑫服饰*","boost":1.0}}},{"wildcard":{"parentCommodityCode":{"wildcard":"*云汉路线业绩目标： 1W/业绩线索：-----------------------------------需求数：10/拜访目标10/ 拜访路径安排：上午：：：润锦，潮工作室，锐城凯，源衣坊，下午：：：程逸，精盈，鸿逸，徜仕，三通，富顺，悦富。田亮，汉美森服饰。堡伦，————————————末成交访客户：，重磅服饰，荣鑫服饰*","boost":1.0}}},{"term":{"xid":{"value":"云汉路线业绩目标： 1W/业绩线索：-----------------------------------需求数：10/拜访目标10/ 拜访路径安排：上午：：：润锦，潮工作室，锐城凯，源衣坊，下午：：：程逸，精盈，鸿逸，徜仕，三通，富顺，悦富。田亮，汉美森服饰。堡伦，————————————末成交访客户：，重磅服饰，荣鑫服饰","boost":1.0}}},{"term":{"yid":{"value":"云汉路线业绩目标： 1W/业绩线索：-----------------------------------需求数：10/拜访目标10/ 拜访路径安排：上午：：：润锦，潮工作室，锐城凯，源衣坊，下午：：：程逸，精盈，鸿逸，徜仕，三通，富顺，悦富。田亮，汉美森服饰。堡伦，————————————末成交访客户：，重磅服饰，荣鑫服饰","boost":1.0}}},{"term":{"sid":{"value":"云汉路线业绩目标： 1W/业绩线索：-----------------------------------需求数：10/拜访目标10/ 拜访路径安排：上午：：：润锦，潮工作室，锐城凯，源衣坊，下午：：：程逸，精盈，鸿逸，徜仕，三通，富顺，悦富。田亮，汉美森服饰。堡伦，————————————末成交访客户：，重磅服饰，荣鑫服饰","boost":1.0}}},{"term":{"hid":{"value":"云汉路线业绩目标： 1W/业绩线索：-----------------------------------需求数：10/拜访目标10/ 拜访路径安排：上午：：：润锦，潮工作室，锐城凯，源衣坊，下午：：：程逸，精盈，鸿逸，徜仕，三通，富顺，悦富。田亮，汉美森服饰。堡伦，————————————末成交访客户：，重磅服饰，荣鑫服饰","boost":1.0}
  

• 通过日志统计，发现该接口当天请求此时在2W次以上，我们是公司业务自用的系统，按道理说不会有这么大的请求量，然后根据请求日志发现了一个很骚的事情，原来的交互设计是每输入一个字，前端就会请求后端去做实时的搜索

  

• 运维同学根据，保障的时间段，也发现了当时es服务器，cpu和内存使用的飙升

解决

• 前端修改交互方式，去掉实时搜索的处理，
• 后端接口增加拦截，过滤不合逻辑的无效请求

总结

• 查询交互设计不合理，报错的es索引，在es库是一个数据量很大的索引，这病频繁请求会导致cpu和频繁的gc
• 后端接口么有校验，导致用户复制输入错误信息，也会去做查询操作，未做查询条件的过滤