ES 集群架構演進之路

1、初始階段

訂單中心ES初始階段如一張白紙，架設方案基本沒有，很多配置都是保持集群默認配置。整個集群部署在集團的彈性云上，ES集群的節(jié)點以及機器部署都比較混亂。同時按照集群維度來看，一個ES集群會有單點問題，顯然對于訂單中心業(yè)務來說也是不被允許的。

2、集群隔離階段

和很多業(yè)務一樣，ES集群采用的混布的方式。但由于訂單中心ES存儲的是線上訂單數(shù)據(jù)，偶爾會發(fā)生混布集群搶占系統(tǒng)大量資源，導致整個訂單中心ES服務異常。

顯然任何影響到訂單查詢穩(wěn)定性的情況都是無法容忍的，所以針對于這個情況，先是對訂單中心ES所在的彈性云，遷出那些系統(tǒng)資源搶占很高的集群節(jié)點，ES集群狀況稍有好轉。但隨著集群數(shù)據(jù)不斷增加，彈性云配置已經(jīng)不太能滿足ES集群，且為了完全的物理隔離，最終干脆將訂單中心ES集群部署到高配置的物理機上，ES集群性能又得到提升。

3、節(jié)點副本調優(yōu)階段

ES的性能跟硬件資源有很大關系，當ES集群單獨部署到物理機器上時，集群內部的節(jié)點并不是獨占整臺物理機資源，在集群運行的時候同一物理機上的節(jié)點仍會出現(xiàn)資源搶占的問題。所以在這種情況下，為了讓ES單個節(jié)點能夠使用最大程度的機器資源，采用每個ES節(jié)點部署在單獨一臺物理機上方式。

但緊接著，問題又來了，如果單個節(jié)點出現(xiàn)瓶頸了呢？我們應該怎么再優(yōu)化呢？

ES查詢的原理，當請求打到某號分片的時候，如果沒有指定分片類型（Preference參數(shù)）查詢，請求會負載到對應分片號的各個節(jié)點上。而集群默認副本配置是一主一副，針對此情況，我們想到了擴容副本的方式，由默認的一主一副變?yōu)橐恢鞫?#xff0c;同時增加相應物理機。

訂單中心ES集群架設示意圖

如圖，整個架設方式通過VIP來負載均衡外部請求：

整個集群有一套主分片，二套副分片（一主二副），從網(wǎng)關節(jié)點轉發(fā)過來的請求，會在打到數(shù)據(jù)節(jié)點之前通過輪詢的方式進行均衡。集群增加一套副本并擴容機器的方式，增加了集群吞吐量，從而提升了整個集群查詢性能。

下圖為訂單中心ES集群各階段性能示意圖，直觀地展示了各階段優(yōu)化后ES集群性能的顯著提升：

當然分片數(shù)量和分片副本數(shù)量并不是越多越好，在此階段，我們對選擇適當?shù)姆制瑪?shù)量做了進一步探索。分片數(shù)可以理解為MySQL中的分庫分表，而當前訂單中心ES查詢主要分為兩類：單ID查詢以及分頁查詢。

分片數(shù)越大，集群橫向擴容規(guī)模也更大，根據(jù)分片路由的單ID查詢吞吐量也能大大提升，但聚合的分頁查詢性能則將降低；分片數(shù)越小，集群橫向擴容規(guī)模也更小，單ID的查詢性能也會下降，但分頁查詢的性能將會提升。

所以如何均衡分片數(shù)量和現(xiàn)有查詢業(yè)務，我們做了很多次調整壓測，最終選擇了集群性能較好的分片數(shù)。

4、主從集群調整階段

到此，訂單中心的ES集群已經(jīng)初具規(guī)模，但由于訂單中心業(yè)務時效性要求高，對ES查詢穩(wěn)定性要求也高，如果集群中有節(jié)點發(fā)生異常，查詢服務會受到影響，從而影響到整個訂單生產流程。很明顯這種異常情況是致命的，所以為了應對這種情況，我們初步設想是增加一個備用集群，當主集群發(fā)生異常時，可以實時的將查詢流量降級到備用集群。

那備用集群應該怎么來搭？主備之間數(shù)據(jù)如何同步？備用集群應該存儲什么樣的數(shù)據(jù)？

考慮到ES集群暫時沒有很好的主備方案，同時為了更好地控制ES數(shù)據(jù)寫入，我們采用業(yè)務雙寫的方式來搭設主備集群。每次業(yè)務操作需要寫入ES數(shù)據(jù)時，同步寫入主集群數(shù)據(jù)，然后異步寫入備集群數(shù)據(jù)。同時由于大部分ES查詢的流量都來源于近幾天的訂單，且訂單中心數(shù)據(jù)庫數(shù)據(jù)已有一套歸檔機制，將指定天數(shù)之前已經(jīng)關閉的訂單轉移到歷史訂單庫。

所以歸檔機制中增加刪除備集群文檔的邏輯，讓新搭建的備集群存儲的訂單數(shù)據(jù)與訂單中心線上數(shù)據(jù)庫中的數(shù)據(jù)量保持一致。同時使用ZK在查詢服務中做了流量控制開關，保證查詢流量能夠實時降級到備集群。在此，訂單中心主從集群完成，ES查詢服務穩(wěn)定性大大提升。

5、現(xiàn)今：實時互備雙集群階段

期間由于主集群ES版本是較低的1.7，而現(xiàn)今ES穩(wěn)定版本都已經(jīng)迭代到6.x，新版本的ES不僅性能方面優(yōu)化很大，更提供了一些新的好用的功能，所以我們對主集群進行了一次版本升級，直接從原來的1.7升級到6.x版本。

集群升級的過程繁瑣而漫長，不但需要保證線上業(yè)務無任何影響，平滑無感知升級，同時由于ES集群暫不支持從1.7到6.x跨越多個版本的數(shù)據(jù)遷移，所以需要通過重建索引的方式來升級主集群，具體升級過程就不在此贅述了。

主集群升級的時候必不可免地會發(fā)生不可用的情況，但對于訂單中心ES查詢服務，這種情況是不允許的。所以在升級的階段中，備集群暫時頂上充當主集群，來支撐所有的線上ES查詢，保證升級過程不影響正常線上服務。同時針對于線上業(yè)務，我們對兩個集群做了重新的規(guī)劃定義，承擔的線上查詢流量也做了重新的劃分。

備集群存儲的是線上近幾天的熱點數(shù)據(jù)，數(shù)據(jù)規(guī)模遠小于主集群，大約是主集群文檔數(shù)的十分之一。集群數(shù)據(jù)量小，在相同的集群部署規(guī)模下，備集群的性能要優(yōu)于主集群。

然而在線上真實場景中，線上大部分查詢流量也來源于熱點數(shù)據(jù)，所以用備集群來承載這些熱點數(shù)據(jù)的查詢，而備集群也慢慢演變成一個熱數(shù)據(jù)集群。之前的主集群存儲的是全量數(shù)據(jù)，用該集群來支撐剩余較小部分的查詢流量，這部分查詢主要是需要搜索全量訂單的特殊場景查詢以及訂單中心系統(tǒng)內部查詢等，而主集群也慢慢演變成一個冷數(shù)據(jù)集群。

同時備集群增加一鍵降級到主集群的功能，兩個集群地位同等重要，但都可以各自降級到另一個集群。雙寫策略也優(yōu)化為：假設有AB集群，正常同步方式寫主（A集群）異步方式寫備（B集群）。A集群發(fā)生異常時，同步寫B(tài)集群（主），異步寫A集群（備）。

ES 訂單數(shù)據(jù)的同步方案

MySQL數(shù)據(jù)同步到ES中，大致總結可以分為兩種方案：

• 方案1：監(jiān)聽MySQL的Binlog，分析Binlog將數(shù)據(jù)同步到ES集群中。
• 方案2：直接通過ES API將數(shù)據(jù)寫入到ES集群中。

考慮到訂單系統(tǒng)ES服務的業(yè)務特殊性，對于訂單數(shù)據(jù)的實時性較高，顯然監(jiān)聽Binlog的方式相當于異步同步，有可能會產生較大的延時性。且方案1實質上跟方案2類似，但又引入了新的系統(tǒng)，維護成本也增高。所以訂單中心ES采用了直接通過ES API寫入訂單數(shù)據(jù)的方式，該方式簡潔靈活，能夠很好的滿足訂單中心數(shù)據(jù)同步到ES的需求。

由于ES訂單數(shù)據(jù)的同步采用的是在業(yè)務中寫入的方式，當新建或更新文檔發(fā)生異常時，如果重試勢必會影響業(yè)務正常操作的響應時間。

所以每次業(yè)務操作只更新一次ES，如果發(fā)生錯誤或者異常，在數(shù)據(jù)庫中插入一條補救任務，有Worker任務會實時地掃這些數(shù)據(jù)，以數(shù)據(jù)庫訂單數(shù)據(jù)為基準來再次更新ES數(shù)據(jù)。通過此種補償機制，來保證ES數(shù)據(jù)與數(shù)據(jù)庫訂單數(shù)據(jù)的最終一致性。

遇到的一些坑

1、實時性要求高的查詢走DB

推薦閱讀：ES 幾十億數(shù)據(jù)檢索 3 秒返回。

對于ES寫入機制的有了解的同學可能會知道，新增的文檔會被收集到Indexing Buffer，然后寫入到文件系統(tǒng)緩存中，到了文件系統(tǒng)緩存中就可以像其他的文件一樣被索引到。

然而默認情況文檔從Indexing Buffer到文件系統(tǒng)緩存（即Refresh操作）是每秒分片自動刷新，所以這就是我們說ES是近實時搜索而非實時的原因：文檔的變化并不是立即對搜索可見，但會在一秒之內變?yōu)榭梢姟?/p>

當前訂單系統(tǒng)ES采用的是默認Refresh配置，故對于那些訂單數(shù)據(jù)實時性比較高的業(yè)務，直接走數(shù)據(jù)庫查詢，保證數(shù)據(jù)的準確性。

2、避免深分頁查詢

ES集群的分頁查詢支持from和size參數(shù)，查詢的時候，每個分片必須構造一個長度為from+size的優(yōu)先隊列，然后回傳到網(wǎng)關節(jié)點，網(wǎng)關節(jié)點再對這些優(yōu)先隊列進行排序找到正確的size個文檔。

假設在一個有6個主分片的索引中，from為10000，size為10，每個分片必須產生10010個結果，在網(wǎng)關節(jié)點中匯聚合并60060個結果，最終找到符合要求的10個文檔。

由此可見，當from足夠大的時候，就算不發(fā)生OOM，也會影響到CPU和帶寬等，從而影響到整個集群的性能。所以應該避免深分頁查詢，盡量不去使用。

3、FieldData與Doc Values

FieldData：

線上查詢出現(xiàn)偶爾超時的情況，通過調試查詢語句，定位到是跟排序有關系。排序在es1.x版本使用的是FieldData結構，FieldData占用的是JVM Heap內存，JVM內存是有限，對于FieldData Cache會設定一個閾值。

如果空間不足時，使用最久未使用（LRU）算法移除FieldData，同時加載新的FieldData Cache，加載的過程需要消耗系統(tǒng)資源，且耗時很大。所以導致這個查詢的響應時間暴漲，甚至影響整個集群的性能。針對這種問題，解決方式是采用Doc Values。

Doc Values：

Doc Values是一種列式的數(shù)據(jù)存儲結構，跟FieldData很類似，但其存儲位置是在Lucene文件中，即不會占用JVM Heap。隨著ES版本的迭代，Doc Values比FieldData更加穩(wěn)定，Doc Values在2.x起為默認設置。

最后

給大家送上一份福利，領取方式：戳這里免費下載

Java架構進階面試及知識點文檔筆記

這份文檔共498頁，其中包括Java集合，并發(fā)編程，JVM，Dubbo,Redis，Spring全家桶，MySQL，Kafka等面試解析及知識點整理

Java分布式高級面試問題解析文檔

其中都是包括分布式的面試問題解析，內容有分布式消息隊列，Redis緩存，分庫分表，微服務架構，分布式高可用，讀寫分離等等！

互聯(lián)網(wǎng)Java程序員面試必備問題解析及文檔學習筆記

Java架構進階視頻解析合集

[外鏈圖片轉存中…(img-le8kcp1M-1626256905464)]

互聯(lián)網(wǎng)Java程序員面試必備問題解析及文檔學習筆記

[外鏈圖片轉存中…(img-woJ1dwmN-1626256905464)]

Java架構進階視頻解析合集

總結

以上是生活随笔為你收集整理的一招彻底帮你搞定HashMap源码，项目实战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。