https://tech.youzan.com/trade_manage/

有贊訂單管理主要承接有贊所有訂單搜索及詳情展示功能，系統隨著業務的不斷發展經歷了多次飛升之路。下面簡單介紹下有贊訂單管理系統的三生三世與“十面埋伏”。

第一世：凡人飛升小仙之路-分庫分表

隨著業務發展，單庫單表所能承載的數據量局限性越發嚴重。?
歷劫：單庫單表數據量承載局限?
渡劫：分庫分表?
分庫分表的維度針對系統買賣家查詢的需求，分片鍵為買家id和店鋪id，其余訂單擴展信息表屬于數據組裝信息，均以店鋪id為分片鍵。?
結果：分庫分表后，數據業務量的承載質的提升。

第二世：小仙飛升上仙之路-引入ES搜索引擎

隨著業務搜索維度的不斷添加，使得跨表查詢需求越來越多，系統的慢查不斷報出，為此引入了ES搜索引擎。?
歷劫：跨表查詢越來越多，系統慢查頻頻報出渡劫：引入ES搜索引擎?
ElasticSearch是一個基于Lucene的搜索服務器,這里主要是通過將訂單主表及輔表的索引字段同步到ES里，這些每張表單獨的索引字段，匯總成一個聯合索引，來實現多個表的跨表搜索。?
結果：目前運行良好，統計的檢索需求響應時間均值20ms以內，對于命中緩存的在1ms以內返回。由于多表聯查的流量都進了ES,所以系統慢查被清0。

兩個問題需要注意下：?
1.?單Type與多Type的選擇?
ES里使用文檔存儲，一個Index可以理解為一個庫，一個Type可以理解為一張表，那么訂單及其擴展信息面臨使用單Type還是多Type的抉擇。?
多Type優點： 可以做到索引字段與表結構一一對應, 數據同步隔離單一，直觀簡單。?
多Type缺點：獲取數據時候需要一次數據聚合，比如一次跨5張表索引聯查，需要先分別取出5張表的數據，然后做一次交集。性能會有影響。類似于DB的跨表聯查，而且當數據做冷熱隔離，數據拆分時候，多Type的拆分和維護成本反而更高。?
單Type優點：可以做到數據一次請求即可將目標信息全量返回，一個Type的數據拆分冷熱隔離維護成本可控。?
單Type缺點：數據同步成本高一些，要做好數據聚合一致性問題。 結合業務需求場景，這里采用的單Type方案。如下圖所示。

2.索引字段數量控制?
由于訂單及其擴展信息字段較多，將這些信息全量同步到ES會導致索引字段過多，索引文件也會隨之過大，檢索效率會受到影響。所以這里采用了將訂單及其擴展信息中強搜索需求的索引字段同步了進來，并沒有做全量所有字段同步。

第三世：上仙飛升上神之路-引入Hbase

隨著業務的不斷發展，對系統性能的要求的不斷提高，我們發現雖然數據檢索的效率很高，但是數據組裝的效率令人擔憂，由于需要從ES中獲取的訂單號列表到各個擴展表去獲取具體信息，也就是一次完整的訂單列表拉取時間=數據檢索時間+數據組裝時間，而數據組裝就算是批量獲取，也要去取N（假如有N張訂單擴展表）次，即使并行去取也不夠高效，上文討論過沒有將訂單的所有信息全部同步到ES的原因，這樣一次完整的訂單拉取時間=數據檢索時間。?
歷劫：數據組裝效率低下渡劫：引入Hbase來為詳情數據組裝 Hbase是一個高可靠性、高性能、面向列、可伸縮的分布式存儲系統。可以通過MapReduce來處理HBase中的海量數據。?
這里將訂單基本信息及其強依賴的擴展信息全量導入Hbase，其中歷史數據采用BulkLoad導入，增量數據采用消息同步寫入，以訂單號為rowKey為訂單號，這樣通過一次請求，將該訂單的基本信息及擴展信息一次性取出。結果：訂單管理架構被抽象成了DB+ES+HBASE的三層架構(如下圖所示)，DB作為數據寫入源頭，ES負責搜索請求的parser解析及基本數據返回（即Es返回字段即可滿足需求的場景），而Hbase作為訂單詳情詳細信息的組裝載體，兩者配合提升整個訂單列表搜索和詳情組裝的性能。同時Hbase的數據源也可以被復用到訂單導出，數據統計等離線需求上。

寫到這里可能很多朋友都看出，實現這一切還有一個非常重要的劫需要去渡。那就是數據同步的實時性和一致性。感興趣的話后續文章可以重點寫寫數據同步以及踩過的坑和破局之道，這里簡單拋磚引玉下。

歷劫：數據同步的實時性與一致性?
渡劫：鏈路白盒+冪等性保障?
1. 鏈路白盒：整個同步鏈路是先監聽binlog然后同步到消息隊列中，業務消費處理同步到Es和Hbase，可以將整個同步鏈路監控起來，比如一個消息binlogTime->addMqTime->processTime->addEsOrHbaseTime,這個差值其實就是實時性的一個指標。一旦整個同步鏈路的白盒搭建好，那么對應的報警監控，失敗重試補償就都可以跟進配套完成。保證數據的完整性與實時性。同步鏈路及同步監控如下圖所示。?

2.冪等性保障：如果不能保證業務消費的冪等性，那么消息的亂序，數據的重放監控補償等等就會很被動。這里簡單提供幾種冪等思路：

• 業務樂觀鎖字段：比如訂單狀態的流轉，應該是一個正向更新，即后一次更新的state一定大于等于前一次。
• version字段：表設計時候留一個version字段，每次數據庫更新都會將該字段加1，作為樂觀鎖依據。
• sonwflake算法：可以根據業務需要定制自己的snowflake算法，比如毫秒級時間戳+binlog變更自增號
• 消息有序：對于一些強依賴消息有序或者業務樂觀鎖不好設定時候，消息端的有序變得尤為重要，可以給根據業務唯一鍵（如訂單號）進行機器取模，保證同一筆訂單的變更數據會被推送到同一臺機器上消費。 其中業務樂觀鎖使用簡單高效，無需額外存儲樂觀鎖字段，而消息強有序每次需要使用取模計算，性能多少會有些影響，不過經過壓測數據顯示性能差別不大，這邊采用業務樂觀鎖+消息有序共用的方案。目前線上運行良好。

簡單回顧了下有贊訂單管理的“飛升之路”，至于是不是上神，還有待進一步考驗，后面會重點發力在配置化編程，系統白盒監控最大化及系統性能的不斷提升上.

轉載于:https://www.cnblogs.com/davidwang456/articles/9239097.html

總結

以上是生活随笔為你收集整理的有赞订单管理的三生三世与“十面埋伏”的全部內容，希望文章能夠幫你解決所遇到的問題。

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