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

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

 

隨着樂視硬件搶購的不斷升級，樂視集團支付面臨的請求壓力百倍乃至千倍的暴增。做爲商品購買的最後一環，保證用戶快速穩定的完成支付尤其重要。因此在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表查找。具體算法流程也可參見下圖：

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

客戶端分庫分表，在客戶端完成分庫分表操做，直連數據庫

使用分庫分表中間件，客戶端連分庫分表中間件，由中間件完成分庫分表操做

這兩種類型的工具市面上都有，這裏不一一列舉，總的來看這兩類工具各有利弊。客戶端分庫分表因爲直連數據庫，因此性能比使用分庫分表中間件高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個部分：

1.時間戳

這裏時間戳的粒度是毫秒級，生成訂單ID時，使用System.currentTimeMillis()做爲時間戳。

2.機器號

每一個訂單服務器都將被分配一個惟一的編號，生成訂單ID時，直接使用該惟一編號做爲機器號便可。

3.自增序號

當在同一服務器的同一毫秒中有多個生成訂單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服務器將再也不直接鏈接從庫DB2和DB3，而是鏈接LVS負載均衡，由LVS鏈接從庫。這樣作的好處是LVS能自動感知從庫是否可用，從庫DB2宕機後，LVS將不會把讀數據請求再發向DB2。同時DBA須要增減從庫節點時，只需獨立操做LVS便可，再也不須要項目組更新配置文件，重啓服務器來配合。

再來看主庫高可用結構圖：

如上圖所示，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