有贊訂單管理主要承接有贊所有訂單搜尋及詳情展示功能，系統随着業務的不斷發展經曆了多次飛升之路。下面簡單介紹下有贊訂單管理系統的三生三世與“十面埋伏”。
第一世：凡人飛升小仙之路-分庫分表
随着業務發展，單庫單表所能承載的資料量局限性越發嚴重。
曆劫：單庫單表資料量承載局限
渡劫：分庫分表
分庫分表的次元針對系統買賣家查詢的需求，分片鍵為買家 id 和店鋪 id，其餘訂單擴充資訊表屬于資料組裝資訊，均以店鋪 id 為分片鍵。
結果：分庫分表後，資料業務量的承載質的提升。
第二世：小仙飛升上仙之路-引入ES搜尋引擎
随着業務搜尋次元的不斷添加，使得跨表查詢需求越來越多，系統的慢查不斷報出，為此引入了 ES 搜尋引擎。
曆劫：跨表查詢越來越多，系統慢查頻頻報出
渡劫：引入 ES 搜尋引擎
ElasticSearch 是一個基于 Lucene 的搜尋伺服器,這裡主要是通過将訂單主表及輔表的索引字段同步到ES裡，這些每張表單獨的索引字段，彙總成一個聯合索引，來實作多個表的跨表搜尋。
結果：目前運作良好，統計的檢索需求響應時間均值 20ms 以内，對于命中緩存的在 1ms 以内傳回。由于多表聯查的流量都進了 ES,是以系統慢查被清0。
兩個問題需要注意下：
1. 單 Type 與多 Type 的選擇(ES6.X以上版本一個索引隻允許有一個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://tech.youzan.com/trade_manage/