節假日出行背后，藏著消息隊列的用法

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