每秒處理10萬訂單樂視集團支付架構

鬆門一枝花發表於2016-05-12

原文:http://www.iteye.com/news/31550

-----------

隨著樂視硬體搶購的不斷升級,樂視集團支付面臨的請求壓力百倍乃至千倍的暴增。作為商品購買的最後一環,保證使用者快速穩定的完成支付尤為重要。所以在15年11月,我們對整個支付系統進行了全面的架構升級,使之具備了每秒穩定處理10萬訂單的能力。為樂視生態各種形式的搶購秒殺活動提供了強有力的支撐。 

一、庫分表 
在redis,memcached等快取系統盛行的網際網路時代,構建一個支撐每秒十萬只讀的系統並不複雜,無非是通過一致性雜湊擴充套件快取節點,水平擴充套件web伺服器等。支付系統要處理每秒十萬筆訂單,需要的是每秒數十萬的資料庫更新操作(insert加update),這在任何一個獨立資料庫上都是不可能完成的任務,所以我們首先要做的是對訂單表(簡稱order)進行分庫與分表。 

在進行資料庫操作時,一般都會有使用者ID(簡稱uid)欄位,所以我們選擇以uid進行分庫分表。 

分庫策略我們選擇了“二叉樹分庫”,所謂“二叉樹分庫”指的是:我們在進行資料庫擴容時,都是以2的倍數進行擴容。比如:1臺擴容到2臺,2臺擴容到4臺,4臺擴容到8臺,以此類推。這種分庫方式的好處是,我們在進行擴容時,只需DBA進行表級的資料同步,而不需要自己寫指令碼進行行級資料同步。 

光是有分庫是不夠的,經過持續壓力測試我們發現,在同一資料庫中,對多個表進行併發更新的效率要遠遠大於對一個表進行併發更新,所以我們在每個分庫中都將order表拆分成10份:order_0,order_1,….,order_9。 

最後我們把order表放在了8個分庫中(編號1到8,分別對應DB1到DB8),每個分庫中10個分表(編號0到9,分別對應order_0到order_9),部署結構如下圖所示: 


 

根據uid計算資料庫編號: 

資料庫編號 = (uid / 10) % 8 + 1 

根據uid計算表編號: 

表編號 = uid % 10 

當uid=9527時,根據上面的演算法,其實是把uid分成了兩部分952和7,其中952模8加1等於1為資料庫編號,而7則為表編號。所以uid=9527的訂單資訊需要去DB1庫中的order_7表查詢。具體演算法流程也可參見下圖: 

 

有了分庫分表的結構與演算法最後就是尋找分庫分表的實現工具,目前市面上約有兩種型別的分庫分表工具: 

1.客戶端分庫分表,在客戶端完成分庫分表操作,直連資料庫 
2.使用分庫分表中介軟體,客戶端連分庫分表中介軟體,由中介軟體完成分庫分表操作 
這兩種型別的工具市面上都有,這裡不一一列舉,總的來看這兩類工具各有利弊。客戶端分庫分表由於直連資料庫,所以效能比使用分庫分表中介軟體高15%到20%。而使用分庫分表中介軟體由於進行了統一的中介軟體管理,將分庫分表操作和客戶端隔離,模組劃分更加清晰,便於DBA進行統一管理。 

我們選擇的是在客戶端分庫分表,因為我們自己開發並開源了一套資料層訪問框架,它的代號叫“芒果”,芒果框架原生支援分庫分表功能,並且配置起來非常簡單。 
  • 芒果主頁:mango.jfaster.org
  • 芒果原始碼:github.com/jfaster/mango

二、訂單ID 
訂單系統的ID必須具有全域性唯一的特徵,最簡單的方式是利用資料庫的序列,每操作一次就能獲得一個全域性唯一的自增ID,如果要支援每秒處理10萬訂單,那每秒將至少需要生成10萬個訂單ID,通過資料庫生成自增ID顯然無法完成上述要求。所以我們只能通過記憶體計算獲得全域性唯一的訂單ID。 

JAVA領域最著名的唯一ID應該算是UUID了,不過UUID太長而且包含字母,不適合作為訂單ID。通過反覆比較與篩選,我們借鑑了Twitter的Snowflake演算法,實現了全域性唯一ID。下面是訂單ID的簡化結構圖: 

 

上圖分為3個部分: 

時間戳 
這裡時間戳的粒度是毫秒級,生成訂單ID時,使用System.currentTimeMillis()作為時間戳。 

機器號 
每個訂單伺服器都將被分配一個唯一的編號,生成訂單ID時,直接使用該唯一編號作為機器號即可。 

自增序號 
當在同一伺服器的同一毫秒中有多個生成訂單ID的請求時,會在當前毫秒下自增此序號,下一個毫秒此序號繼續從0開始。比如在同一伺服器同一毫秒有3個生成訂單ID的請求,這3個訂單ID的自增序號部分將分別是0,1,2。 

上面3個部分組合,我們就能快速生成全域性唯一的訂單ID。不過光全域性唯一還不夠,很多時候我們會只根據訂單ID直接查詢訂單資訊,這時由於沒有uid,我們不知道去哪個分庫的分表中查詢,遍歷所有的庫的所有表?這顯然不行。所以我們需要將分庫分表的資訊新增到訂單ID上,下面是帶分庫分表資訊的訂單ID簡化結構圖: 

 

我們在生成的全域性訂單ID頭部新增了分庫與分表的資訊,這樣只根據訂單ID,我們也能快速的查詢到對應的訂單資訊。 

分庫分表資訊具體包含哪些內容?第一部分有討論到,我們將訂單表按uid維度拆分成了8個資料庫,每個資料庫10張表,最簡單的分庫分表資訊只需一個長度為2的字串即可儲存,第1位存資料庫編號,取值範圍1到8,第2位存表編號,取值範圍0到9。 

還是按照第一部分根據uid計算資料庫編號和表編號的演算法,當uid=9527時,分庫資訊=1,分表資訊=7,將他們進行組合,兩位的分庫分表資訊即為”17”。具體演算法流程參見下圖: 

 

上述使用表編號作為分表資訊沒有任何問題,但使用資料庫編號作為分庫資訊卻存在隱患,考慮未來的擴容需求,我們需要將8庫擴容到16庫,這時取值範圍1到8的分庫資訊將無法支撐1到16的分庫場景,分庫路由將無法正確完成,我們將上訴問題簡稱為分庫資訊精度丟失。 

為解決分庫資訊精度丟失問題,我們需要對分庫資訊精度進行冗餘,即我們現在儲存的分庫資訊要支援以後的擴容。這裡我們假設最終我們會擴容到64臺資料庫,所以新的分庫資訊演算法為: 

分庫資訊 = (uid / 10) % 64 + 1 

當uid=9527時,根據新的演算法,分庫資訊=57,這裡的57並不是真正資料庫的編號,它冗餘了最後擴充套件到64臺資料庫的分庫資訊精度。我們當前只有8臺資料庫,實際資料庫編號還需根據下面的公式進行計算: 

實際資料庫編號 = (分庫資訊 - 1) % 8 + 1 

當uid=9527時,分庫資訊=57,實際資料庫編號=1,分庫分表資訊=”577”。 

由於我們選擇模64來儲存精度冗餘後的分庫資訊,儲存分庫資訊的長度由1變為了2,最後的分庫分表資訊的長度為3。具體演算法流程也可參見下圖: 

 

如上圖所示,在計算分庫資訊的時候採用了模64的方式冗餘了分庫資訊精度,這樣當我們的系統以後需要擴容到16庫,32庫,64庫都不會再有問題。 

上面的訂單ID結構已經能很好的滿足我們當前與之後的擴容需求,但考慮到業務的不確定性,我們在訂單ID的最前方加了1位用於標識訂單ID的版本,這個版本號屬於冗餘資料,目前並沒有用到。下面是最終訂單ID簡化結構圖: 

 

Snowflake演算法:github.com/twitter/snowflake 

三、最終一致性 
到目前為止,我們通過對order表uid維度的分庫分表,實現了order表的超高併發寫入與更新,並能通過uid和訂單ID查詢訂單資訊。但作為一個開放的集團支付系統,我們還需要通過業務線ID(又稱商戶ID,簡稱bid)來查詢訂單資訊,所以我們引入了bid維度的order表叢集,將uid維度的order表叢集冗餘一份到bid維度的order表叢集中,要根據bid查詢訂單資訊時,只需查bid維度的order表叢集即可。 

上面的方案雖然簡單,但保持兩個order表叢集的資料一致性是一件很麻煩的事情。兩個表叢集顯然是在不同的資料庫叢集中,如果在寫入與更新中引入強一致性的分散式事務,這無疑會大大降低系統效率,增長服務響應時間,這是我們所不能接受的,所以我們引入了訊息佇列進行非同步資料同步,來實現資料的最終一致性。當然訊息佇列的各種異常也會造成資料不一致,所以我們又引入了實時監控服務,實時計算兩個叢集的資料差異,並進行一致性同步。 

下面是簡化的一致性同步圖: 

 

四、資料庫高可用 
沒有任何機器或服務能保證線上上穩定執行不出故障。比如某一時間,某一資料庫主庫當機,這時我們將不能對該庫進行讀寫操作,線上服務將受到影響。 

所謂資料庫高可用指的是:當資料庫由於各種原因出現問題時,能實時或快速的恢復資料庫服務並修補資料,從整個叢集的角度看,就像沒有出任何問題一樣。需要注意的是,這裡的恢復資料庫服務並不一定是指修復原有資料庫,也包括將服務切換到另外備用的資料庫。 

資料庫高可用的主要工作是資料庫恢復與資料修補,一般我們以完成這兩項工作的時間長短,作為衡量高可用好壞的標準。這裡有一個惡性迴圈的問題,資料庫恢復的時間越長,不一致資料越多,資料修補的時間就會越長,整體修復的時間就會變得更長。所以資料庫的快速恢復成了資料庫高可用的重中之重,試想一下如果我們能在資料庫出故障的1秒之內完成資料庫恢復,修復不一致的資料和成本也會大大降低。 

下圖是一個最經典的主從結構: 

 

上圖中有1臺web伺服器和3臺資料庫,其中DB1是主庫,DB2和DB3是從庫。我們在這裡假設web伺服器由專案組維護,而資料庫伺服器由DBA維護。 

當從庫DB2出現問題時,DBA會通知專案組,專案組將DB2從web服務的配置列表中刪除,重啟web伺服器,這樣出錯的節點DB2將不再被訪問,整個資料庫服務得到恢復,等DBA修復DB2時,再由專案組將DB2新增到web服務。 

當主庫DB1出現問題時,DBA會將DB2切換為主庫,並通知專案組,專案組使用DB2替換原有的主庫DB1,重啟web伺服器,這樣web服務將使用新的主庫DB2,而DB1將不再被訪問,整個資料庫服務得到恢復,等DBA修復DB1時,再將DB1作為DB2的從庫即可。 

上面的經典結構有很大的弊病:不管主庫或從庫出現問題,都需要DBA和專案組協同完成資料庫服務恢復,這很難做到自動化,而且恢復工程也過於緩慢。 

我們認為,資料庫運維應該和專案組分開,當資料庫出現問題時,應由DBA實現統一恢復,不需要專案組操作服務,這樣便於做到自動化,縮短服務恢復時間。 

先來看從庫高可用結構圖: 

 

如上圖所示,web伺服器將不再直接連線主庫DB1,而是連線KeepAlive虛擬出的一個虛擬ip,再將此虛擬ip對映到主庫DB1上,同時新增DB_bak從庫,實時同步DB1中的資料。正常情況下web還是在DB1中讀寫資料,當DB1當機後,指令碼會自動將DB_bak設定成主庫,並將虛擬ip對映到DB_bak上,web服務將使用健康的DB_bak作為主庫進行讀寫訪問。這樣只需幾秒的時間,就能完成主資料庫服務恢復。 

組合上面的結構,得到主從高可用結構圖: 

 

資料庫高可用還包含資料修補,由於我們在操作核心資料時,都是先記錄日誌再執行更新,加上實現了近乎實時的快速恢復資料庫服務,所以修補的資料量都不大,一個簡單的恢復指令碼就能快速完成資料修復。 

五、資料分級 
支付系統除了最核心的支付訂單表與支付流水錶外,還有一些配置資訊表和一些使用者相關資訊表。如果所有的讀操作都在資料庫上完成,系統效能將大打折扣,所以我們引入了資料分級機制。 

我們簡單的將支付系統的資料劃分成了3級: 

第1級:訂單資料和支付流水資料;這兩塊資料對實時性和精確性要求很高,所以不新增任何快取,讀寫操作將直接運算元據庫。 

第2級:使用者相關資料;這些資料和使用者相關,具有讀多寫少的特徵,所以我們使用redis進行快取。 

第3級:支付配置資訊;這些資料和使用者無關,具有資料量小,頻繁讀,幾乎不修改的特徵,所以我們使用本地記憶體進行快取。 

使用本地記憶體快取有一個資料同步問題,因為配置資訊快取在記憶體中,而本地記憶體無法感知到配置資訊在資料庫的修改,這樣會造成資料庫中資料和本地記憶體中資料不一致的問題。 

為了解決此問題,我們開發了一個高可用的訊息推送平臺,當配置資訊被修改時,我們可以使用推送平臺,給支付系統所有的伺服器推送配置檔案更新訊息,伺服器收到訊息會自動更新配置資訊,並給出成功反饋。 

六、粗細管道 
黑客攻擊,前端重試等一些原因會造成請求量的暴漲,如果我們的服務被激增的請求給一波打死,想要重新恢復,就是一件非常痛苦和繁瑣的過程。 

舉個簡單的例子,我們目前訂單的處理能力是平均10萬下單每秒,峰值14萬下單每秒,如果同一秒鐘有100萬個下單請求進入支付系統,毫無疑問我們的整個支付系統就會崩潰,後續源源不斷的請求會讓我們的服務叢集根本啟動不起來,唯一的辦法只能是切斷所有流量,重啟整個叢集,再慢慢匯入流量。 

我們在對外的web伺服器上加一層“粗細管道”,就能很好的解決上面的問題。 

下面是粗細管道簡單的結構圖: 

 

請看上面的結構圖,http請求在進入web叢集前,會先經過一層粗細管道。入口端是粗口,我們設定最大能支援100萬請求每秒,多餘的請求會被直接拋棄掉。出口端是細口,我們設定給web叢集10萬請求每秒。剩餘的90萬請求會在粗細管道中排隊,等待web叢集處理完老的請求後,才會有新的請求從管道中出來,給web叢集處理。這樣web叢集處理的請求數每秒永遠不會超過10萬,在這個負載下,叢集中的各個服務都會高校運轉,整個叢集也不會因為暴增的請求而停止服務。 

如何實現粗細管道?nginx商業版中已經有了支援,相關資料請搜尋 

nginx max_conns,需要注意的是max_conns是活躍連線數,具體設定除了需要確定最大TPS外,還需確定平均響應時間。 

nginx相關:http://nginx.org/en/docs/http/ngx_http_upstream_module.html

相關文章