揭秘 | 成立17年的淘寶，萬億級海量交易訂單都儲存在哪？

在一個這樣大體量的資料集上，需要能夠滿足使用者隨時查詢的低延時需求，同時需要達到極低的儲存成本，在技術上是一個非常大的挑戰。

淘寶從2003年成立至今近17年的時間，隨著流量不斷上漲，交易訂單資料庫的架構也經歷過數次演進。

第一階段，開始由於流量較小，使用了一套Oracle資料儲存了所有的訂單資訊，新訂單建立和歷史訂單查詢都在同一套資料庫進行。

第二階段，由於歷史訂單量資料量越來越大，單一一套庫已經不能滿足同時滿足效能和容量的問題，於是對交易訂單庫進行了拆分，單獨建立了一個Oracle歷史庫，將三個月以前的訂單遷移進歷史庫，同時由於資料量巨大，查詢效能不能滿足需求，因此當時的歷史訂單不提供查詢功能。使用者只能查詢三個月之內的訂單資訊。

第三個階段，為了解決擴充套件性和儲存成本問題，交易歷史庫整體遷移到了HBase方案，這套方案在當時很好了解決了儲存成本和業務查詢需求這2個訴求。整體方案是使用主表結合索引表，查詢訂單詳細資訊透過主表完成，透過買家或者賣家ID查詢訂單，則需要藉助索引表先得到訂單號。

• 儲存成本，每日寫入量巨大且資料永不刪除，必須要保證極低的成本。

• 節省儲存成本的前提下，保證豐富的查詢特性，例如按時間維度排序等。因此底層資料庫需要支援二級索引，且二級索引需要保證一致性和效能。

• 保證較低的查詢延時，不影響使用者使用體驗。雖然90天前的歷史訂單的查詢量比90天內要少很多，但這依然是直接面對使用者的，需要保證長尾延時在一定限度內。

• 線上庫依然沿用之前的MySQL InnoDB叢集，但是隻儲存90天的資料量，90天之前的訂單會被刪除，資料量少，可以保證較高的快取命中率，確保讀寫延時。

• 透過資料同步將線上庫中超過90天的訂單遷移到歷史庫中，遷移之後該部分訂單從線上庫刪除。

• 歷史庫切換為X-Engine，儲存全量的交易訂單資料，90之前的訂單讀寫，直接操作歷史庫, 同時歷史庫承接線上庫的所有遷移寫入負載。

這套架構上線之後，交易歷史庫的儲存成本相比較於使用HBase沒有上升，同時由於歷史庫和線上庫能力相同，可以建立完全一樣的索引，歷史訂單恢復了對訂單按時間排序功能的支援，同時其讀取延時也得到了保證。

在淘寶交易歷史庫的方案中，考慮到業務層面歷史程式碼架構的延續性，採用了InnoDB引擎線上庫和X-Engine歷史庫分離的方案。在這套架構中，X-Engine歷史庫其實同時承擔了線上庫遷移過來的寫入以及90天以前記錄的讀寫流量。 

實際上，考慮到淘寶交易訂單記錄流水型的訪問特徵(最近寫入的記錄會被大量訪問，隨著時間推移，記錄訪問頻次急劇衰減），X-Engine引擎內部的冷熱分離機制就能很好的處理這種流水型業務，所以單一X-Engine資料庫叢集完全解決需求。

對於新開業務或者有大量流水型記錄儲存需求的現有業務且業務層面還未做冷熱分離，我們建議直接使用一套X-Engine引擎，在儲存成本降低的同時，DB層的訪問程式碼會更簡單。基於X-Engine引擎的PolarDB-X分散式資料庫可以同時解決scale out問題和成本問題。

目前X-Engine引擎已經上線阿里雲， 經過阿里內部業務驗證，歡迎有成本和效能需求的使用者購買使用。