阿裡巴巴旗下的淘寶和天貓作為國内最大在線購物平台，提供售賣的商品數目數以億計，其活躍用戶數量超過了7億人，服務的商家的數量也在數千萬量級。面對性能和成本的雙重壓力，阿裡數據庫内核團隊如何應對？

作者 | 王劍英（北樓） / 和利

天貓和淘寶每天發生的實物和虛拟商品的交易達到億級别。考慮到一次成功交易的整個鍊路，會涉及到會員信息驗證，商品庫信息查詢，訂單創建，庫存扣減，優惠扣減，訂單支付，物流信息更新，确認支付等。

鍊路中的每一環都涉及到數據庫中記錄的創建和狀态的更新，一次成功的交易可能對應到後台信息系統上數百次數據庫事務操作，支撐交易系統的整個數據庫集群則會承擔每日高達數百億的事務讀寫。這除了給數據庫系統帶來巨大的性能挑戰之外，每日遞增的海量數據也帶來巨大的存儲成本壓力。

交易訂單作為其中最為關鍵的信息，由于可能涉及交易糾紛處理，需要随時提供用戶查詢，必須永久的記錄在數據庫中。淘寶成立至今近17年，所有與訂單相關的數據庫記錄總量達到了萬億級别，其所占用的磁盤空間也早已超過PB級。

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

用戶的曆史訂單記錄數據量巨大且不能丢失

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

第一階段，開始由于流量較小，使用了一套Oracle數據存儲了所有的訂單信息，新訂單創建和曆史訂單查詢都在同一套數據庫進行。

第二階段，由于曆史訂單量數據量越來越大，單一一套庫已經不能滿足同時滿足性能和容量的問題，于是對交易訂單庫進行了拆分，單獨建立了一個Oracle曆史庫，将三個月以前的訂單遷移進曆史庫，同時由于數據量巨大，查詢性能不能滿足需求，因此當時的曆史訂單不提供查詢功能。用戶隻能查詢三個月之内的訂單信息。

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

但這個方案遺留一個問題：訂單并不是嚴格按照90天進行遷移的，有很多類型的訂單并不遷移到曆史庫，導緻已買到--訂單列表的排序是亂序的，已買到的訂單列表不是嚴格按照時間由近到遠排序的，用戶如果按照訂單列表一頁一頁往下翻，會發現自己最近的訂單”突然丢了”(實際上沒有丢的，隻是亂序了，再往後翻就有了)。

第四個階段，曆史庫采用基于X-Engine引擎的PolarDB-X集群，在滿足存儲成本的同時，提供與在線庫一樣的索引能力，解決亂序問題。

回顧淘寶交易庫的演進曆史，自拆分出獨立的交易曆史庫之後，在持續十年時間裡，業務團隊和數據庫團隊一直在應對幾個核心的挑戰：

• 存儲成本，每日寫入量巨大且數據永不删除，必須要保證極低的成本。
• 節省存儲成本的前提下，保證豐富的查詢特性，例如按時間維度排序等。因此底層數據庫需要支持二級索引，且二級索引需要保證一緻性和性能。
• 保證較低的查詢延時，不影響用戶使用體驗。雖然90天前的曆史訂單的查詢量比90天内要少很多，但這依然是直接面對用戶的，需要保證長尾延時在一定限度内。

在2018年，因為數據庫存儲的原因導緻的訂單排序錯亂的問題，受到越來越多的投訴，給用戶帶來非常大的困擾，業務上決定根治這個問題。從前面的分析總結看，理想中的交易曆史庫方案需要同時滿足三個條件: 低成本，低延時，特性豐富。使用和在線庫一樣的InnoDB引擎則滿足不了存儲成本的要求，而使用HBase則滿足不了一緻性二級索引等要求。

2018年，阿裡自研的X-Engine引擎逐步在集團内部落地，其針對阿裡巴巴交易業務的流水性特征設計了原生的冷熱分離的架構，X-Engine引擎中的冷數據記錄在數據頁中緊湊排列并默認對所有數據塊進行壓縮，這套架構兼顧了性能和成本，很快在内部非常多的業務中落地，例如：X-Engine如何支撐釘釘數據量激增。

在考察交易曆史庫的方案時，一個思路是合并在線庫和曆史庫，依賴X-Engine自身的冷熱分離能力, 實現對90天内交易訂單的高性能訪問和90天以前交易訂單記錄的低成本存儲。同時一套統一的交易訂單庫，可以提供諸如二級索引等功能，用戶訂單不能按時間排序的問題也随之解決，業務層的代碼将非常簡單。

但交易訂單系統在在線庫/曆史庫分離的架構下疊代了十年的時間，很多業務系統的代碼對這套分離架構做了兼容，考慮到對業務代碼改造以及遷移的風險，我們在初期繼承了之前在線和曆史分離的架構。隻是将原有的HBase集群替換成了PolarDB-X集群(基于X-Engine引擎的版本)：

• 在線庫依然沿用之前的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問題和成本問題。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!