消息中间件的产生主要是为了达到以下目的：
- 异步
- 解耦
- 最终一致性
- 并行
下面我们来看针对同一件事情，不同的处理办法：
过年了拜年发微信：
- 普通青年：编辑微信，群发给所有人。
- 文艺青年：编辑微信，交给美腻秘书发送，自己已去......
- 二笔青年：编辑微信，发送；编辑微信，发送；编辑微信，发送；..........
我们现在主要关注第二种场景，它的使用方式实现了解耦操作和异步操作。
- 举一个淘宝的简单例子：
一笔交易的完成涉及到很多系统协调操作的过程，如上多个系统，但如果只是串行的执行这些操作，可能还没执行完这些操作，用户可能已没有耐心，离开了操作界面。给用户留下不好的用户体验。
- 现在消息中间件就派上了用场：
（以下截图都取自阿里沈询消息中间件ONS讲解）
消息中间件具有减少延迟，提升用户体验（异步解耦）
最终一致性：如果由于消息中间件消费端的一个模块 crash 了，而出现的短暂不一致现象，而该模块恢复以后会重新完成它的操作，最终保证数据操作的一致性，我们可以使用消息中间件来保证最终状态的统一。
并行：因为消息时并行发送到各个消息队列的，也是并行的被各个系统进行处理的，系统的高效可以由此得到保证。
ONS的设计思路：
消息中间件的难点主要是在于权衡和取舍。
- 设计假定：
- 每台PC机器都可能down机不可服务
- 任意集群都可能处理能力不足
- 最坏的情况一定会发生
- 内网环境要低延迟来提供最佳用户体验
- 关键设计：
- 分布式集群化
- 强数据安全
- 海量数据堆积
- 毫秒级投递延迟
数据安全：交易物流等 数据不能丢失
使用队列多冗余的方式保证消息队列的高可用性。（包括数据的复制，服务器的切换等操作都是在消息队列后端来完成，对用户是不可见的）。
中间件设计保证：不管系统堆积了多少消息，系统本身的处理能力不能慢或不能挂。
- 消息投递的三种方式：
- 推
- 拉
- 推拉结合
Kafkia 面向的场景是：日志的分析，处理 及 统计功能，它主要更关注于日志拉取的吞吐量。而不太关注数据拉取的延迟，它采取的主要地消息投递模式是拉模型。
ONS采取的是推拉结合的模式（长轮询的模式）
推送策略：
队列中收到消息后会主动推送给订阅者，订阅者返回一个ack，这样的数据延迟会比较小，并且订阅者比较轻量，主需要关注接收和处理消息就可以了。
拉取策略：拉消息是订阅者定时向消息服务器拉取消息，这样消息服务器压力会比较大，并且延迟相对来说会比较大，拉消息模式关注的主要是吞吐量。
推拉结合：当队列中收到发布者发送的消息之后，会给消息订阅者一个通知，我这边收到消息了，然后订阅者会向消息中间件的服务器拉取消息。——缺点，拉取消息本身的交互次数会变得非常多。
另一种方案：消息的订阅者在主动拉取消息的同时，ONSServer 会 hold住你拉的请求，知道有消息以后会返回给你。以这种方式可以实现 以拉取的模式（策略）来实现非常及时的通讯。