现象
某日线上业务同学反馈订单列表查询页面一直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
- 后端接口么有校验,导致用户复制输入错误信息,也会去做查询操作,未做查询条件的过滤