案例
有一天，產品跑來說：“我們要做一個用戶注冊功能，需要在用戶注冊成功后給用戶發一封成功郵件，”
小明（攻城獅）：“好，需求很明確了，” 不就提供一個注冊介面，保存用戶資訊，同時發起郵件呼叫，待郵件發送成功后，回傳用戶操作成功，沒一會功夫，代碼就寫完了，驗證功能沒問題后，就發布上線了，
線上正常運行了一段時間，產品匆匆地跑來說：“你做的功能不行啊，運營反饋注冊操作回應太慢，已經有好多用戶流失了，”
小明聽得一身冷汗，趕緊回去改，他發現，原先的以單執行緒同步阻塞的方式進行郵件發送，確實存在問題，這次，他利用了 JAVA 多執行緒的特性，另起執行緒進行郵件發送，主執行緒直接回傳保存結果，測驗通過后，趕緊發布上線，小明心想，這下總沒問題了吧，
沒過多久，產品又跑來了，他說：“現在，注冊操作回應是快多了，但是又有新的問題了，有用戶反應，郵件收不到，能否在發送郵件時，保存一下發送的結果，對于發送失敗的，進行補發，”
小明一聽，哎，又得熬夜加班了，產品看他一臉苦逼的樣子，忙說：“郵件服務這塊，別的團隊都已經做好了，你不用再自己搞了，直接用他們的服務，”
小明趕緊去和郵件團隊溝通，誰知他們的服務根本就不對外開放，這下小明可開始犯愁了，明知道有這么一個服務，可是偏偏又呼叫不了，
郵件團隊的人說，“看你愁的，我給你提供了一個類似郵局信箱的東西，你往這信箱里寫上你要發送的訊息，以及我們約定的地址，之后你就不用再操心了，我們自然能從約定的地址中取得訊息，進行郵件的相應操作，”
后來，小明才知道，這就是外界廣為流傳的訊息佇列，你不用知道具體的服務在哪，如何呼叫，你要做的只是將該發送的訊息，向你們約定好的地址進行發送，你的任務就完成了，對應的服務自然能監聽到你發送的訊息，進行后續的操作，這就是訊息佇列最大的特點，將同步操作轉為異步處理，將多服務共同操作轉為職責單一的單服務操作，做到了服務間的解耦，
哈哈，這下能高枕無憂了，太年輕，哪有萬無一失的技術啊~
不久的一天，你會發現所有業務都替換了郵件發送的方式，統一使用了訊息佇列來進行發送，這下僅僅一個郵件服務模塊，難以承受業務方源源不斷的訊息，大量的訊息堆積在了佇列中，這就需要更多的消費者（郵件服務）來共同處理佇列中的訊息，即所謂的分布式訊息處理，
總結
定義
有了上面的基礎，再看非常官方的解釋應該也能理解了，
訊息佇列（英語：Message queue）是一種行程間通信或同一行程的不同執行緒間的通信方式，軟體的貯列用來處理一系列的輸入，通常是來自用戶，訊息佇列提供了異步的通信協議，每一個貯列中的紀錄包含詳細說明的資料，包含發生的時間，輸入設備的種類，以及特定的輸入引數，也就是說：訊息的發送者和接收者不需要同時與訊息佇列互交，訊息會保存在佇列中，直到接收者取回它， ——維基百科
名詞解釋
解釋還是太官方了，我們來看一個最簡單的架構模型：
- Producer：訊息生產者，負責產生和發送訊息到 Broker；
- Broker：訊息處理中心，負責訊息存盤、確認、重試等，一般其中會包含多個 queue；
- Consumer：訊息消費者，負責從 Broker 中獲取訊息，并進行相應處理；
特性
異步性
將耗時的同步操作，通過以發送訊息的方式，進行了異步化處理，減少了同步等待的時間，
松耦合
訊息佇列減少了服務之間的耦合性，不同的服務可以通過訊息佇列進行通信，而不用關心彼此的實作細節，只要定義好訊息的格式就行，
分布式
通過對消費者的橫向擴展，降低了訊息佇列阻塞的風險，以及單個消費者產生單點故障的可能性（當然訊息佇列本身也可以做成分布式集群），
可靠性
訊息佇列一般會把接收到的訊息存盤到本地硬碟上（當訊息被處理完之后，存盤資訊根據不同的訊息佇列實作，有可能將其洗掉），這樣即使應用掛掉或者訊息佇列本身掛掉，訊息也能夠重新加載，
來源：https://github.com/jasonGeng88/blog/
近期熱文推薦：
1.Java 15 正式發布， 14 個新特性，重繪你的認知！！
2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
3.我用 Java 8 寫了一段邏輯，同事直呼看不懂，你試試看，，
4.吊打 Tomcat ，Undertow 性能很炸！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/237894.html
標籤：其他