害阿里程序员差点被当场开除的P0事故

前言

这是帅丙真实事件,大家都知道很多公司都是有故障等级这么一说的,这就是敖丙在公司背的P0级故障,敖丙差点因此被解雇,事情经过十分惊心动魄,我的心脏病都差点复发

事故等级主要针对生产环境,划分依据类似于bug等级。

P0属于最高级别事故,比如崩溃,页面无法访问,主流程不通,主功能未实现,或者在影响面上影响很大(即使bug本身不严重)。

P1事故属于高级别事故,一般属于主功能上的分支,支线流程,核心次功能等,后面还有P2,P3等,主要根据企业实际情况划分。

正文

敖丙之前也负责公司的商品搜索业务,因为业务体量增速太快了,商品表中的商品数据也很快跃入千万级别,查询的RT(response time 响应时间)也越来越高了,而且产品说需要根据更多维度去查询商品

因为之前我们都是根据商品的名称去查询的,但是电商其实都会根据很多个维度去查询商品。

就比如大家去淘宝的查询的时候就会发现,你搜商品名称、颜色、标签等等多个维度都可以找到这个商品,就比如下图的搜索,我只是搜了【帅丙】你会发现,名字里面也没有连续的帅丙两个字,有帅和丙的出来了

害阿里程序员差点被当场开除的P0事故

害阿里程序员差点被当场开除的P0事故

开玩笑的哈,不过当时敖丙真的要死的心真的都要有了,就在崩掉的1分钟内,就有用户反馈搜索未响应,我第一时间想到的就是重启,于是我一个健步冲出去,开启电脑,进机器,输入了重启命令。

好了,是的好了,还好有惊无险,不过只过了10秒,集群又99%了,呐呢?

害阿里程序员差点被当场开除的P0事故

Es有Bug!没错肯定是Es的锅。

那为啥会这样呢,我直接跟老大这样解释也好像不行啊,还是要被开除的吧!

于是我去看看看代码,我在关键词使用了通配符,我当时是为了匹配更多内容才这么做的,类似数据库的like,Es的通配符就是: * 帅丙 * 这样在关键词前后加“*”号去查询

后面我发现就是通配符的锅,那柯南丙就说一下为啥会这样的问题出现。

许多有RDBMS/SQL背景的开发者,在初次踏入ElasticSearch世界的时候,很容易就想到使用通配符(Wildcard Query)来实现模糊查询(比如用户输入补全),因为这是和SQL里like操作最相似的查询方式,用起来感觉非常舒适。

然而帅丙的故障就揭示了,滥用Wildcard query可能带来灾难性的后果

我当时首先复现了问题

复现方法

  1. 创建一个只有一条文档的索引

POST test_index/type1/?refresh=true

{

“foo”: “bar”

}

2.使用wildcard query执行一个首尾带有通配符*的长字符串查询

POST /test_index/_search

{

“query”: {

“wildcard”: {

“foo”: {

​ “value”: “轻轻的我走了,正如我轻轻的来;我轻轻的招手,作别西天的云彩。那河畔的金柳,是夕阳中的新娘;波光里的艳影,在我的心头荡漾。软泥上的青荇,油油的在水底招摇;在康河的柔波里,我甘心做一条水草!那榆荫下的一潭,不是清泉,是天上虹;揉碎在浮藻间,沉淀着彩虹似的梦。寻梦?撑一支长篙,向青草更青处漫溯;满载一船星辉,在星辉斑斓里放歌。但我不能放歌,悄悄是别离的笙箫;夏虫也为我沉默,沉默是今晚的康桥!悄悄的我走了,正如我悄悄的来;我挥一挥衣袖,不带走一片云彩。”

}

}

}

}

  1. 查看结果

{

“took”: 3445,

“timed_out”: false,

“_shards”: {

“total”: 5,

“successful”: 5,

“failed”: 0

},

“hits”: {

“total”: 0,

“max_score”: null,

“hits”:

}

}

害阿里程序员差点被当场开除的P0事故

线上的查询比我这个范例要复杂得多,会同时查几个字段,实际测试下来,一个查询可能会执行十几秒钟。

再有比较多长字符串查询的时候,集群可能就DOS了。

探查深层次根源

为什么对只有一条数据的索引做这个查询开销这么高? 直觉上应该是瞬间返回结果才对!

回答这个问题前,可以再做个测试,如果继续加大查询字符串的长度,到了一定长度后,ES直接抛异常了,服务ES里异常给出的cause如下:

Caused by: org.apache.lucene.util.automaton.TooComplexToDeterminizeException: Determinizing automaton with 22082 states and 34182 transitions would result in more than 10000 states. at org.apache.lucene.util.automaton.Operations.determinize(Operations.java:741) ~[lucene-core-6.4.1.jar:6.4.1

解释:该异常来自org.apache.lucene.util.automaton这个包,异常原因的字面含义是说“自动机过于复杂而无法确定状态: 由于状态和转换太多,确定一个自动机需要生成的状态超过10000个上限

柯南丙网上查找了大量资料后,终于搞清楚了问题的来龙去脉。

为了加速通配符和正则表达式的匹配速度,Lucene4.0开始会将输入的字符串模式构建成一个DFA (Deterministic Finite Automaton),带有通配符的pattern构造出来的DFA可能会很复杂,开销很大

比如a*bc构造出来的DFA就像下面这个图一样:

害阿里程序员差点被当场开除的P0事故

image-20191204205715057

害阿里程序员差点被当场开除的P0事故

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注