背景
事情是這樣的。一天下午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只處理復雜查詢請求。