起因
呃，中午準備吃飯的時候，突然發(fā)現(xiàn)產(chǎn)品的搜索功能掛了，沒辦法，只能放下手里的碗，抱起前面的磚準備開始排查問題。
排查過程
連接線上服務器，查詢ERROR日志，果然一堆ES相關(guān)報錯，初步懷疑是公司內(nèi)部DBIndex服務（內(nèi)部基于dubbo封裝的提供者，用于app端查詢的服務）掛了。
-
連接DBIndex服務所在機器，查詢服務進程狀態(tài)，發(fā)現(xiàn)沒什么問題，繼續(xù)查看日志，發(fā)現(xiàn)一堆類似的錯誤。如圖：
Exception_1.png
看來可以確定是elasticsearch自身服務的問題了，但是具體是什么問題呢，一頓度娘，谷哥的操作之后，發(fā)現(xiàn)并沒有一個比較貼切的回答。
-
暫時沒什么頭緒，就繼續(xù)查看錯誤日志，一直翻到報錯的起始點，發(fā)現(xiàn)了一些不一樣的異常信息。如圖：
Exception_2.png
這個錯就比明顯了，大概可以發(fā)現(xiàn)跟ES自身的線程池有關(guān)系。
- 查閱相關(guān)資料后了解到，使用Elasticsearch的時候，在并發(fā)查詢量大的情況下，訪問流量超過了集群中單個Elasticsearch實例的處理能力，Elasticsearch服務端會觸發(fā)保護性的機制，拒絕執(zhí)行新的訪問，并且拋出EsRejectedExecutionException異常。
這個保護機制與異常觸發(fā)是由Elasticsearch API實現(xiàn)中的thread pool與配套的queue決定的。
在示例中，Elasticsearch為index操作分配的線程池，pool size=7，thread = 7, queue capacity=1000，當7個線程處理不過來，并且隊列中緩沖的tasks超過1000個，那么新的task就會被簡單的丟棄掉，并且拋出EsRejectedExecutionException異常。
總結(jié)
最后靠著重啟大法解決了這次的問題。。。我們可以打開 es/configs/elasticsearch.yml 配置一些線程池的參數(shù)，但估計治標不治本，最好的方法還是加機器跑集群吧，單實例始終是單實例。。。
