欢迎转载，转载请注明出处：http://www.cnblogs.com/lidabnu/p/5723280.html
消息中间件已经流行很长时间，一般情况下，不需要自己来从头研发、设计消息中间件，所以基础知识的目的是了解消息中间件解决什么问题、如何评估衡量消息中间件，以及掌握基本的相关术语。
专业术语
- 消息：一种需要跨系统传递的数据结构
- 生产者：产生消息的系统
- 消费者：消费消息的系统
- Broker：消息中转角色，负责消息的存储和转发，JMS规范中叫做Provider
应用场景
总结了一下，消息中间件用于解耦生产者与消费者，现在的理解，主要是降低生产者对消费者的“了解程度或要求程度”，具体来看：
- 生产者不知道也不关心消费者是谁，不知道也不关心消费者是不是可能减少或者增多——我都不知道你是谁
- 生产者知道消费者都有谁，但是消费者的技术实现方式完全不同：例如异构系统的集成——我知道你是谁，但是我对你怎么实现没啥要求
- 生产者与消费者的系统质量属性要求不同或已支持的质量属性程度不同：——我知道你是谁，但是我对你实现的好坏没啥要求
- 响应时间的要求不同：例如订单提交操作，生产者需要及时的响应最终用户，而订单的处理可以有相对较长的延时。
- 可用性的不同：例如与某个外部系统集成，该外部系统的可用性相对不高，则可使用消息中间件来屏蔽此种不同。
消息中间件本身实现要解决的问题
从上面的应用场景来看，消息中间件需要解决以下问题，或者说要具备以下特性
- 我不知道你是谁：支持发布-订阅模式，即支持动态的扩展和缩小消息消费者的范围
- 我知道你是谁，我对你怎么实现没啥要求：与消费者、生产者的通信方式平台无关，提供多种技术的接入支持
- 我知道你是谁，我对你实现的好坏没啥要求：
- 具备足够的消息堆积能力：对应于消费者挂了
- 对消息“至少消费一次”的保证：对应于消费者拿走一条消息后还没消费完就挂了
除上述要求外，还有一些通用的质量属性要求：
- 高性能
- 性能可伸缩
- 可靠性：主要指消息的可靠性，各种情况下不应丢消息
- 高可用：自身不能随便宕机
- 易用性/可维护性：
- API易用
- 部署容易
- 运维管理容易：便于与已有监控系统集成；便于细粒度管理消息中间件中的各种消息
以及一些异步化（消息中间件实质上是一种同步变异步）后所要解决的问题：
- 消息顺序性保证：先生产的消息需要先消费，某些场景下是必须的
最后，上个学习过程中的脑图：
