前言
这是帅丙真实事件，大家都知道很多公司都是有故障等级这么一说的，这就是敖丙在公司背的P0级故障，敖丙差点因此被解雇，事情经过十分惊心动魄，我的心脏病都差点复发。
正文
敖丙之前也负责公司的商品搜索业务，因为业务体量增速太快了，商品表中的商品数据也很快跃入千万级别，查询的RT（response time 响应时间）也越来越高了，而且产品说需要根据更多维度去查询商品。
因为之前我们都是根据商品的名称去查询的，但是电商其实都会根据很多个维度去查询商品。
就比如大家去淘宝的查询的时候就会发现，你搜商品名称、颜色、标签等等多个维度都可以找到这个商品，就比如下图的搜索，我只是搜了【帅丙】你会发现，名字里面也没有连续的帅丙两个字，有帅和丙的出来了
大家知道的传统的关系型数据库都是用什么 name like %帅丙% 这样的方式查询的，而且查询出来的结果肯定只能是name里面带帅丙的对吧。
那你还想搜别的字段比如什么尺寸、关键词、价格等等，都能搜到帅丙，这相当于是多个维度的了，传统的关系型数据库做不到呀。
做技术选型的时候，帅丙第一时间想到了搜索引擎。
当时市面是比较流行的有：Apache Lucene、Elasticsearch、Solr
搜索引擎我后面会讲ELK（Elasticsearch、Logstash、Kibana）和Canal，我呀真的是太宠你们了，这样会不会把你们惯坏了。
帅丙我呀，噼里啪啦一顿操作，最后得出结论：
那我们商品还是要实时的呀，你后台改了价格啥的，是不是都要实时同步出去，不然不是炸了嘛。
看到这，我想可爱的你和帅丙心中都有了答案：Elasticsearch这是个神一样的引擎。
我这里就做一个简单的介绍就好了，细节的点我们后面去他的章节讲，啥都写了，敖丙哪里有这么多素材写文章？
看过敖丙之前文章的朋友都知道，我们做技术选型之前，要做什么呀，设计！
我们要去了解这玩意的好处、坏处、常见的坑、出了问题的应急预案等等，还有他的数据同步机制啊，持久化机制啥的，就是高可用嘛。
同样的我不大篇幅介绍了，以后都会写的嘛，我就给大家看看我当时做的设计吧。
这个只是最初的demo，详细的终稿我就不给大家看了，因为有很多公司内部的逻辑。
不过大家还是可以看到敖丙真的考虑了很多，还是那句话，不打没把握的仗！
设计做好敖丙就卡卡卡的用起来了。
说实话，真香，这玩意真的好用，学习成本也很低，查询语句分分钟掌握了，官网文档把功能介绍得清晰无比。
用着用着重头戏来了，你们都知道敖丙我是做电商活动的，都是什么很高的流量打进来这样，还是如往常一样上线了一个活动。
这是一个月飞风高的夜晚，丝丝凉风迎面吹来，敖丙悠闲的坐在椅子上，手里拿着破旧的茶杯，喝着外婆炒的苦荆茶，享受着这惬意的时光。
突然，说时迟那时快，运维打来了紧急电话ES集群CPU打到了99%要挂了，我的心蓦然一痛，心里还在庆幸还是集群没崩。
然后他接着说了一句，不好集群挂了！
敖丙卒，本篇完….
开玩笑的哈，不过当时敖丙真的要死的心真的都要有了，就在崩掉的1分钟内，就有用户反馈搜索未响应，我第一时间想到的就是重启，于是我一个健步冲出去，开启电脑，进机器，输入了重启命令。
好了，是的好了，还好有惊无险，不过只过了10秒，集群又99%了，呐呢？
我又只能重启了，这次没挂，过了很久很久，直到活动结束，还是没挂。
查找问题
但是这次影响到线上，3分钟的搜索未响应，我想我估计明天是要去财务领工资，提前回家过年了。
还好Leader说没事，先找到问题，把他修复掉。
你们都知道敖丙天才来的，我第一时间想到的就是看日志，我登上去看es没报错，再看本身的服务，除了超时的错误啥都没有，卧槽，是的当时我脑袋嗡嗡响。
不过我继续想为啥是我的搜索挂了，会不会是有人搜了什么奇怪的东西？
我打开了我的搜索日志！！！
卧槽这不是吧，哪个坑爹玩意搜这么长的一串中文，差不多250个字吧。
但是我一想，搜这么长也不应该打挂服务啊，会不会是我写了bug！
我脸颊流下一滴汗水