背景
事情是這樣的，一天下午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)升級硬體，換成SSD2)分片改成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只處理復雜查詢請求，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/46400.html
標籤：架構設計
下一篇：springcloud vue.js 微服務分布式 前后分離 集成代碼生成器 shiro權限 activiti作業流