京東到家訂單中心系統業(yè)務(wù)中，無(wú)論是外部商家的訂單生產(chǎn)，或是內部上下游系統的依賴(lài)，訂單查詢(xún)的調用量都非常大，造成了訂單數據讀多寫(xiě)少的情況。

我們把訂單數據存儲在MySQL中，但顯然只通過(guò)DB來(lái)支撐大量的查詢(xún)是不可取的。同時(shí)對于一些復雜的查詢(xún)，MySQL支持得不夠友好，所以訂單中心系統使用了Elasticsearch來(lái)承載訂單查詢(xún)的主要壓力。

Elasticsearch作為一款功能強大的分布式搜索引擎，支持近實(shí)時(shí)的存儲、搜索數據，在京東到家訂單系統中發(fā)揮著(zhù)巨大作用，目前訂單中心ES集群存儲數據量達到10億個(gè)文檔，日均查詢(xún)量達到5億。

隨著(zhù)京東到家近幾年業(yè)務(wù)的快速發(fā)展，訂單中心ES架設方案也不斷演進(jìn)，發(fā)展至今ES集群架設是一套實(shí)時(shí)互備方案，很好地保障了ES集群讀寫(xiě)的穩定性，下面就給大家介紹一下這個(gè)歷程以及過(guò)程中遇到的一些坑。

ES 集群架構演進(jìn)之路

1、初始階段

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

2、集群隔離階段

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

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

3、節點(diǎn)副本調優(yōu)階段

ES的性能跟硬件資源有很大關(guān)系，當ES集群?jiǎn)为毑渴鸬轿锢頇C器上時(shí)，集群內部的節點(diǎn)并不是獨占整臺物理機資源，在集群運行的時(shí)候同一物理機上的節點(diǎn)仍會(huì )出現資源搶占的問(wèn)題。所以在這種情況下，為了讓ES單個(gè)節點(diǎn)能夠使用最大程度的機器資源，采用每個(gè)ES節點(diǎn)部署在單獨一臺物理機上方式。

但緊接著(zhù)，問(wèn)題又來(lái)了，如果單個(gè)節點(diǎn)出現瓶頸了呢？我們應該怎么再優(yōu)化呢？

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

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

如圖，整個(gè)架設方式通過(guò)VIP來(lái)負載均衡外部請求：

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

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

當然分片數量和分片副本數量并不是越多越好，在此階段，我們對選擇適當的分片數量做了進(jìn)一步探索。分片數可以理解為MySQL中的分庫分表，而當前訂單中心ES查詢(xún)主要分為兩類(lèi)：?jiǎn)蜪D查詢(xún)以及分頁(yè)查詢(xún)。

分片數越大，集群橫向擴容規模也更大，根據分片路由的單ID查詢(xún)吞吐量也能大大提升，但聚合的分頁(yè)查詢(xún)性能則將降低；分片數越小，集群橫向擴容規模也更小，單ID的查詢(xún)性能也會(huì )下降，但分頁(yè)查詢(xún)的性能將會(huì )提升。

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

4、主從集群調整階段

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

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

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

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

5、現今：實(shí)時(shí)互備雙集群階段

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

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

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

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

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

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

ES 訂單數據的同步方案

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

方案1：監聽(tīng)MySQL的Binlog，分析Binlog將數據同步到ES集群中。

方案2：直接通過(guò)ES API將數據寫(xiě)入到ES集群中。

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

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

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

遇到的一些坑

1、實(shí)時(shí)性要求高的查詢(xún)走DB

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

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

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

2、避免深分頁(yè)查詢(xún)

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

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

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

3、FieldData與Doc Values

FieldData

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

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

Doc Values

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

總結

架構的快速迭代源于業(yè)務(wù)的快速發(fā)展，正是由于近幾年到家業(yè)務(wù)的高速發(fā)展，訂單中心的架構也不斷優(yōu)化升級。而架構方案沒(méi)有最好的，只有最合適的，相信再過(guò)幾年，訂單中心的架構又將是另一個(gè)面貌，但吞吐量更大，性能更好，穩定性更強，將是訂單中心系統永遠的追求。