一熄求、從一道面試題開始

面試一家公司渣玲，上來就問：項(xiàng)目中是怎么解決高并發(fā)的？

看來高并發(fā)這個(gè)問題在面試中是逃離不了了弟晚，現(xiàn)在寫一點(diǎn)自己淺薄的理解忘衍。我覺得要回答這個(gè)問題可以從這幾個(gè)方面入手：

第一、硬件層面卿城，服務(wù)器用更大的內(nèi)存枚钓，更好的硬盤∩海考慮到 Money搀捷，這肯定不是面試官想聽的答案，不過可以提上一嘴多望。

第二嫩舟、軟件層面，這也是重點(diǎn)怀偷，先簡(jiǎn)單介紹一下家厌，后面再詳細(xì)說明：

1. 應(yīng)用服務(wù)器肯定是最先抗不住的，所以先搞一個(gè) Nginx 做負(fù)責(zé)均衡椎工，后臺(tái)多部署幾臺(tái)應(yīng)用服務(wù)器像街，將請(qǐng)求均勻的分發(fā)到每臺(tái)服務(wù)器上；

2. 有了 Nginx 負(fù)責(zé)均衡晋渺，應(yīng)用服務(wù)器的壓力暫時(shí)抗住了镰绎，現(xiàn)在就輪到數(shù)據(jù)庫(kù)這塊抗不住了。這時(shí)候就要考慮分庫(kù)分表了木西，還有就是讀寫分離畴栖，將寫的壓力搞到主庫(kù) Master 上，讀的壓力搞到從庫(kù) Slave八千。就是：分庫(kù)分表 + 讀寫分離吗讶；

3. 如果訪問量繼續(xù)擴(kuò)大，此時(shí)可以不停的加服務(wù)器恋捆，但如果就是簡(jiǎn)單的不停的加機(jī)器照皆，其實(shí)是不對(duì)的，這時(shí)就應(yīng)該加入緩存服務(wù)器沸停。

4. 上一步的緩存只是解決了讀的問題膜毁，其實(shí)寫的壓力還是很大，這個(gè)時(shí)候就要引入消息中間鍵了，像各種 MQ 之類的瘟滨，可以很好的做寫請(qǐng)求異步化處理候醒，實(shí)現(xiàn)削峰填谷的效果。

二杂瘸、先考慮一個(gè)最簡(jiǎn)單的系統(tǒng)架構(gòu)

假設(shè)剛剛開始你的系統(tǒng)就部署在一臺(tái)機(jī)器上倒淫，背后就連接了一臺(tái)數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)部署在一臺(tái)服務(wù)器上败玉。

我們可以再現(xiàn)實(shí)點(diǎn)敌土，給個(gè)例子，你的系統(tǒng)部署的機(jī)器是 4 核 8G运翼，數(shù)據(jù)庫(kù)服務(wù)器是 16 核 32G纯赎。這個(gè)架構(gòu)夠簡(jiǎn)單吧！

此時(shí)假設(shè)系統(tǒng)用戶量總共就 10 萬南蹂，用戶量很少犬金，日活用戶按照不同系統(tǒng)的場(chǎng)景有區(qū)別，取一個(gè)較為客觀的比例六剥，10% 吧晚顷，每天活躍的用戶就 1 萬。按照 2-8 法則疗疟，每天高峰期算 4 個(gè)小時(shí)该默，高峰期活躍的用戶占比達(dá)到 80%，就是 8000 人活躍在 4 小時(shí)內(nèi)策彤。然后每個(gè)人對(duì)你的系統(tǒng)發(fā)起的請(qǐng)求栓袖，我們算每天是 20 次吧。那么高峰期 8000 人發(fā)起的請(qǐng)求也才 16 萬次店诗，平均每秒也就 10 次請(qǐng)求裹刮。

好吧！完全跟高并發(fā)搭不上邊庞瘸，對(duì)不對(duì)捧弃？然后系統(tǒng)層面每秒是 10 次請(qǐng)求，對(duì)數(shù)據(jù)庫(kù)的調(diào)用每次請(qǐng)求都會(huì)好幾次數(shù)據(jù)庫(kù)操作的擦囊，比如做做 CRUD 之類的违霞。那么我們?nèi)∫淮握?qǐng)求對(duì)應(yīng) 3 次數(shù)據(jù)庫(kù)操作吧，那這樣的話瞬场，數(shù)據(jù)庫(kù)層每秒也就 30 次請(qǐng)求买鸽，對(duì)吧？

按照上述這臺(tái)數(shù)據(jù)庫(kù)服務(wù)器的配置贯被，支撐是絕對(duì)沒問題的眼五。用一張圖表示妆艘，就是下面這樣：

最簡(jiǎn)單的架構(gòu)

假設(shè)此時(shí)你的用戶數(shù)開始快速增長(zhǎng)，比如用戶量增長(zhǎng)了 50 倍弹砚，此時(shí)日活用戶是 50 萬双仍，高峰期對(duì)系統(tǒng)每秒請(qǐng)求是 500/s枢希。然后對(duì)數(shù)據(jù)庫(kù)的每秒請(qǐng)求數(shù)量是 1500/s桌吃，這個(gè)時(shí)候會(huì)怎么樣呢?

按照上述的機(jī)器配置來說，庫(kù)層面基本上 1500/s 的請(qǐng)求壓力的話苞轿，還算可以接受茅诱。但是如果系統(tǒng)內(nèi)處理的是較復(fù)雜的業(yè)務(wù)邏輯，很可能你會(huì)發(fā)搬卒，現(xiàn)應(yīng)用服務(wù)器 CPU 負(fù)載較高了瑟俭。這時(shí)，我們就需要對(duì)應(yīng)用服務(wù)器做集群部署了契邀。

三摆寄、系統(tǒng)集群化部署

集群化部署可以在應(yīng)用服務(wù)器前面掛一個(gè)負(fù)載均衡層，把請(qǐng)求均勻打到系統(tǒng)層面坯门，讓系統(tǒng)可以用多臺(tái)機(jī)器集群化支撐更高的并發(fā)壓力微饥。

比如說，這里假設(shè)給系統(tǒng)增加部署一臺(tái)機(jī)器古戴，那么平均下來欠橘，每臺(tái)機(jī)器就只有 250/s 的請(qǐng)求了。這樣一來现恼，兩臺(tái)機(jī)器的 CPU 負(fù)載都會(huì)明顯降低肃续，這個(gè)初步的“高并發(fā)”不就先 hold 住了嗎？

要是連這個(gè)都不做叉袍，那單臺(tái)機(jī)器負(fù)載越來越高的時(shí)候始锚，極端情況下是可能出現(xiàn)機(jī)器上部署的系統(tǒng)無法有足夠的資源響應(yīng)請(qǐng)求了，然后出現(xiàn)請(qǐng)求卡死喳逛，甚至系統(tǒng)宕機(jī)之類的問題疼蛾。

所以，簡(jiǎn)單小結(jié)艺配，第一步要做的：先搞一個(gè) Nginx 做負(fù)責(zé)均衡察郁，將請(qǐng)求均勻打到系統(tǒng)層，后臺(tái)多部署幾臺(tái)應(yīng)用服務(wù)器转唉，將請(qǐng)求均勻的分發(fā)到每臺(tái)服務(wù)器上皮钠，此時(shí)的架構(gòu)圖變成下面的樣子：

Nginx 做負(fù)責(zé)均衡

四、數(shù)據(jù)庫(kù)：分庫(kù)分表 + 讀寫分離

假設(shè)此時(shí)用戶量繼續(xù)增長(zhǎng)赠法，達(dá)到了 1000 萬注冊(cè)用戶麦轰，那么此時(shí)對(duì)系統(tǒng)層面的請(qǐng)求量會(huì)達(dá)到每秒 1000/s乔夯，系統(tǒng)層面，你可以繼續(xù)通過集群化的方式來擴(kuò)容款侵，反正前面的負(fù)載均衡層會(huì)均勻分散流量過去的末荐。但是，這時(shí)數(shù)據(jù)庫(kù)層面接受的請(qǐng)求量會(huì)達(dá)到 3000/s新锈，這個(gè)就有點(diǎn)問題了甲脏。

一般來說，普通配置的線上數(shù)據(jù)庫(kù)妹笆，建議就是讀寫并發(fā)加起來块请，不要超過 3000/s。因?yàn)閿?shù)據(jù)庫(kù)壓力過大拳缠，首先一個(gè)問題就是高峰期系統(tǒng)性能可能會(huì)降低墩新，因?yàn)閿?shù)據(jù)庫(kù)負(fù)載過高對(duì)性能會(huì)有影響。

另外窟坐，壓力過大把你的數(shù)據(jù)庫(kù)給搞掛了怎么辦海渊？所以此時(shí)你必須得對(duì)系統(tǒng)做分庫(kù)分表 + 讀寫分離，也就是把一個(gè)庫(kù)拆分為多個(gè)庫(kù)哲鸳，部署在多個(gè)數(shù)據(jù)庫(kù)服務(wù)上臣疑。

再另外，即使數(shù)據(jù)庫(kù)抗住了并發(fā)帕胆，但隨著時(shí)間的推移朝捆，數(shù)據(jù)量也會(huì)越來越大，過多的數(shù)據(jù)懒豹，在對(duì)數(shù)據(jù)庫(kù)進(jìn)行 CRUD 操作時(shí)也會(huì)大大影響性能芙盘。一般情況下，數(shù)據(jù)達(dá)到 500W+ 以后查詢統(tǒng)計(jì)性能嚴(yán)重下降脸秽。

1儒老、先說說數(shù)據(jù)庫(kù)的分庫(kù)分表：

數(shù)據(jù)切分根據(jù)其切分類型，可以分為兩種方式：垂直拆分和水平拆分记餐。

水平拆分與垂直拆分

垂直拆分：基于數(shù)據(jù)庫(kù)中的"列"進(jìn)行驮樊，某個(gè)表字段較多，可以新建一張擴(kuò)展表片酝，將不經(jīng)常用或字段長(zhǎng)度較大的字段拆分出去到擴(kuò)展表中囚衔。

例如在上圖中，name雕沿、age 為常用字段练湿，可以拆分到一張表中，而 sex审轮、photo肥哎、grade 為不常用字段辽俗，可以拆分到另一張表中，當(dāng)然這里只是舉例子篡诽，你可以根據(jù)實(shí)際情況來拆分崖飘。

垂直拆分

這樣做的好處是：
由于 MySQL 底層是通過數(shù)據(jù)頁(yè)存儲(chǔ)的，一條記錄占用空間過大杈女，可能會(huì)導(dǎo)致跨頁(yè)查詢朱浴，進(jìn)而造成額外的性能開銷。通過垂直拆分碧信，表中字段長(zhǎng)度較短且訪問頻率較高的優(yōu)先訪問赊琳，內(nèi)存能加載更多的數(shù)據(jù)街夭，命中率更高砰碴，減少了磁盤 IO，從而提升了數(shù)據(jù)庫(kù)性能板丽。同時(shí)解決業(yè)務(wù)系統(tǒng)層面的耦合呈枉，業(yè)務(wù)清晰。

當(dāng)然缺點(diǎn)也很明顯：
部分表無法 join埃碱，只能通過接口聚合方式解決猖辫，提升了開發(fā)的復(fù)雜度，分布式事務(wù)處理復(fù)雜砚殿，依然存在單表數(shù)據(jù)量過大的問題（需要水平切分）啃憎。

水平拆分：將同一個(gè)表按不同的條件分散到多個(gè)數(shù)據(jù)庫(kù)或多個(gè)表中，每個(gè)表中只包含一部分?jǐn)?shù)據(jù)似炎，從而使得單個(gè)表的數(shù)據(jù)量變小辛萍。

還是上圖的例子，把 ID 為 0 ~ 99999 的數(shù)據(jù)放在第一個(gè)表羡藐，把 ID 為 99999 ~ 199999 的數(shù)據(jù)放在第二個(gè)表贩毕，以此類推。

水平切分的優(yōu)點(diǎn)：
不存在單庫(kù)數(shù)據(jù)量過大仆嗦、高并發(fā)的性能瓶頸辉阶，提升系統(tǒng)穩(wěn)定性和負(fù)載能力。應(yīng)用端改造較小瘩扼，不需要拆分業(yè)務(wù)模塊谆甜。

缺點(diǎn)：
跨分片的事務(wù)一致性難以保證，跨庫(kù)的 join 關(guān)聯(lián)查詢性能較差集绰，數(shù)據(jù)多次擴(kuò)展難度和維護(hù)量極大规辱。

2、再說說讀寫分離

回到并發(fā)的例子倒慧，此時(shí)假設(shè)對(duì)數(shù)據(jù)庫(kù)層面的總并發(fā)是 3000/s按摘，其中寫并發(fā)占到了 1000/s包券，讀并發(fā)占到了 2000/s。

那么一旦分庫(kù)分表之后炫贤，采用兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器上部署主庫(kù)來支撐寫請(qǐng)求溅固，每臺(tái)服務(wù)器承載的寫并發(fā)就是 500/s。每臺(tái)主庫(kù)掛載一個(gè)服務(wù)器部署從庫(kù)兰珍，那么 2 個(gè)從庫(kù)每個(gè)從庫(kù)支撐的讀并發(fā)就是 1000/s侍郭。

簡(jiǎn)單總結(jié)，并發(fā)量繼續(xù)增長(zhǎng)時(shí)掠河，我們就需要 focus 在數(shù)據(jù)庫(kù)層面：分庫(kù)分表 + 讀寫分離亮元。此時(shí)的架構(gòu)圖如下所示：

分庫(kù)分表 + 讀寫分離

五、緩存引入

如果你的用戶量繼續(xù)增大呢唠摹？

這還不好辦爆捞？繼續(xù)加機(jī)器就行了唄！

如果你只是簡(jiǎn)單的不停的加機(jī)器勾拉，其實(shí)是不對(duì)的煮甥，因?yàn)榉?wù)器還是挺貴的。這時(shí)就應(yīng)該加入緩存服務(wù)器藕赞。把所有請(qǐng)求過的結(jié)果成肘，保存在緩存服務(wù)器，下次如果來了相同的請(qǐng)求斧蜕，那么直接在緩存中查找双霍，而不用查數(shù)據(jù)庫(kù)了，這樣一來減少了數(shù)據(jù)庫(kù)的請(qǐng)求壓力批销，二來緩存的查詢一般都是比數(shù)據(jù)庫(kù)快洒闸，進(jìn)而加快了響應(yīng)速度。

在上面的例子中风钻，假設(shè) 90% 的讀請(qǐng)求都是重復(fù)的顷蟀，那么現(xiàn)在的架構(gòu)如下圖：

緩存引入

可能未來你的系統(tǒng)讀請(qǐng)求每秒都幾萬次了，但是可能 80%~90% 都是通過緩存集群來讀的骡技，而緩存集群里的機(jī)器可能單機(jī)每秒都可以支撐幾萬讀請(qǐng)求鸣个，所耗費(fèi)機(jī)器資源很少，可能就兩三臺(tái)機(jī)器就夠了布朦。

你要是換成是數(shù)據(jù)庫(kù)來試一下囤萤，可能就要不停的加從庫(kù)到10臺(tái)、20臺(tái)機(jī)器才能抗住每秒幾萬的讀并發(fā)是趴，那個(gè)成本是極高的涛舍。

關(guān)于緩存集群的進(jìn)階，可以看看白話“一致哈纤敉荆”這篇文章富雅。

緩存機(jī)制的引入避免請(qǐng)求過多時(shí)掸驱，直接與數(shù)據(jù)庫(kù)操作從而造成系統(tǒng)瓶頸，極大的提升了用戶體驗(yàn)和系統(tǒng)穩(wěn)定性没佑。但同時(shí)也帶來了一些需要注意的問題：

1毕贼、緩存穿透
緩存穿透是指查詢一個(gè)一定不存在的數(shù)據(jù)，因?yàn)榫彺嬷幸矡o該數(shù)據(jù)的信息蛤奢，則會(huì)直接去數(shù)據(jù)庫(kù)層進(jìn)行查詢鬼癣，從系統(tǒng)層面來看像是穿透了緩存層直接達(dá)到 DB，從而稱為緩存穿透啤贩。

沒有了緩存層的保護(hù)待秃，查詢一定不存在的數(shù)據(jù)對(duì)系統(tǒng)來說可能是一種危險(xiǎn)，如果有人惡意用這種查詢頻繁請(qǐng)求痹屹，不章郁，準(zhǔn)確的說是攻擊系統(tǒng)，大量的請(qǐng)求都會(huì)到達(dá)數(shù)據(jù)庫(kù)層導(dǎo)致 DB 癱瘓從而引起系統(tǒng)故障痢掠。

解決辦法可以使用空值緩存：一種比較簡(jiǎn)單的解決辦法驱犹。

在第一次查詢完不存在的數(shù)據(jù)后嘲恍，將該 Key 與對(duì)應(yīng)的空值也放入緩存中足画，只不過設(shè)定為較短的失效時(shí)間，例如幾分鐘佃牛，這樣則可以應(yīng)對(duì)短時(shí)間的大量的該 Key 攻擊淹辞，設(shè)置為較短的失效時(shí)間是因?yàn)樵撝悼赡軜I(yè)務(wù)無關(guān)，存在意義不大俘侠，且該次的查詢也未必是攻擊者發(fā)起象缀，無過久存儲(chǔ)的必要，故可以早點(diǎn)失效爷速。

2央星、緩存雪崩
在普通的緩存系統(tǒng)中一般例如 Redis 中，我們會(huì)給緩存設(shè)置一個(gè)失效時(shí)間惫东，但是如果所有的緩存的失效時(shí)間相同莉给，那么在同一時(shí)間失效時(shí)，所有系統(tǒng)的請(qǐng)求都會(huì)發(fā)送到數(shù)據(jù)庫(kù)層廉沮，db 可能無法承受如此大的壓力導(dǎo)致系統(tǒng)崩潰颓遏。

3、緩存擊穿
緩存擊穿實(shí)際上是緩存雪崩的一個(gè)特例滞时，大家使用過微博的應(yīng)該都知道叁幢，微博有一個(gè)熱門話題的功能，用戶對(duì)于熱門話題的搜索量往往在一些時(shí)刻會(huì)大大的高于其他話題坪稽，這種我們成為系統(tǒng)的“熱點(diǎn)“曼玩，由于系統(tǒng)中對(duì)這些熱點(diǎn)的數(shù)據(jù)緩存也存在失效時(shí)間鳞骤，在熱點(diǎn)的緩存到達(dá)失效時(shí)間時(shí)，此時(shí)可能依然會(huì)有大量的請(qǐng)求到達(dá)系統(tǒng)黍判，沒有了緩存層的保護(hù)弟孟，這些請(qǐng)求同樣的會(huì)到達(dá) DB 從而可能引起故障。

擊穿與雪崩的區(qū)別即在于擊穿是對(duì)于特定的熱點(diǎn)數(shù)據(jù)來說样悟，而雪崩是全部數(shù)據(jù)拂募。

六、引入消息中間件

你以為到緩存層面就結(jié)束了窟她？NO~~~

上一步的緩存集群只是解決了讀的問題陈症，其實(shí)寫的壓力還是很大，這個(gè)時(shí)候就要引入消息中間鍵了震糖，像各種 MQ 之類的東西录肯。是非常好的做寫請(qǐng)求異步化處理，實(shí)現(xiàn)削峰填谷的效果吊说，還有就是應(yīng)用解耦论咏。

假如說，你現(xiàn)在每秒是 1000/s 次寫請(qǐng)求颁井，其中比如 500 次請(qǐng)求是必須請(qǐng)求過來立馬寫入數(shù)據(jù)庫(kù)中的厅贪，但是另外 500 次寫請(qǐng)求是可以允許異步化等待個(gè)幾十秒，甚至幾分鐘后才落入數(shù)據(jù)庫(kù)內(nèi)的雅宾。

那么此時(shí)完全可以引入消息中間件集群养涮，把允許異步化的每秒 500 次請(qǐng)求寫入 MQ，然后基于 MQ 做一個(gè)削峰填谷眉抬。比如就以平穩(wěn)的 100/s 的速度消費(fèi)出來然后落入數(shù)據(jù)庫(kù)中即可贯吓，此時(shí)就會(huì)大幅度降低數(shù)據(jù)庫(kù)的寫入壓力。

引入 MQ

消息中間件系統(tǒng)本身也是為高并發(fā)而生蜀变，所以通常單機(jī)都是支撐幾萬甚至十萬級(jí)的并發(fā)請(qǐng)求的悄谐。所以，他本身也跟緩存系統(tǒng)一樣库北，可以用很少的資源支撐很高的并發(fā)請(qǐng)求爬舰，用他來支撐部分允許異步化的高并發(fā)寫入是沒問題的，比使用數(shù)據(jù)庫(kù)直接支撐那部分高并發(fā)請(qǐng)求要減少很多的機(jī)器使用量贤惯。

既然說到了 MQ洼专，那么面試時(shí)很有可能就會(huì)問：如何保證消息隊(duì)列的高可用？

要是你傻乎乎的就用了一個(gè) MQ孵构，各種問題從來沒考慮過屁商，那你就杯具了，面試官對(duì)你的感覺就是，只會(huì)簡(jiǎn)單使用一些技術(shù)蜡镶，沒任何思考雾袱，馬上對(duì)你的印象就不太好了。

解決辦法：

1官还、開啟 MQ 的持久化
消息寫入之后會(huì)持久化到磁盤芹橡，哪怕是 MQ 自己掛了，恢復(fù)之后會(huì)自動(dòng)讀取之前存儲(chǔ)的數(shù)據(jù)望伦，一般數(shù)據(jù)不會(huì)丟林说。

2、普通集群模式
在多臺(tái)機(jī)器上啟動(dòng)多個(gè) MQ 實(shí)例屯伞，每個(gè)機(jī)器啟動(dòng)一個(gè)腿箩。你創(chuàng)建的 queue，只會(huì)放在一個(gè) MQ 實(shí)例上劣摇。消費(fèi)的時(shí)候珠移，實(shí)際上如果連接到了另外一個(gè)實(shí)例，那么那個(gè)實(shí)例會(huì)從 queue 所在實(shí)例上拉取數(shù)據(jù)過來末融。

普通集群模式

這種方式確實(shí)很麻煩钧惧，也不怎么好，沒做到所謂的分布式勾习，就是個(gè)普通集群浓瞪。因?yàn)檫@導(dǎo)致你要么消費(fèi)者每次隨機(jī)連接一個(gè)實(shí)例然后拉取數(shù)據(jù)，要么固定連接那個(gè) queue 所在實(shí)例消費(fèi)數(shù)據(jù)语卤，前者有數(shù)據(jù)拉取的開銷追逮，后者導(dǎo)致單實(shí)例性能瓶頸。

而且如果那個(gè)放 queue 的實(shí)例宕機(jī)了粹舵，會(huì)導(dǎo)致接下來其他實(shí)例就無法從那個(gè)實(shí)例拉取，如果你開啟了消息持久化骂倘，讓 RabbitMQ 落地存儲(chǔ)消息的話眼滤，消息不一定會(huì)丟，得等這個(gè)實(shí)例恢復(fù)了历涝，然后才可以繼續(xù)從這個(gè) queue 拉取數(shù)據(jù)诅需。

所以這個(gè)事兒就比較尷尬了，這就沒有什么所謂的高可用性荧库，這方案主要是提高吞吐量的堰塌，就是說讓集群中多個(gè)節(jié)點(diǎn)來服務(wù)某個(gè) queue 的讀寫操作。

3分衫、鏡像集群模式
這種模式场刑，才是所謂的 RabbitMQ 的高可用模式。跟普通集群模式不一樣的是蚪战，在鏡像集群模式下牵现，你創(chuàng)建的 queue铐懊，無論元數(shù)據(jù)還是 queue 里的消息都會(huì)存在于多個(gè)實(shí)例上，就是說瞎疼，每個(gè) RabbitMQ 節(jié)點(diǎn)都有這個(gè) queue 的一個(gè)完整鏡像科乎，包含 queue 的全部數(shù)據(jù)的意思掰伸。然后每次你寫消息到 queue 的時(shí)候苞尝，都會(huì)自動(dòng)把消息同步到多個(gè)實(shí)例的 queue 上路召。

鏡像集群模式

這樣的話蹬敲，好處在于赌髓，你任何一個(gè)機(jī)器宕機(jī)了矩父，沒事兒劳坑，其它機(jī)器（節(jié)點(diǎn)）還包含了這個(gè) queue 的完整數(shù)據(jù)言津，別的 consumer 都可以到其它節(jié)點(diǎn)上去消費(fèi)數(shù)據(jù)腻异。壞處在于进副，第一，這個(gè)性能開銷也太大了吧悔常，消息需要同步到所有機(jī)器上影斑，導(dǎo)致網(wǎng)絡(luò)帶寬壓力和消耗很重！第二机打，這么玩兒矫户，不是分布式的，就沒有擴(kuò)展性可言了残邀，如果某個(gè) queue 負(fù)載很重皆辽，你加機(jī)器，新增的機(jī)器也包含了這個(gè) queue 的所有數(shù)據(jù)芥挣，并沒有辦法線性擴(kuò)展你的 queue驱闷。

4、消費(fèi)端弄丟了數(shù)據(jù)
這個(gè)時(shí)候得用 RabbitMQ 提供的 ack 機(jī)制空免，簡(jiǎn)單來說空另，就是你必須關(guān)閉 RabbitMQ 的自動(dòng) ack，可以通過一個(gè) api 來調(diào)用就行蹋砚，然后每次你自己代碼里確保處理完的時(shí)候扼菠，再在程序里 ack。

七坝咐、總結(jié)

到目前為止循榆，通過這些的手段，我們已經(jīng)可以讓系統(tǒng)架構(gòu)盡可能用最小的機(jī)器資源抗住了最大的請(qǐng)求壓力墨坚，減輕了數(shù)據(jù)庫(kù)的負(fù)擔(dān)秧饮。總結(jié)起來就是下面幾點(diǎn)：

1. Nginx 系統(tǒng)集群化；
2. 數(shù)據(jù)庫(kù)層面：分庫(kù)分表 + 讀寫分離浦楣；
3. 針對(duì)讀多寫少的請(qǐng)求袖肥，引入緩存集群；
4. 針對(duì)高寫入的壓力振劳，引入消息中間件集群椎组。

八、彩蛋

在上述的第一步 Nginx 系統(tǒng)集群化部署中历恐，如果訪問量繼續(xù)增大 Nginx
扛不住了寸癌，咋整？

在這種架構(gòu)中 Nginx 特別重要弱贼，是整個(gè)系統(tǒng)的入口蒸苇，一旦 Nginx 掛了，即使后面的整個(gè)系統(tǒng)都正常吮旅，也無法對(duì)外提供服務(wù)了溪烤。

這里就要用 keepalived 了，用兩臺(tái) Nginx 組成一個(gè)集群庇勃，分別部署上keepalived檬嘀，設(shè)置成相同的虛擬 IP，這樣一個(gè)節(jié)點(diǎn)在崩潰的情況下责嚷，另一個(gè)節(jié)點(diǎn)能夠自動(dòng)接替其工作鸳兽。

另外還可以配置 DNS，以DNS輪詢方式進(jìn)行負(fù)載均衡罕拂。

參考：
http://www.reibang.com/p/2f441c373d9e
https://mp.weixin.qq.com/s/YmlcrHH1NeE_vWqDGSayVQ