歡迎轉載，轉載請注明出處：http://www.cnblogs.com/lidabnu/p/5723280.html
消息中間件已經流行很長時間，一般情況下，不需要自己來從頭研發、設計消息中間件，所以基礎知識的目的是了解消息中間件解決什么問題、如何評估衡量消息中間件，以及掌握基本的相關術語。
專業術語
- 消息：一種需要跨系統傳遞的數據結構
- 生產者：產生消息的系統
- 消費者：消費消息的系統
- Broker：消息中轉角色，負責消息的存儲和轉發，JMS規范中叫做Provider
應用場景
總結了一下，消息中間件用於解耦生產者與消費者，現在的理解，主要是降低生產者對消費者的“了解程度或要求程度”，具體來看：
- 生產者不知道也不關心消費者是誰，不知道也不關心消費者是不是可能減少或者增多——我都不知道你是誰
- 生產者知道消費者都有誰，但是消費者的技術實現方式完全不同：例如異構系統的集成——我知道你是誰，但是我對你怎么實現沒啥要求
- 生產者與消費者的系統質量屬性要求不同或已支持的質量屬性程度不同：——我知道你是誰，但是我對你實現的好壞沒啥要求
- 響應時間的要求不同：例如訂單提交操作，生產者需要及時的響應最終用戶，而訂單的處理可以有相對較長的延時。
- 可用性的不同：例如與某個外部系統集成，該外部系統的可用性相對不高，則可使用消息中間件來屏蔽此種不同。
消息中間件本身實現要解決的問題
從上面的應用場景來看，消息中間件需要解決以下問題，或者說要具備以下特性
- 我不知道你是誰：支持發布-訂閱模式，即支持動態的擴展和縮小消息消費者的范圍
- 我知道你是誰，我對你怎么實現沒啥要求：與消費者、生產者的通信方式平台無關，提供多種技術的接入支持
- 我知道你是誰，我對你實現的好壞沒啥要求：
- 具備足夠的消息堆積能力：對應於消費者掛了
- 對消息“至少消費一次”的保證：對應於消費者拿走一條消息后還沒消費完就掛了
除上述要求外，還有一些通用的質量屬性要求：
- 高性能
- 性能可伸縮
- 可靠性：主要指消息的可靠性，各種情況下不應丟消息
- 高可用：自身不能隨便宕機
- 易用性/可維護性：
- API易用
- 部署容易
- 運維管理容易：便於與已有監控系統集成；便於細粒度管理消息中間件中的各種消息
以及一些異步化（消息中間件實質上是一種同步變異步）后所要解決的問題：
- 消息順序性保證：先生產的消息需要先消費，某些場景下是必須的
最后，上個學習過程中的腦圖：
