「每秒處理10萬訂單樂視集團(tuán)支付架構(gòu)」

1、 梁陽鶴,樂視網(wǎng)bo ss平臺技術(shù)部架構(gòu)師,主要負(fù)責(zé)樂視集團(tuán)支付,樂視會員系統(tǒng),商業(yè)運(yùn)營平臺等系統(tǒng)架構(gòu)工作.開源數(shù)據(jù)訪問層框架man go作者.？隨著樂視硬件搶購的不斷升級,樂視集團(tuán)支付面臨的請求壓力百倍乃至千倍的暴增.作為商品購置的最后一環(huán),保證用戶快速穩(wěn)定的完成支付尤為重要.所以在15年11月,我們對整個支付系統(tǒng)進(jìn)行了全面的架構(gòu)升級,使之具備了每秒穩(wěn)定處理10萬訂單的水平.為樂視生態(tài)各種形式的搶購秒殺活動提供了強(qiáng)有力的支撐.一、庫分表在redis , memcached等緩存系統(tǒng)盛行的互聯(lián)網(wǎng)時代,構(gòu)建一個支撐每秒十萬只 讀的系統(tǒng)并不復(fù)雜,無非是通過一致性哈希擴(kuò)展緩存節(jié)點,水平擴(kuò)展web效勞

2、器等.支付系統(tǒng)要處理每秒十萬筆訂單,需要的是每秒數(shù)十萬的數(shù)據(jù)庫更新操作ins e r t力口 u p date,這在任何一個獨立數(shù)據(jù)庫上都是不可能完成的任務(wù),所以我們首先要做的是對訂單表簡稱 o rder進(jìn)行分庫與分表.在進(jìn)行數(shù)據(jù)庫操作時,一般都會有用戶ID簡稱uid字段,所以我們選擇以uid進(jìn)行分庫分表.分庫策略我們選擇了 “二叉樹分庫,所謂“二叉樹分庫指的是 ：我們在進(jìn)行 數(shù)據(jù)庫擴(kuò)容時,都是以2的倍數(shù)進(jìn)行擴(kuò)容.比方:1臺擴(kuò)容到2臺,2臺擴(kuò)容到4臺,4臺擴(kuò)容到8臺,以此類推.這種分庫方式的好處是,我們在進(jìn)行擴(kuò)容時,只需DBA進(jìn)行表級的數(shù)據(jù)同步,而不需要自己寫腳本進(jìn)行行級數(shù)據(jù)同步.光是有分庫是

3、不夠的,經(jīng)過持續(xù)壓力測試我們發(fā)現(xiàn),在同一數(shù)據(jù)庫中,對多個表進(jìn) 行并發(fā)更新的效率要遠(yuǎn)遠(yuǎn)大于對一個表進(jìn)行并發(fā)更新,所以我們在每個分庫中都 將 order 表拆分成 1 0 份:or d e r _0,o rder_1, - -.o r der_9.最后我們把or d e r表放在了 8個分庫中編號1到8 ,分別對應(yīng)DB1到DB8,每個分庫中10個分表編號0到9,分別對應(yīng)order_0到order _ 9,部署結(jié)構(gòu)如下列圖所示:uid維度.de表集群DB1DB2DB3DB4order_0 order 1order_8order 9order_0order 1order_8order 9order_0

4、order 1order_8order 9order_0 order 1ordec8order 9DB5DB6DB7DB8order_0 order 1ordec8order 9ordecO order 1ordec8order 9order_0 order 1order_8order 9order_0 oder_l order_8order 9jF根據(jù)uid計算數(shù)據(jù)庫編號數(shù)據(jù)庫編號 =(u I d / 10) % 8+ 1根據(jù)uid計算表編號： 表編號=uid % 1 0當(dāng)uid=9527 時,根據(jù)上面的算法 洪實是把uid分成了兩局部952和7,其中95 2模8力口 1等于1為數(shù)據(jù)庫編號,而7那么為表編號.所以uid =952 7的訂單信息需要去DB1庫中的o rd 6 r_7表查找.具體算法流程也可參見下列圖：根據(jù)3d計算庫與表I模8加除10取整9521DB19527I I模10 0 r 7 1 orde；7有了分庫分表的結(jié)構(gòu)與算法最后就是尋找分庫分表的實現(xiàn)工具,目前市面上約有兩種類型的分庫分表工具：1 .客戶端分庫分表,在客戶端完成分庫分表操作,直連數(shù)據(jù)庫2 .使用分庫分表中間件,客戶端連分庫分表中間件,由中間件完成分庫分