前言
这是帅丙真实事件，大家都知道很多公司都是有故障等级这么一说的，这就是敖丙在公司背的P0级故障，敖丙差点因此被解雇，事情经过十分惊心动魄，我的心脏病都差点复发。
事故等级主要针对生产环境，划分依据类似于bug等级。
P0属于最高级别事故，比如崩溃，页面无法访问，主流程不通，主功能未实现，或者在影响面上影响很大（即使bug本身不严重）。
P1事故属于高级别事故，一般属于主功能上的分支，支线流程，核心次功能等，后面还有P2，P3等，主要根据企业实际情况划分。
正文
敖丙之前也负责公司的商品搜索业务，因为业务体量增速太快了，商品表中的商品数据也很快跃入千万级别，查询的RT（response time 响应时间）也越来越高了，而且产品说需要根据更多维度去查询商品。
因为之前我们都是根据商品的名称去查询的，但是电商其实都会根据很多个维度去查询商品。
就比如大家去淘宝的查询的时候就会发现，你搜商品名称、颜色、标签等等多个维度都可以找到这个商品，就比如下图的搜索，我只是搜了【帅丙】你会发现，名字里面也没有连续的帅丙两个字，有帅和丙的出来了
开玩笑的哈，不过当时敖丙真的要死的心真的都要有了，就在崩掉的1分钟内，就有用户反馈搜索未响应，我第一时间想到的就是重启，于是我一个健步冲出去，开启电脑，进机器，输入了重启命令。
好了，是的好了，还好有惊无险，不过只过了10秒，集群又99%了，呐呢？
Es有Bug！没错肯定是Es的锅。
那为啥会这样呢，我直接跟老大这样解释也好像不行啊，还是要被开除的吧！
于是我去看看看代码，我在关键词使用了通配符，我当时是为了匹配更多内容才这么做的，类似数据库的like，Es的通配符就是： * 帅丙 * 这样在关键词前后加“*”号去查询。
后面我发现就是通配符的锅，那柯南丙就说一下为啥会这样的问题出现。
许多有RDBMS/SQL背景的开发者，在初次踏入ElasticSearch世界的时候，很容易就想到使用通配符(Wildcard Query)来实现模糊查询（比如用户输入补全)，因为这是和SQL里like操作最相似的查询方式，用起来感觉非常舒适。
然而帅丙的故障就揭示了，滥用Wildcard query可能带来灾难性的后果。
我当时首先复现了问题
复现方法
- 创建一个只有一条文档的索引
POST test_index/type1/?refresh=true
{
“foo”: “bar”
}
2.使用wildcard query执行一个首尾带有通配符*的长字符串查询
POST /test_index/_search
{
“query”: {
“wildcard”: {
“foo”: {
“value”: “轻轻的我走了，正如我轻轻的来；我轻轻的招手，作别西天的云彩。那河畔的金柳，是夕阳中的新娘；波光里的艳影，在我的心头荡漾。软泥上的青荇，油油的在水底招摇；在康河的柔波里，我甘心做一条水草！那榆荫下的一潭，不是清泉，是天上虹；揉碎在浮藻间，沉淀着彩虹似的梦。寻梦？撑一支长篙，向青草更青处漫溯；满载一船星辉，在星辉斑斓里放歌。但我不能放歌，悄悄是别离的笙箫；夏虫也为我沉默，沉默是今晚的康桥！悄悄的我走了，正如我悄悄的来；我挥一挥衣袖，不带走一片云彩。”
}
}
}
}
- 查看结果
{
“took”: 3445,
“timed_out”: false,
“_shards”: {
“total”: 5,
“successful”: 5,
“failed”: 0
},
“hits”: {
“total”: 0,
“max_score”: null,
“hits”:
}
}
线上的查询比我这个范例要复杂得多，会同时查几个字段，实际测试下来，一个查询可能会执行十几秒钟。
再有比较多长字符串查询的时候，集群可能就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就像下面这个图一样:
image-20191204205715057
