社区微信群开通啦，扫一扫抢先加入社区官方微信群
社区微信群
欢迎关注鄙人公众号，技术干货随时看！
https://wenku.baidu.com/view/8ff2ce94591b6bd97f192279168884868762b8e7
https://wenku.baidu.com/view/24cfee1ce43a580216fc700abb68a98270feac21
elasticsearch client 即TransportClient（最常用的一个实现），一定要使用单例模式，不懂单例模式的自己去学！不用单例模式的代价是残酷的，鄙人作为开发经理，曾被一个二笔开发坑得一塌糊涂，原因就是这个二笔把client封装成了线程池（越是二笔往往 越以为自己是大神，鄙人还没见过几个能自己写线程池的大神）！鄙人下面讲述下事故的过程。鄙认作为工学硕士，自知不才，但鄙人通读lucene、solr、elasticsearch源码，有自信elasticsearch稳定性极高，一般的并发量绝不会挂机，事实证明也从来没挂过机！但是，鄙认就遇到了并发一秒并发20的请况下，客户那边反馈查询全部超时， elasticsearch集群报出了如下错误：
有经验的人不难看出，是连接数超出了elasticsearch等待队列的长度1000（默认设置，官方强烈建议不要修改），打开header集群依然是绿色，但已经不再接受客户端请求(http服务类的程序一般会有三个线程池，等待、监听和处理线程池，无论是tomcat、jetty，当然elasticsearch也不例外，当等待请求超过等待队列的线程上限时，就直接返回超时)。鄙人当时查看了并发量，一秒不到20，根据经验绝对不是并发过高问题。因为是线上问题，快速回复服务是第一位的，重启所有机器无效，然后把服务从f5下线，重启集群，f5拉上线后，依然是大面积超时！迫于无奈，当时用物理机临时扩容硬抗。接下来，鄙人为了查明原因，从头到尾把二笔的es接口代码和client源码读了一遍，最终怀疑是client创建过多造成了，这位二笔开发自己把client写成了线程池，频繁的创建释放client。下面看下client的源码：
我们可以看到，client本身就是线程池，一个cient会占用大量的线程。elasticsearch集群报错的就是标红的那一行代码，
等待请求超过了1000。鄙人把elasticsearch接口代码client改成了单例模式，然后进行对比压测，出现大量超市时，并发量相差100倍。 client一定要用单例模式，或者更好的方式是使用restful接口，因为官方已经声明elasticsearch后续会deprecated client。
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
