99热免费,女高潮大叫喷水流白浆,精品老肥婆88AV,美女后入视频,日韩h

01淘寶交易訂單系統(tǒng)介紹

天貓和淘寶每天發(fā)生的實(shí)物和虛擬商品的交易達(dá)到億級別。考慮到一次成功交易的整個鏈路，會涉及到會員信息驗(yàn)證，商品庫信息查詢，訂單創(chuàng)建，庫存扣減，優(yōu)惠扣減，訂單支付，物流信息更新，確認(rèn)支付等。

鏈路中的每一環(huán)都涉及到數(shù)據(jù)庫中記錄的創(chuàng)建和狀態(tài)的更新，一次成功的交易可能對應(yīng)到后臺信息系統(tǒng)上數(shù)百次數(shù)據(jù)庫事務(wù)操作，支撐交易系統(tǒng)的整個數(shù)據(jù)庫集群則會承擔(dān)每日高達(dá)數(shù)百億的事務(wù)讀寫。這除了給數(shù)據(jù)庫系統(tǒng)帶來巨大的性能挑戰(zhàn)之外，每日遞增的海量數(shù)據(jù)也帶來巨大的存儲成本壓力。

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

在一個這樣大體量的數(shù)據(jù)集上，需要能夠滿足用戶隨時查詢的低延時需求，同時需要達(dá)到極低的存儲成本，在技術(shù)上是一個非常大的挑戰(zhàn)。

用戶的歷史訂單記錄數(shù)據(jù)量巨大且不能丟失

02淘寶交易訂單庫的架構(gòu)演進(jìn)歷史

淘寶從2003年成立至今近17年的時間，隨著流量不斷上漲，交易訂單數(shù)據(jù)庫的架構(gòu)也經(jīng)歷過數(shù)次演進(jìn)。

第一階段，開始由于流量較小，使用了一套Oracle數(shù)據(jù)存儲了所有的訂單信息，新訂單創(chuàng)建和歷史訂單查詢都在同一套數(shù)據(jù)庫進(jìn)行。

第二階段，由于歷史訂單量數(shù)據(jù)量越來越大，單一一套庫已經(jīng)不能滿足同時滿足性能和容量的問題，于是對交易訂單庫進(jìn)行了拆分，單獨(dú)建立了一個Oracle歷史庫，將三個月以前的訂單遷移進(jìn)歷史庫，同時由于數(shù)據(jù)量巨大，查詢性能不能滿足需求，因此當(dāng)時的歷史訂單不提供查詢功能。用戶只能查詢?nèi)齻€月之內(nèi)的訂單信息。

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

但這個方案遺留一個問題：訂單并不是嚴(yán)格按照90天進(jìn)行遷移的，有很多類型的訂單并不遷移到歷史庫，導(dǎo)致已買到--訂單列表的排序是亂序的，已買到的訂單列表不是嚴(yán)格按照時間由近到遠(yuǎn)排序的，用戶如果按照訂單列表一頁一頁往下翻，會發(fā)現(xiàn)自己最近的訂單”突然丟了”(實(shí)際上沒有丟的，只是亂序了，再往后翻就有了)。

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

03淘寶交易訂單庫的業(yè)務(wù)痛點(diǎn)

回顧淘寶交易庫的演進(jìn)歷史，自拆分出獨(dú)立的交易歷史庫之后，在持續(xù)十年時間里，業(yè)務(wù)團(tuán)隊(duì)和數(shù)據(jù)庫團(tuán)隊(duì)一直在應(yīng)對幾個核心的挑戰(zhàn)：

存儲成本，每日寫入量巨大且數(shù)據(jù)永不刪除，必須要保證極低的成本。節(jié)省存儲成本的前提下，保證豐富的查詢特性，例如按時間維度排序等。因此底層數(shù)據(jù)庫需要支持二級索引，且二級索引需要保證一致性和性能。保證較低的查詢延時，不影響用戶使用體驗(yàn)。雖然90天前的歷史訂單的查詢量比90天內(nèi)要少很多，但這依然是直接面對用戶的，需要保證長尾延時在一定限度內(nèi)。在2018年，因?yàn)閿?shù)據(jù)庫存儲的原因?qū)е碌挠唵闻判蝈e亂的問題，受到越來越多的投訴，給用戶帶來非常大的困擾，業(yè)務(wù)上決定根治這個問題。從前面的分析總結(jié)看，理想中的交易歷史庫方案需要同時滿足三個條件: 低成本，低延時，特性豐富。使用和在線庫一樣的InnoDB引擎則滿足不了存儲成本的要求，而使用HBase則滿足不了一致性二級索引等要求。

04基于X-Engine引擎的歷史庫方案

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

在考察交易歷史庫的方案時，一個思路是合并在線庫和歷史庫，依賴X-Engine自身的冷熱分離能力, 實(shí)現(xiàn)對90天內(nèi)交易訂單的高性能訪問和90天以前交易訂單記錄的低成本存儲。同時一套統(tǒng)一的交易訂單庫，可以提供諸如二級索引等功能，用戶訂單不能按時間排序的問題也隨之解決，業(yè)務(wù)層的代碼將非常簡單。

但交易訂單系統(tǒng)在在線庫/歷史庫分離的架構(gòu)下迭代了十年的時間，很多業(yè)務(wù)系統(tǒng)的代碼對這套分離架構(gòu)做了兼容，考慮到對業(yè)務(wù)代碼改造以及遷移的風(fēng)險(xiǎn)，我們在初期繼承了之前在線和歷史分離的架構(gòu)。只是將原有的HBase集群替換成了PolarDB-X集群(基于X-Engine引擎的版本)：

在線庫依然沿用之前的MySQL InnoDB集群，但是只保存90天的數(shù)據(jù)量，90天之前的訂單會被刪除，數(shù)據(jù)量少，可以保證較高的緩存命中率，確保讀寫延時。通過數(shù)據(jù)同步將在線庫中超過90天的訂單遷移到歷史庫中，遷移之后該部分訂單從在線庫刪除。歷史庫切換為X-Engine，保存全量的交易訂單數(shù)據(jù)，90之前的訂單讀寫，直接操作歷史庫, 同時歷史庫承接在線庫的所有遷移寫入負(fù)載。

這套架構(gòu)上線之后，交易歷史庫的存儲成本相比較于使用HBase沒有上升，同時由于歷史庫和在線庫能力相同，可以創(chuàng)建完全一樣的索引，歷史訂單恢復(fù)了對訂單按時間排序功能的支持，同時其讀取延時也得到了保證。

05數(shù)據(jù)庫架構(gòu)參考

在淘寶交易歷史庫的方案中，考慮到業(yè)務(wù)層面歷史代碼架構(gòu)的延續(xù)性，采用了InnoDB引擎在線庫和X-Engine歷史庫分離的方案。在這套架構(gòu)中，X-Engine歷史庫其實(shí)同時承擔(dān)了在線庫遷移過來的寫入以及90天以前記錄的讀寫流量。

實(shí)際上，考慮到淘寶交易訂單記錄流水型的訪問特征(最近寫入的記錄會被大量訪問，隨著時間推移，記錄訪問頻次急劇衰減)，X-Engine引擎內(nèi)部的冷熱分離機(jī)制就能很好的處理這種流水型業(yè)務(wù)，所以單一X-Engine數(shù)據(jù)庫集群完全解決需求。

對于新開業(yè)務(wù)或者有大量流水型記錄存儲需求的現(xiàn)有業(yè)務(wù)且業(yè)務(wù)層面還未做冷熱分離，我們建議直接使用一套X-Engine引擎，在存儲成本降低的同時，DB層的訪問代碼會更簡單。基于X-Engine引擎的PolarDB-X分布式數(shù)據(jù)庫可以同時解決scale out問題和成本問題。