京東到家訂單中心 Elasticsearch 演進歷程
背景
京東到家訂單中心系統業務中，無論是外部商家的訂單生產，或是內部上下游系統的依賴，訂單查詢的調用量都非常大，造成了訂單數據讀多寫少的情況。京東到家的訂單數據存儲在Mysql中，但顯然只通過DB來支撐大量的查詢是不可取的，同時對于一些復雜的查詢，Mysql支持得不夠友好，所以訂單中心系統使用了Elasticsearch來承載訂單查詢的主要壓力。
Elasticsearch 做為一款功能強大的分布式搜索引擎，支持近實時的存儲、搜索數據，在京東到家訂單系統中發揮著巨大作用，目前訂單中心ES集群存儲數據量達到10億個文檔，日均查詢量達到5億。隨著京東到家近幾年業務的快速發展，訂單中心ES架設方案也不斷演進，發展至今ES集群架設是一套實時互備方案，很好的保障了ES集群讀寫的穩定性，下面就給大家介紹一下這個歷程以及遇到的一些坑。
ES集群架設演進歷程
1. 初始階段
訂單中心ES初始階段好如一張白紙，架設方案基本沒有，很多配置都是保持集群默認配置。整個集群部署在集團的彈性云上，ES集群的節點以及機器部署都比較混亂。同時按照集群維度來看，一個ES集群會有單點問題，顯然對于訂單中心業務來說也是不被允許的。
2. 集群隔離階段
和很多業務一樣，ES集群采用的混布的方式。但由于訂單中心ES存儲的是線上訂單數據，偶爾會發生混布集群搶占系統大量資源，導致整個訂單中心ES服務異常的情況。
顯然任何影響到訂單查詢穩定性都是無法容忍的，所以針對于這個情況，先是對訂單中心ES所在的彈性云，遷出那些系統資源搶占很高的集群節點，ES集群狀況稍有好轉。但隨著集群數據不斷增加，彈性云配置已經不太能滿足ES集群，且為了完全的物理隔離，最終干脆將訂單中心ES集群部署到高配置的物理機上，ES集群性能又得到提升。
3. 節點副本調優階段
ES的性能跟硬件資源有很大關系，當ES集群單獨部署到物理機器上時，集群內部的節點并不是獨占整臺物理機資源，在集群運行的時候同一物理機上的節點仍會出現資源搶占的問題。所以在這種情況下，為了讓ES單個節點能夠使用最大程度的機器資源，采用每個ES節點部署在單獨一臺物理機上方式。
但緊接著，問題又來了，如果單個節點出現瓶頸了呢?我們應該怎么再優化呢?ES查詢的原理，當請求打到某號分片的時候，如果沒有指定分片類型(preference參數)查詢，請求會負載到對應分片號的各個節點上。而集群默認副本配置是一主一副，針對于此，我們想到了擴容副本的方式，由默認的一主一副變為一主二副，同時增加相應物理機。
如上圖，訂單中心ES集群架設示意圖。整個架設方式通過VIP來負載均衡外部請求，第一層gateway節點實質為ES中client node，相當于一個智能負載均衡器，充當著分發請求的角色。第二層為data node，負責存儲數據以及執行數據的相關操作。整個集群有一套主分片，二套副分片(一主二副)，從網關節點轉發過來的請求，會在打到數據節點之前通過輪詢的方式進行均衡。集群增加一套副本并擴容機器的方式，增加了集群吞吐量，從而提升了整個集群查詢性能。下圖為訂單中心ES集群各階段性能示意圖，直觀的展示了各階段優化后ES集群性能的顯著提升。
當然分片數量和分片副本數量并不是越多越好，在此階段中，對選擇適當的分片數量做了近一步探索。分片數可以理解為Mysql中的分庫分表，而當前訂單中心ES查詢主要分為兩類：單ID查詢以及分頁查詢。分片數越大，集群橫向擴容規模也更大，根據分片路由的單ID查詢吞吐量也能大大提升，但對于聚合的分頁查詢性能則將降低。分片數越小，集群橫向擴容規模更小，單ID的查詢性能也將下降，但對于分頁查詢，性能將會得到提升。所以如何均衡分片數量和現有查詢業務，我們做了很多次調整壓測，最終選擇了集群性能較好的分片數。
4. 主從集群調整階段
到此，訂單中心的ES集群已經初具規模，但由于訂單中心業務時效性要求高，對于ES查詢穩定性要求也高，如果集群中有節點發生異常，查詢服務會受到影響，從而影響到整個訂單生產流程。顯而易見這種異常情況是致命，所以為了應對這種情況，我們初步設想是增加一個備用集群，當主集群發生異常時，可以實時的將查詢流量降級到備用集群。
那備用集群應該怎么來搭?主備之間數據如何同步?備用集群應該存儲什么樣的數據?考慮到ES集群暫時沒有很好的主備方案，同時為了更好的控制ES數據寫入，我們采用業務雙寫的方式來搭設主備集群。每次業務操作需要寫入ES數據時，同步的寫入主集群數據，然后異步的寫入備集群數據。同時由于大部分ES查詢的流量都來源于近幾天的訂單，且訂單中心數據庫數據已有一套歸檔機制，將指定天數之前已經關閉的訂單轉移到歷史訂單庫。
所以歸檔機制中增加刪除備集群文檔的邏輯，讓新搭建的備集群存儲的訂單數據與訂單中心線上數據庫中的數據量保持一致。同時使用ZK在查詢服務中做了流量控制開關，保證查詢流量能夠實時的降級到備集群。在此，訂單中心主從集群完成，ES查詢服務穩定性大大提升。
5. 現今：實時互備雙集群階段
期間由于主集群ES版本是較低的1.7，而現今ES穩定版本都以及迭代到6.x，新版本的ES不僅性能方面優化很大，更提供了一些新的好用的功能，所以我們對主集群進行了一次版本升級，直接從原來的1.7升級到6.x版本。集群升級的過程繁瑣而漫長，不但需要保證線上業務無任何影響，平滑無感知升級，同時由于ES集群暫不支持從1.7到6.x跨越多個版本的數據遷移，所以需要通過重建索引的方式來升級主集群，具體升級過程就不在此贅述了。
主集群升級的時候必不可免的會發生不可用的情況，但對于訂單中心ES查詢服務，這種情況是不允許的。所以在升級的階段中，備集群暫時頂上充當主集群，來支撐所有的線上ES查詢，保證升級過程不影響正常線上服務。同時針對于線上業務，我們對兩個集群做了重新的規劃定義，承擔的線上查詢流量也做了重新的劃分。
備集群存儲的是線上近幾天的熱點數據，數據規模遠小于主集群，大約是主集群文檔數的十分之一左右。集群數據量小，在相同的集群部署規模下，備集群的性能要優于主集群。然而在線上真實場景中，線上大部分查詢流量也來源于熱點數據，所以用備集群來承載這些熱點數據的查詢，而備集群也慢慢演變成一個熱數據集群。之前的主集群存儲的是全量數據，用該集群來支撐剩余較小部分的查詢流量，這部分查詢主要是需要搜索全量訂單的特殊場景查詢以及訂單中心系統內部查詢等，而主集群也慢慢演變成一個冷數據集群。
同時備集群增加一鍵降級到主集群的功能，兩個集群地位同等重要，但都可以各自降級到另一個集群。雙寫策略也優化為：假設有A B集群，正常同步方式寫主(A集群)異步方式寫備(B集群)。A集群發生異常時，同步寫B集群(主)，異步寫A集群(備)。
ES訂單數據的同步方案
Mysql數據同步到ES中，大致總結可以分為兩種方案：
(1) 方案1：監聽mysql的binlog，分析binlog將數據同步到ES集群中
優點：業務與ES數據耦合度低，業務邏輯中不需要關心ES數據的寫入。
缺點：binglog模式只能使用ROW模式，且引入了新的同步服務，增加了開發量以及維護成本，也增大了ES同步的風險。
(2) 方案2：直接通過ES API將數據寫入到ES集群中
優點：簡潔明了，能夠靈活的控制數據的寫入
缺點：與業務耦合嚴重，強依賴于業務系統的寫入方式
考慮到訂單系統ES服務的業務特殊性，對于訂單數據的實時性較高，顯然監聽binlog的方式相當于異步同步，有可能會產生較大的延時性。且方案1實質上跟方案2類似，但又引入了新的系統，維護成本也增高。所以訂單中心ES采用了直接通過ES API寫入訂單數據的方式，該方式簡潔靈活，能夠很好的滿足訂單中心數據同步到ES的需求。
由于ES訂單數據的同步采用的是在業務中寫入的方式，當新建或更新文檔發生異常時，如果重試勢必會影響業務正常操作的響應時間。所以每次業務操作只更新一次ES，如果發生錯誤或者異常，在數據庫中插入一條補救任務，有worker任務會實時的掃這些數據，以數據庫訂單數據為基準來再次更新ES數據。通過此種補償機制，來保證ES數據與數據庫訂單數據的最終一致性。
遇到的一些坑
1. 實時性要求高的查詢走db
對于ES寫入機制的有了解的可能會知道，新增的文檔會被收集到indexing buffer，然后寫入到文件系統緩存中，到了文件系統緩存中就可以像其他的文件一樣被索引到。然而默認情況文檔從index buffer到文件系統緩存(即refresh操作)是每秒分片自動刷新，所以這就是我們說ES是近實時搜索而非實時的原因：文檔的變化并不是立即對搜索可見，但會在一秒之內變為可見。當前訂單系統ES采用的是默認refresh配置，故對于那些訂單數據實時性比較高的業務，直接走數據庫查詢，保證數據的準確性。
2. 避免深分頁查詢
ES集群的分頁查詢支持from和size參數，查詢的時候每個分片必須構造一個長度為from+size的優先隊列，然后回傳到網關節點，網關節點再對這些優先隊列進行排序找到正確的size個文檔。假設在一個有6個主分片的索引中，from為10000，size為10，每個分片必須產生10010個結果，在網關節點中匯聚合并60060個結果，最終找到符合要求的10個文檔。由此可見，當from足夠大的時候，就算不發生OOM，也會影響到CPU和帶寬等，從而影響到整個集群的性能。所以應該避免深分頁查詢，盡量不去使用。
3. FieldData與Doc Values
Fielddata：線上查詢出現偶爾超時的情況，通過調試查詢語句，定位到是跟排序有關系。排序在es 1.x版本使用的是fielddata 結構，fielddata占用的是jvm heap內存，jvm內存是有限，對于fielddata cache會設定一個閾值。如果空間不足時，使用最久未使用(LRU)算法移除fielddata，同時加載新的fielddata cache，加載的過程需要消耗系統資源，且耗時很大。所以導致這個查詢的響應時間暴漲，甚至影響整個集群的性能。針對于這種問題，解決的方式是采用doc values。
Doc Values：Doc Values是一種列式的數據存儲結構，跟fieldata很類似，但其存儲位置是在Lucene文件中，即不會占用JVM heap。隨著ES版本的迭代，doc values比fielddata更加穩定，doc values在2.x起為默認設置。
總結
架構的快速迭代源于業務的快速發展，正是由于近幾年到家業務的高速發展，訂單中心的架構也不斷優化升級。而架構方案沒有最好的，只有最合適的，相信再過幾年，訂單中心的架構又將是另一個面貌，但吞吐量更大，性能更好，穩定性更強，將是訂單中心系統永遠的追求。
【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】
