一個故事告訴你什么是消息隊列，很形象…
Java技術(shù)棧
www.javastack.cn
關(guān)注閱讀更多優(yōu)質(zhì)文章
案例
有一天，產(chǎn)品跑來說：“我們要做一個用戶注冊功能，需要在用戶注冊成功后給用戶發(fā)一封成功郵件。”
小明（攻城獅）：“好，需求很明確了?！?不就提供一個注冊接口，保存用戶信息，同時發(fā)起郵件調(diào)用，待郵件發(fā)送成功后，返回用戶操作成功。沒一會功夫，代碼就寫完了。驗證功能沒問題后，就發(fā)布上線了。
線上正常運行了一段時間，產(chǎn)品匆匆地跑來說：“你做的功能不行啊，運營反饋注冊操作響應(yīng)太慢，已經(jīng)有好多用戶流失了。”
小明聽得一身冷汗，趕緊回去改。他發(fā)現(xiàn)，原先的以單線程同步阻塞的方式進行郵件發(fā)送，確實存在問題。這次，他利用了 JAVA 多線程的特性，另起線程進行郵件發(fā)送，主線程直接返回保存結(jié)果。測試通過后，趕緊發(fā)布上線。小明心想，這下總沒問題了吧。
沒過多久，產(chǎn)品又跑來了，他說：“現(xiàn)在，注冊操作響應(yīng)是快多了。但是又有新的問題了，有用戶反應(yīng)，郵件收不到。能否在發(fā)送郵件時，保存一下發(fā)送的結(jié)果，對于發(fā)送失敗的，進行補發(fā)?！?/p>
小明一聽，哎，又得熬夜加班了。產(chǎn)品看他一臉苦逼的樣子，忙說：“郵件服務(wù)這塊，別的團隊都已經(jīng)做好了，你不用再自己搞了，直接用他們的服務(wù)?！?/p>
小明趕緊去和郵件團隊溝通，誰知他們的服務(wù)根本就不對外開放。這下小明可開始犯愁了，明知道有這么一個服務(wù)，可是偏偏又調(diào)用不了。
郵件團隊的人說，“看你愁的，我給你提供了一個類似郵局信箱的東西，你往這信箱里寫上你要發(fā)送的消息，以及我們約定的地址。之后你就不用再操心了，我們自然能從約定的地址中取得消息，進行郵件的相應(yīng)操作。”
后來，小明才知道，這就是外界廣為流傳的消息隊列。你不用知道具體的服務(wù)在哪，如何調(diào)用。你要做的只是將該發(fā)送的消息，向你們約定好的地址進行發(fā)送，你的任務(wù)就完成了。對應(yīng)的服務(wù)自然能監(jiān)聽到你發(fā)送的消息，進行后續(xù)的操作。這就是消息隊列最大的特點，將同步操作轉(zhuǎn)為異步處理，將多服務(wù)共同操作轉(zhuǎn)為職責單一的單服務(wù)操作，做到了服務(wù)間的解耦。
哈哈，這下能高枕無憂了。太年輕，哪有萬無一失的技術(shù)啊~
不久的一天，你會發(fā)現(xiàn)所有業(yè)務(wù)都替換了郵件發(fā)送的方式，統(tǒng)一使用了消息隊列來進行發(fā)送。這下僅僅一個郵件服務(wù)模塊，難以承受業(yè)務(wù)方源源不斷的消息，大量的消息堆積在了隊列中。這就需要更多的消費者（郵件服務(wù)）來共同處理隊列中的消息，即所謂的分布式消息處理。
總結(jié)
定義
有了上面的基礎(chǔ)，再看非常官方的解釋應(yīng)該也能理解了。關(guān)注公眾號Java技術(shù)棧可以獲取更多消息隊列實戰(zhàn)教程。
名詞解釋
解釋還是太官方了，我們來看一個最簡單的架構(gòu)模型：
Producer：消息生產(chǎn)者，負責產(chǎn)生和發(fā)送消息到 Broker； Broker：消息處理中心。負責消息存儲、確認、重試等，一般其中會包含多個 queue； Consumer：消息消費者，負責從 Broker 中獲取消息，并進行相應(yīng)處理；
特性
異步性
將耗時的同步操作，通過以發(fā)送消息的方式，進行了異步化處理。減少了同步等待的時間。
松耦合
消息隊列減少了服務(wù)之間的耦合性，不同的服務(wù)可以通過消息隊列進行通信，而不用關(guān)心彼此的實現(xiàn)細節(jié)，只要定義好消息的格式就行。
分布式
通過對消費者的橫向擴展，降低了消息隊列阻塞的風險，以及單個消費者產(chǎn)生單點故障的可能性（當然消息隊列本身也可以做成分布式集群）。
可靠性
消息隊列一般會把接收到的消息存儲到本地硬盤上（當消息被處理完之后，存儲信息根據(jù)不同的消息隊列實現(xiàn)，有可能將其刪除），這樣即使應(yīng)用掛掉或者消息隊列本身掛掉，消息也能夠重新加載。
來源：https://github.com/jasonGeng88/blog/
關(guān)注Java技術(shù)?？锤喔韶?/strong>
