先說一下本人使用RocketMQ的背景吧。近期公司在做一個車輛調度的項目，需要使用消息隊列。由於目前公司內部已經搭建了RocketMQ的集羣服務，運維那邊建議利用現有的RocketMQ集羣來做，只需要建幾個Topic就能使用了。因此，在當前幾個流行的消息隊列中，比方說RabbitMQ、RocketMQ、ActiveMQ、Kafka等，選擇了RocketMQ。對，爲什麼選擇RocketMQ，原因就是這麼簡單，運維省事啊！並沒有什麼大家想象的開會來討論下性能、場景什麼的。
既然要用RocketMQ，那就用唄。
其實之前，我對RocketMQ瞭解並不多，如果說對某個消息隊列更熟悉一點，可能還是RabbitMQ，因爲RabbitMQ在大學裏面就學習過，搭建環境啊，寫寫demo啊，更熟練些（雖然長時間不用也忘的差不多了......）。
不過這些都不重要，重要的是技術人員都有一顆學習的心啊！不懂就學啊，然後，就學以致用啊！
這篇文章不會介紹什麼知識性東西，僅僅作爲RocketMQ的一個入門介紹，知道他是什麼，幹什麼的，爲什麼要用這個東西。
一、RocketMQ的前世今生
RocketMQ出自阿里巴巴，用 Java 語言實現，在設計時參考了 Kafka，並做出了自己的一些改進，消息可靠性上比 Kafka 更好。比起Kafka的Scala語言和RabbitMQ的Erlang語言，更容易找到技術人員進行定製開發。
阿里的消息中間件有很長的歷史，從2007年的Notify到2010年的Napoli，2011年升級爲MetaQ，然後到2012年開始做RocketMQ，2016年，阿里巴巴將RocketMQ捐贈給Apache基金會，並於2017年9月成爲Apache基金會的頂級項目。第一代的Notify主要使用了推模型，解決了事務消息；第二代的MetaQ主要使用了拉模型，解決了順序消息和海量堆積的問題。RocketMQ基於長輪詢的拉取方式，兼有兩者的優點。
在阿里內部，RocketMQ很好地服務了集團大大小小上千個應用，在每年的雙十一當天，更有不可思議的萬億級消息通過RocketMQ流轉（在2017年的雙十一當天，整個阿里巴巴集團通過RocketMQ流轉的線上消息達到了萬億級，峯值TPS達到5600萬），在阿里大中臺策略中發揮着舉足輕重的作用。
二、什麼是消息隊列
學過數據結構我們都知道，“隊列”是一種先進先出的數據結構。
簡單來說，消息隊列就是基礎數據結構課程裏“先進先出”的數據結構。但是如果要消除單點故障，保證消息傳輸的可靠性，並且還能應對大流量的衝擊，對消息隊列的要求就很高了。
三、爲什麼要使用消息隊列
現在互聯網“微架構”模式興起，原有大型集中式的IT服務因爲各種弊端，通常被分拆成細粒度的多個“微服務”，這些微服務可以在一個局域網內，也可能跨機房部署。一方面對服務之間松耦合的要求越來越高，另一方面，服務之間的聯繫卻越來越緊密，對通信質量要求也越來越高，分佈式消息隊列可以提供應用解耦、流量消峯、消息分發等功能，已經成爲大型互聯網服務架構裏標配的中間件。
1、應用解耦
複雜的應用會存在多個子系統，比如在電商應用中有訂單系統、庫存系統、物流系統、支付系統等。這個時候如果各個子系統之間的耦合性太高，整體系統的可用性就會大幅降低。多個低錯誤率的子系統強耦合在一起，得到的是一個高錯誤率的整體系統。
以電商應用爲例，用戶創建訂單後，如果耦合調用庫存系統、物流系統、支付系統，任何一個子系統出了故障或者因爲升級等原因暫時不可用，都會造成下單操作異常，影響用戶使用體驗。
轉變成基於消息隊列的方式後，系統可用性就高多了，比如物流系統因爲發生故障，需要幾分鐘的時間來修復，在這幾分鐘的時間裏，物流系統要處理的內容被緩存在消息隊列裏，用戶的下單操作可以正常完成。
當物流系統恢復後，補充處理存儲在消息隊列裏的訂單信息即可，終端用戶感知不到物流系統發生過幾分鐘的故障。
2、流量削峯
仍然以電商系統爲例，每年的淘寶雙十一、京東618等，各大電商網站的活動都在0點準時開啓，應用系統的流量會瞬間猛增，這個時候如果沒有緩衝機制，不可能承受住短時大流量的衝擊。通過利用消息隊列，把大量的請求暫存起來，分散到相對長的一段時間內處理，能大大提高系統的穩定性和用戶體驗 。
舉個例子，如果訂單系統每秒最多能處理一萬次下單，這個處理能力應對正常時段的下單是綽綽有餘的，正常時段我們下單後一秒內就能返回結果。在購物節0點的時候，如果沒有消息隊列這種緩衝機制，爲了保證系統穩定，只能在訂單超過1萬次後就不允許用戶下單了；如果有消息隊列做緩衝，我們可以取消這個限制，把一秒內下的訂單分散成一段時間來處理，這時有些用戶可能在十幾秒才能收到下單成功的狀態，但是也比不能下單的狀態要好。
使用消息隊列進行流量消峯，很多時候不是因爲能力不夠，而是出於經濟性的考量。比如有的業務系統，流量最高峯也不會超過一萬QPS，而平時只有一千左右的QPS，這種情況下我們就可以用個普通性能的服務器（只支持一千左右的 QPS 就可以），然後加個消息隊列作爲高峯期的緩衝，無須花大筆資金部署能處理上萬 QPS 的服務器。
3、消息分發
在大數據時代，數據對很多公司來說就像金礦，公司需要依賴對數據的分析，進行用戶畫像 、精準推送、流程優化等各種操作，並且對處理的實時性要求越來越高。數據是不斷產生的，各個分析團隊、算法團隊都要依賴這些數據來進行工作，這個時候有個可持久化的消息隊列就非常重要。數據的產生方只需要把各自的數據寫人一個消息隊列即可，數據使用方根據各自需求訂閱感興趣的數據，不同數據團隊所訂閱的數據可以重複也可以不重複，互不干擾，也不必和數據產生方關聯。
除了應用解耦、流量消峯、消息分發等功能外，消息隊列還有保證最終一致性、方便動態擴容等功能。