Elasticsearch實戰-磁碟IO被打滿

背景

事情是這樣的。一天下午4點42分左右。業務反饋我開發的服務在測試環境出現問題，返回資源數據是0。查日誌發現是ES訪問超時。相當於資料庫掛了。持續了20多分鐘自己恢復。
咨詢了ES團隊，最終得到下麵的答覆：

當前集群現狀:
1）當前集群數據IO最高的索引為XXX，數據量很小(100mb) 
2)但是讀寫都很大(讀>1000QPS,寫>1000QPS) ，使用的是線下環境的機器
3)索引分了10個片，4個副本問題
分析:
1)線下環境的機器之前瞭解到測試環境硬碟性能本來就很差,這個需要業務SRE一塊來確定
2)查詢的時候，會一次性查詢10個片，這樣可能會查10台機器的數據，很容易出現木桶效應，造成集群的性能下降
3)寫入的時候，雖然是做了10個分片，看起來能加大寫能力，但是機器數少，導致結果是每台機器分佈了5個分片，等效於只做了2個分片，完全沒有擴大寫的能力
建議:
1)升級硬體，換成SSD
2)分片改成2個，這樣讀能力比以前肯定有提升，寫能力等價
3)數據量很小，建議直接換成Redis

我自己做了調查。測試環境ES有十臺VM（非本地ESB磁碟）作為伺服器。其中一臺IO被打滿。其他機器負載、IO都很低。對於這個問題，ES團隊給出的答覆是：

ES的服務負載均衡、發現機制是自己寫的，一般不會出現問題，
Client僅僅對官方的客戶端做了簡單的封裝，
當然最好是可以對官方的客戶端進行改造，
但是我們現在的人力明顯不行，只能繼續沿用老的客戶端使用；
我們預計在10月份左右會出一個自研的客戶端，
會儘量避免出現一臺機器導致部分查詢出現問題，
但是也避免不了，
ES內部的服務發現機制，我們改變不了，除非改ES

調查

1.需要換成本地磁碟，測試環境也是我們的正式環境。是否能直接替換成物理機？多少台合適？怎麼可以平滑替換？

沒有必要換成物理機。因為ES記憶體最多能用32G。記憶體多出來的是浪費用不上，有物理機也是隔成VM來用。

原來10台VM是足夠的，只需要同等數量替換。

有機器替換功能。替換時原理是先申請機器部署。然後點擊機器替換。會一臺台的將分片趕到新機器上。一臺下完自動下線老機器。

2.我們測試環境有10台伺服器，10個分片，4個副本，寫/讀QPS大概是7：6。究竟幾個分片幾個索引更合理？

因為每個分片和副本是同步寫。寫比例大，副本多會對性能有很大影響。分片替換需要重建索引，很難平滑。所以只將副本數減少為一個分片1個。

3.程式方面有沒有可以優化的？

在ES上層增加tair緩存。在進行數據更新操作時是單個數據讀取。採用tair有更好的事務性，並減少了對ES的壓力。ES只處理複雜查詢請求。