隨著樂視硬件搶購(gòu)的不斷升級(jí)掀亩，樂視集團(tuán)支付面臨的請(qǐng)求壓力百倍乃至千倍的暴增槽棍。作為商品購(gòu)買的最后一環(huán)缆巧，保證用戶快速穩(wěn)定的完成支付尤為重要豌拙。所以在15年11月按傅，我們對(duì)整個(gè)支付系統(tǒng)進(jìn)行了全面的架構(gòu)升級(jí)拼岳，使之具備了每秒穩(wěn)定處理10萬訂單的能力惜纸。為樂視生態(tài)各種形式的搶購(gòu)秒殺活動(dòng)提供了強(qiáng)有力的支撐耐版。
一粪牲、庫(kù)分表
在redis虑瀑，memcached等緩存系統(tǒng)盛行的互聯(lián)網(wǎng)時(shí)代湿滓，構(gòu)建一個(gè)支撐每秒十萬只讀的系統(tǒng)并不復(fù)雜，無非是通過一致性哈希擴(kuò)展緩存節(jié)點(diǎn)舌狗，水平擴(kuò)展web服務(wù)器等叽奥。支付系統(tǒng)要處理每秒十萬筆訂單，需要的是每秒數(shù)十萬的數(shù)據(jù)庫(kù)更新操作（insert加update）痛侍，這在任何一個(gè)獨(dú)立數(shù)據(jù)庫(kù)上都是不可能完成的任務(wù)朝氓，所以我們首先要做的是對(duì)訂單表（簡(jiǎn)稱order）進(jìn)行分庫(kù)與分表主届。
在進(jìn)行數(shù)據(jù)庫(kù)操作時(shí)赵哲，一般都會(huì)有用戶ID（簡(jiǎn)稱uid）字段，所以我們選擇以u(píng)id進(jìn)行分庫(kù)分表君丁。
分庫(kù)策略我們選擇了“二叉樹分庫(kù)”枫夺，所謂“二叉樹分庫(kù)”指的是：我們?cè)谶M(jìn)行數(shù)據(jù)庫(kù)擴(kuò)容時(shí)，都是以2的倍數(shù)進(jìn)行擴(kuò)容绘闷。比如：1臺(tái)擴(kuò)容到2臺(tái)橡庞，2臺(tái)擴(kuò)容到4臺(tái)，4臺(tái)擴(kuò)容到8臺(tái)印蔗，以此類推扒最。這種分庫(kù)方式的好處是，我們?cè)谶M(jìn)行擴(kuò)容時(shí)华嘹，只需DBA進(jìn)行表級(jí)的數(shù)據(jù)同步吧趣，而不需要自己寫腳本進(jìn)行行級(jí)數(shù)據(jù)同步。
光是有分庫(kù)是不夠的，經(jīng)過持續(xù)壓力測(cè)試我們發(fā)現(xiàn)强挫，在同一數(shù)據(jù)庫(kù)中岔霸，對(duì)多個(gè)表進(jìn)行并發(fā)更新的效率要遠(yuǎn)遠(yuǎn)大于對(duì)一個(gè)表進(jìn)行并發(fā)更新，所以我們?cè)诿總€(gè)分庫(kù)中都將order表拆分成10份：order_0纠拔，order_1秉剑，….泛豪，order_9稠诲。
最后我們把order表放在了8個(gè)分庫(kù)中（編號(hào)1到8，分別對(duì)應(yīng)DB1到DB8）诡曙，每個(gè)分庫(kù)中10個(gè)分表（編號(hào)0到9臀叙，分別對(duì)應(yīng)order_0到order_9），部署結(jié)構(gòu)如下圖所示：
根據(jù)uid計(jì)算數(shù)據(jù)庫(kù)編號(hào)：
數(shù)據(jù)庫(kù)編號(hào) = (uid / 10) % 8 + 1
根據(jù)uid計(jì)算表編號(hào)：
表編號(hào) = uid % 10
當(dāng)uid=9527時(shí)价卤，根據(jù)上面的算法劝萤，其實(shí)是把uid分成了兩部分952和7，其中952模8加1等于1為數(shù)據(jù)庫(kù)編號(hào)慎璧，而7則為表編號(hào)床嫌。所以u(píng)id=9527的訂單信息需要去DB1庫(kù)中的order_7表查找。具體算法流程也可參見下圖：
有了分庫(kù)分表的結(jié)構(gòu)與算法最后就是尋找分庫(kù)分表的實(shí)現(xiàn)工具胸私，目前市面上約有兩種類型的分庫(kù)分表工具：
- 客戶端分庫(kù)分表厌处，在客戶端完成分庫(kù)分表操作，直連數(shù)據(jù)庫(kù)
- 使用分庫(kù)分表中間件岁疼，客戶端連分庫(kù)分表中間件阔涉，由中間件完成分庫(kù)分表操作
這兩種類型的工具市面上都有，這里不一一列舉捷绒，總的來看這兩類工具各有利弊瑰排。客戶端分庫(kù)分表由于直連數(shù)據(jù)庫(kù)暖侨，所以性能比使用分庫(kù)分表中間件高15%到20%椭住。而使用分庫(kù)分表中間件由于進(jìn)行了統(tǒng)一的中間件管理，將分庫(kù)分表操作和客戶端隔離字逗，模塊劃分更加清晰京郑，便于DBA進(jìn)行統(tǒng)一管理。
我們選擇的是在客戶端分庫(kù)分表扳肛，因?yàn)槲覀冏约洪_發(fā)并開源了一套數(shù)據(jù)層訪問框架傻挂，它的代號(hào)叫“芒果”，芒果框架原生支持分庫(kù)分表功能挖息，并且配置起來非常簡(jiǎn)單金拒。
- 芒果主頁(yè)：mango.jfaster.org
- 芒果源碼：github.com/jfaster/mango
二、訂單ID
訂單系統(tǒng)的ID必須具有全局唯一的特征，最簡(jiǎn)單的方式是利用數(shù)據(jù)庫(kù)的序列绪抛，每操作一次就能獲得一個(gè)全局唯一的自增ID资铡，如果要支持每秒處理10萬訂單，那每秒將至少需要生成10萬個(gè)訂單ID幢码，通過數(shù)據(jù)庫(kù)生成自增ID顯然無法完成上述要求笤休。所以我們只能通過內(nèi)存計(jì)算獲得全局唯一的訂單ID。
JAVA領(lǐng)域最著名的唯一ID應(yīng)該算是UUID了症副，不過UUID太長(zhǎng)而且包含字母店雅，不適合作為訂單ID。通過反復(fù)比較與篩選贞铣，我們借鑒了Twitter的Snowflake算法闹啦，實(shí)現(xiàn)了全局唯一ID。下面是訂單ID的簡(jiǎn)化結(jié)構(gòu)圖：
上圖分為3個(gè)部分：
- 時(shí)間戳
這里時(shí)間戳的粒度是毫秒級(jí)辕坝，生成訂單ID時(shí)窍奋，使用System.currentTimeMillis()作為時(shí)間戳。
- 機(jī)器號(hào)
每個(gè)訂單服務(wù)器都將被分配一個(gè)唯一的編號(hào)酱畅，生成訂單ID時(shí)琳袄，直接使用該唯一編號(hào)作為機(jī)器號(hào)即可。
- 自增序號(hào)
當(dāng)在同一服務(wù)器的同一毫秒中有多個(gè)生成訂單ID的請(qǐng)求時(shí)纺酸，會(huì)在當(dāng)前毫秒下自增此序號(hào)窖逗，下一個(gè)毫秒此序號(hào)繼續(xù)從0開始。比如在同一服務(wù)器同一毫秒有3個(gè)生成訂單ID的請(qǐng)求吁峻，這3個(gè)訂單ID的自增序號(hào)部分將分別是0滑负，1，2用含。
上面3個(gè)部分組合矮慕，我們就能快速生成全局唯一的訂單ID。不過光全局唯一還不夠啄骇，很多時(shí)候我們會(huì)只根據(jù)訂單ID直接查詢訂單信息痴鳄，這時(shí)由于沒有uid，我們不知道去哪個(gè)分庫(kù)的分表中查詢缸夹，遍歷所有的庫(kù)的所有表痪寻？這顯然不行。所以我們需要將分庫(kù)分表的信息添加到訂單ID上虽惭，下面是帶分庫(kù)分表信息的訂單ID簡(jiǎn)化結(jié)構(gòu)圖：
我們?cè)谏傻娜钟唵蜪D頭部添加了分庫(kù)與分表的信息橡类，這樣只根據(jù)訂單ID，我們也能快速的查詢到對(duì)應(yīng)的訂單信息芽唇。
分庫(kù)分表信息具體包含哪些內(nèi)容顾画？第一部分有討論到取劫，我們將訂單表按uid維度拆分成了8個(gè)數(shù)據(jù)庫(kù)，每個(gè)數(shù)據(jù)庫(kù)10張表研侣，最簡(jiǎn)單的分庫(kù)分表信息只需一個(gè)長(zhǎng)度為2的字符串即可存儲(chǔ)谱邪，第1位存數(shù)據(jù)庫(kù)編號(hào)，取值范圍1到8庶诡，第2位存表編號(hào)惦银，取值范圍0到9。
還是按照第一部分根據(jù)uid計(jì)算數(shù)據(jù)庫(kù)編號(hào)和表編號(hào)的算法末誓，當(dāng)uid＝9527時(shí)扯俱，分庫(kù)信息＝1，分表信息＝7基显，將他們進(jìn)行組合蘸吓，兩位的分庫(kù)分表信息即為”17”善炫。具體算法流程參見下圖：
上述使用表編號(hào)作為分表信息沒有任何問題撩幽，但使用數(shù)據(jù)庫(kù)編號(hào)作為分庫(kù)信息卻存在隱患，考慮未來的擴(kuò)容需求箩艺，我們需要將8庫(kù)擴(kuò)容到16庫(kù)窜醉，這時(shí)取值范圍1到8的分庫(kù)信息將無法支撐1到16的分庫(kù)場(chǎng)景，分庫(kù)路由將無法正確完成艺谆，我們將上訴問題簡(jiǎn)稱為分庫(kù)信息精度丟失榨惰。
為解決分庫(kù)信息精度丟失問題，我們需要對(duì)分庫(kù)信息精度進(jìn)行冗余静汤，即我們現(xiàn)在保存的分庫(kù)信息要支持以后的擴(kuò)容琅催。這里我們假設(shè)最終我們會(huì)擴(kuò)容到64臺(tái)數(shù)據(jù)庫(kù)，所以新的分庫(kù)信息算法為：
分庫(kù)信息 = (uid / 10) % 64 + 1
當(dāng)uid＝9527時(shí)虫给，根據(jù)新的算法藤抡，分庫(kù)信息=57，這里的57并不是真正數(shù)據(jù)庫(kù)的編號(hào)抹估，它冗余了最后擴(kuò)展到64臺(tái)數(shù)據(jù)庫(kù)的分庫(kù)信息精度缠黍。我們當(dāng)前只有8臺(tái)數(shù)據(jù)庫(kù)，實(shí)際數(shù)據(jù)庫(kù)編號(hào)還需根據(jù)下面的公式進(jìn)行計(jì)算：
實(shí)際數(shù)據(jù)庫(kù)編號(hào) = (分庫(kù)信息 - 1) % 8 + 1
當(dāng)uid＝9527時(shí)药蜻，分庫(kù)信息＝57瓷式，實(shí)際數(shù)據(jù)庫(kù)編號(hào)＝1，分庫(kù)分表信息=”577”语泽。
由于我們選擇模64來保存精度冗余后的分庫(kù)信息贸典，保存分庫(kù)信息的長(zhǎng)度由1變?yōu)榱?，最后的分庫(kù)分表信息的長(zhǎng)度為3踱卵。具體算法流程也可參見下圖：
如上圖所示廊驼，在計(jì)算分庫(kù)信息的時(shí)候采用了模64的方式冗余了分庫(kù)信息精度，這樣當(dāng)我們的系統(tǒng)以后需要擴(kuò)容到16庫(kù)，32庫(kù)蔬充，64庫(kù)都不會(huì)再有問題蝶俱。
上面的訂單ID結(jié)構(gòu)已經(jīng)能很好的滿足我們當(dāng)前與之后的擴(kuò)容需求，但考慮到業(yè)務(wù)的不確定性饥漫，我們?cè)谟唵蜪D的最前方加了1位用于標(biāo)識(shí)訂單ID的版本榨呆，這個(gè)版本號(hào)屬于冗余數(shù)據(jù)，目前并沒有用到庸队。下面是最終訂單ID簡(jiǎn)化結(jié)構(gòu)圖：
Snowflake算法：github.com/twitter/snowflake
三积蜻、最終一致性
到目前為止，我們通過對(duì)order表uid維度的分庫(kù)分表彻消，實(shí)現(xiàn)了order表的超高并發(fā)寫入與更新竿拆，并能通過uid和訂單ID查詢訂單信息。但作為一個(gè)開放的集團(tuán)支付系統(tǒng)宾尚，我們還需要通過業(yè)務(wù)線ID（又稱商戶ID丙笋，簡(jiǎn)稱bid）來查詢訂單信息惫企，所以我們引入了bid維度的order表集群晃虫，將uid維度的order表集群冗余一份到bid維度的order表集群中刚操，要根據(jù)bid查詢訂單信息時(shí)在岂，只需查bid維度的order表集群即可豫缨。
上面的方案雖然簡(jiǎn)單缩举，但保持兩個(gè)order表集群的數(shù)據(jù)一致性是一件很麻煩的事情洁奈。兩個(gè)表集群顯然是在不同的數(shù)據(jù)庫(kù)集群中串慰，如果在寫入與更新中引入強(qiáng)一致性的分布式事務(wù)淹朋，這無疑會(huì)大大降低系統(tǒng)效率笙各，增長(zhǎng)服務(wù)響應(yīng)時(shí)間，這是我們所不能接受的础芍，所以我們引入了消息隊(duì)列進(jìn)行異步數(shù)據(jù)同步杈抢，來實(shí)現(xiàn)數(shù)據(jù)的最終一致性。當(dāng)然消息隊(duì)列的各種異常也會(huì)造成數(shù)據(jù)不一致者甲，所以我們又引入了實(shí)時(shí)監(jiān)控服務(wù)春感，實(shí)時(shí)計(jì)算兩個(gè)集群的數(shù)據(jù)差異，并進(jìn)行一致性同步虏缸。
下面是簡(jiǎn)化的一致性同步圖：
四鲫懒、數(shù)據(jù)庫(kù)高可用
沒有任何機(jī)器或服務(wù)能保證在線上穩(wěn)定運(yùn)行不出故障。比如某一時(shí)間刽辙，某一數(shù)據(jù)庫(kù)主庫(kù)宕機(jī)窥岩，這時(shí)我們將不能對(duì)該庫(kù)進(jìn)行讀寫操作，線上服務(wù)將受到影響宰缤。
所謂數(shù)據(jù)庫(kù)高可用指的是：當(dāng)數(shù)據(jù)庫(kù)由于各種原因出現(xiàn)問題時(shí)颂翼，能實(shí)時(shí)或快速的恢復(fù)數(shù)據(jù)庫(kù)服務(wù)并修補(bǔ)數(shù)據(jù)晃洒，從整個(gè)集群的角度看，就像沒有出任何問題一樣朦乏。需要注意的是球及，這里的恢復(fù)數(shù)據(jù)庫(kù)服務(wù)并不一定是指修復(fù)原有數(shù)據(jù)庫(kù)，也包括將服務(wù)切換到另外備用的數(shù)據(jù)庫(kù)呻疹。
數(shù)據(jù)庫(kù)高可用的主要工作是數(shù)據(jù)庫(kù)恢復(fù)與數(shù)據(jù)修補(bǔ)吃引，一般我們以完成這兩項(xiàng)工作的時(shí)間長(zhǎng)短，作為衡量高可用好壞的標(biāo)準(zhǔn)刽锤。這里有一個(gè)惡性循環(huán)的問題庐氮，數(shù)據(jù)庫(kù)恢復(fù)的時(shí)間越長(zhǎng)，不一致數(shù)據(jù)越多输枯，數(shù)據(jù)修補(bǔ)的時(shí)間就會(huì)越長(zhǎng)占贫，整體修復(fù)的時(shí)間就會(huì)變得更長(zhǎng)。所以數(shù)據(jù)庫(kù)的快速恢復(fù)成了數(shù)據(jù)庫(kù)高可用的重中之重型奥，試想一下如果我們能在數(shù)據(jù)庫(kù)出故障的1秒之內(nèi)完成數(shù)據(jù)庫(kù)恢復(fù)碉京，修復(fù)不一致的數(shù)據(jù)和成本也會(huì)大大降低谐宙。
下圖是一個(gè)最經(jīng)典的主從結(jié)構(gòu)：
上圖中有1臺(tái)web服務(wù)器和3臺(tái)數(shù)據(jù)庫(kù)，其中DB1是主庫(kù)，DB2和DB3是從庫(kù)帅掘。我們?cè)谶@里假設(shè)web服務(wù)器由項(xiàng)目組維護(hù)，而數(shù)據(jù)庫(kù)服務(wù)器由DBA維護(hù)修档。
當(dāng)從庫(kù)DB2出現(xiàn)問題時(shí)寓免，DBA會(huì)通知項(xiàng)目組，項(xiàng)目組將DB2從web服務(wù)的配置列表中刪除实抡，重啟web服務(wù)器啄清，這樣出錯(cuò)的節(jié)點(diǎn)DB2將不再被訪問辣卒，整個(gè)數(shù)據(jù)庫(kù)服務(wù)得到恢復(fù)场靴，等DBA修復(fù)DB2時(shí)该押，再由項(xiàng)目組將DB2添加到web服務(wù)。
當(dāng)主庫(kù)DB1出現(xiàn)問題時(shí)奠蹬，DBA會(huì)將DB2切換為主庫(kù)朝聋，并通知項(xiàng)目組，項(xiàng)目組使用DB2替換原有的主庫(kù)DB1囤躁，重啟web服務(wù)器冀痕，這樣web服務(wù)將使用新的主庫(kù)DB2，而DB1將不再被訪問狸演，整個(gè)數(shù)據(jù)庫(kù)服務(wù)得到恢復(fù)言蛇，等DBA修復(fù)DB1時(shí)，再將DB1作為DB2的從庫(kù)即可宵距。
上面的經(jīng)典結(jié)構(gòu)有很大的弊怖吧小：不管主庫(kù)或從庫(kù)出現(xiàn)問題，都需要DBA和項(xiàng)目組協(xié)同完成數(shù)據(jù)庫(kù)服務(wù)恢復(fù)满哪，這很難做到自動(dòng)化婿斥，而且恢復(fù)工程也過于緩慢。
我們認(rèn)為哨鸭，數(shù)據(jù)庫(kù)運(yùn)維應(yīng)該和項(xiàng)目組分開民宿，當(dāng)數(shù)據(jù)庫(kù)出現(xiàn)問題時(shí)，應(yīng)由DBA實(shí)現(xiàn)統(tǒng)一恢復(fù)像鸡，不需要項(xiàng)目組操作服務(wù)活鹰，這樣便于做到自動(dòng)化，縮短服務(wù)恢復(fù)時(shí)間坟桅。
先來看從庫(kù)高可用結(jié)構(gòu)圖：
如上圖所示华望，web服務(wù)器將不再直接連接從庫(kù)DB2和DB3，而是連接LVS負(fù)載均衡仅乓，由LVS連接從庫(kù)。這樣做的好處是LVS能自動(dòng)感知從庫(kù)是否可用蓬戚，從庫(kù)DB2宕機(jī)后夸楣，LVS將不會(huì)把讀數(shù)據(jù)請(qǐng)求再發(fā)向DB2。同時(shí)DBA需要增減從庫(kù)節(jié)點(diǎn)時(shí)子漩，只需獨(dú)立操作LVS即可豫喧，不再需要項(xiàng)目組更新配置文件，重啟服務(wù)器來配合幢泼。
再來看主庫(kù)高可用結(jié)構(gòu)圖：
如上圖所示紧显，web服務(wù)器將不再直接連接主庫(kù)DB1，而是連接KeepAlive虛擬出的一個(gè)虛擬ip缕棵，再將此虛擬ip映射到主庫(kù)DB1上孵班，同時(shí)添加DB_bak從庫(kù)涉兽，實(shí)時(shí)同步DB1中的數(shù)據(jù)。正常情況下web還是在DB1中讀寫數(shù)據(jù)篙程，當(dāng)DB1宕機(jī)后枷畏，腳本會(huì)自動(dòng)將DB_bak設(shè)置成主庫(kù)，并將虛擬ip映射到DB_bak上虱饿，web服務(wù)將使用健康的DB_bak作為主庫(kù)進(jìn)行讀寫訪問拥诡。這樣只需幾秒的時(shí)間，就能完成主數(shù)據(jù)庫(kù)服務(wù)恢復(fù)氮发。
組合上面的結(jié)構(gòu)渴肉，得到主從高可用結(jié)構(gòu)圖：
數(shù)據(jù)庫(kù)高可用還包含數(shù)據(jù)修補(bǔ)，由于我們?cè)诓僮骱诵臄?shù)據(jù)時(shí)爽冕，都是先記錄日志再執(zhí)行更新仇祭，加上實(shí)現(xiàn)了近乎實(shí)時(shí)的快速恢復(fù)數(shù)據(jù)庫(kù)服務(wù)，所以修補(bǔ)的數(shù)據(jù)量都不大扇售，一個(gè)簡(jiǎn)單的恢復(fù)腳本就能快速完成數(shù)據(jù)修復(fù)前塔。
五、數(shù)據(jù)分級(jí)
支付系統(tǒng)除了最核心的支付訂單表與支付流水表外承冰，還有一些配置信息表和一些用戶相關(guān)信息表华弓。如果所有的讀操作都在數(shù)據(jù)庫(kù)上完成，系統(tǒng)性能將大打折扣困乒，所以我們引入了數(shù)據(jù)分級(jí)機(jī)制寂屏。
我們簡(jiǎn)單的將支付系統(tǒng)的數(shù)據(jù)劃分成了3級(jí)：
第1級(jí)：訂單數(shù)據(jù)和支付流水?dāng)?shù)據(jù)；這兩塊數(shù)據(jù)對(duì)實(shí)時(shí)性和精確性要求很高娜搂，所以不添加任何緩存迁霎，讀寫操作將直接操作數(shù)據(jù)庫(kù)。
第2級(jí)：用戶相關(guān)數(shù)據(jù)百宇；這些數(shù)據(jù)和用戶相關(guān)考廉，具有讀多寫少的特征，所以我們使用redis進(jìn)行緩存携御。
第3級(jí)：支付配置信息昌粤；這些數(shù)據(jù)和用戶無關(guān)，具有數(shù)據(jù)量小啄刹，頻繁讀涮坐，幾乎不修改的特征，所以我們使用本地內(nèi)存進(jìn)行緩存誓军。
使用本地內(nèi)存緩存有一個(gè)數(shù)據(jù)同步問題袱讹，因?yàn)榕渲眯畔⒕彺嬖趦?nèi)存中，而本地內(nèi)存無法感知到配置信息在數(shù)據(jù)庫(kù)的修改昵时，這樣會(huì)造成數(shù)據(jù)庫(kù)中數(shù)據(jù)和本地內(nèi)存中數(shù)據(jù)不一致的問題捷雕。
為了解決此問題椒丧，我們開發(fā)了一個(gè)高可用的消息推送平臺(tái)，當(dāng)配置信息被修改時(shí)非区，我們可以使用推送平臺(tái)瓜挽，給支付系統(tǒng)所有的服務(wù)器推送配置文件更新消息，服務(wù)器收到消息會(huì)自動(dòng)更新配置信息征绸，并給出成功反饋久橙。
六、粗細(xì)管道
黑客攻擊管怠，前端重試等一些原因會(huì)造成請(qǐng)求量的暴漲淆衷，如果我們的服務(wù)被激增的請(qǐng)求給一波打死，想要重新恢復(fù)渤弛，就是一件非常痛苦和繁瑣的過程祝拯。
舉個(gè)簡(jiǎn)單的例子，我們目前訂單的處理能力是平均10萬下單每秒她肯，峰值14萬下單每秒佳头，如果同一秒鐘有100萬個(gè)下單請(qǐng)求進(jìn)入支付系統(tǒng)，毫無疑問我們的整個(gè)支付系統(tǒng)就會(huì)崩潰晴氨，后續(xù)源源不斷的請(qǐng)求會(huì)讓我們的服務(wù)集群根本啟動(dòng)不起來康嘉，唯一的辦法只能是切斷所有流量，重啟整個(gè)集群籽前，再慢慢導(dǎo)入流量亭珍。
我們?cè)趯?duì)外的web服務(wù)器上加一層“粗細(xì)管道”，就能很好的解決上面的問題枝哄。
下面是粗細(xì)管道簡(jiǎn)單的結(jié)構(gòu)圖：
請(qǐng)看上面的結(jié)構(gòu)圖肄梨，http請(qǐng)求在進(jìn)入web集群前，會(huì)先經(jīng)過一層粗細(xì)管道挠锥。入口端是粗口众羡，我們?cè)O(shè)置最大能支持100萬請(qǐng)求每秒，多余的請(qǐng)求會(huì)被直接拋棄掉蓖租。出口端是細(xì)口纱控，我們?cè)O(shè)置給web集群10萬請(qǐng)求每秒。剩余的90萬請(qǐng)求會(huì)在粗細(xì)管道中排隊(duì)菜秦，等待web集群處理完老的請(qǐng)求后，才會(huì)有新的請(qǐng)求從管道中出來舶掖，給web集群處理球昨。這樣web集群處理的請(qǐng)求數(shù)每秒永遠(yuǎn)不會(huì)超過10萬，在這個(gè)負(fù)載下眨攘，集群中的各個(gè)服務(wù)都會(huì)高校運(yùn)轉(zhuǎn)主慰，整個(gè)集群也不會(huì)因?yàn)楸┰龅恼?qǐng)求而停止服務(wù)嚣州。
如何實(shí)現(xiàn)粗細(xì)管道？nginx商業(yè)版中已經(jīng)有了支持共螺，相關(guān)資料請(qǐng)搜索
nginx max_conns该肴，需要注意的是max_conns是活躍連接數(shù)，具體設(shè)置除了需要確定最大TPS外藐不，還需確定平均響應(yīng)時(shí)間匀哄。
