勞動(dòng)節(jié)小長(zhǎng)假快到了，你打開(kāi)12306手機(jī)App，準(zhǔn)備買車票出去玩：
首先，輸入車票信息，起點(diǎn)站，終點(diǎn)站，出發(fā)時(shí)間，票數(shù)以及座席，發(fā)送訂票請(qǐng)求。然后，單擊“預(yù)訂”按鈕，12306 App界面開(kāi)始轉(zhuǎn)圈圈。與此同時(shí)全國(guó)大概3億人民也在和你一起做相同的事情。3s后，應(yīng)用告訴你訂票失敗。你修改車次，重新發(fā)送訂票請(qǐng)求。應(yīng)用重復(fù)第二步繼續(xù)等待。又一個(gè)3s后，12306 App告訴你訂票成功。
12306 App在處理以上邏輯時(shí)，會(huì)遇到以下挑戰(zhàn)：比如今天這個(gè)車次只售出4000張票，而實(shí)際有30萬(wàn)人發(fā)送了訂票信息，如果逐一請(qǐng)求處理，那么90%以上的人都將要耗時(shí)3s來(lái)等待，怎么辦？答案是：消息隊(duì)列！
業(yè)務(wù)系統(tǒng)在超高并發(fā)場(chǎng)景中，由于后端服務(wù)來(lái)不及同步處理過(guò)多、過(guò)快的請(qǐng)求，可能導(dǎo)致請(qǐng)求堵塞，嚴(yán)重時(shí)可能由于高負(fù)荷拖垮Web服務(wù)器。
實(shí)際的流量會(huì)隨著時(shí)間不短變化，像12306 App這樣的App流量大得難以想象，而一年中不同的時(shí)間段，其流量也不同。為了能支持最高峰流量，我們通常采取短平快的方式——直接擴(kuò)容服務(wù)器，增加服務(wù)端的吞吐量。
優(yōu)點(diǎn)是顯而易見(jiàn)的，短時(shí)間內(nèi)吞吐量增加了好幾倍，甚至數(shù)十倍。缺點(diǎn)也明顯，流量低峰期服務(wù)器相對(duì)較閑。
如何平衡平時(shí)的空閑與節(jié)假日的超高峰呢？我們想到了消息隊(duì)列（比如Apache RocketMQ，Apache Kafka），也是目前業(yè)界比較常用的手段。利用消息隊(duì)列扭轉(zhuǎn)處理訂票請(qǐng)求，告知用戶30min內(nèi)會(huì)告訴他/她訂票結(jié)果。
新網(wǎng)消息隊(duì)列RabbitMQ是一款支持持久化消息隊(duì)列的消息中間件。通過(guò)創(chuàng)建集群的方式來(lái)實(shí)現(xiàn)RabbitMQ以及所依賴的服務(wù)的部署，完全兼容RabbitMQ開(kāi)源生態(tài)以及多語(yǔ)言客戶端，為用戶提供快速創(chuàng)建、方便管理的消息中間件。
電商業(yè)務(wù)場(chǎng)景中經(jīng)常會(huì)有秒殺或者團(tuán)搶的活動(dòng)，此時(shí)會(huì)產(chǎn)生大量的請(qǐng)求涌入系統(tǒng)，如果直接打到服務(wù)器上可能超出服務(wù)的最大承載能力，導(dǎo)致系統(tǒng)癱瘓。引入RabbitMQ，先將請(qǐng)求寫在RabbitMQ中，后臺(tái)服務(wù)器從RabbitMQ中讀取請(qǐng)求處理，把巨大的壓力從后端服務(wù)器轉(zhuǎn)移到RabbitMQ上來(lái)保障業(yè)務(wù)正常運(yùn)行。
目前消息隊(duì)列已經(jīng)成為云原生時(shí)代企業(yè)上云的核心基礎(chǔ)設(shè)施！快快點(diǎn)擊進(jìn)行了解吧：http://www.xinnet.com/cs/rabbitmq.html