阿里消息中间件ONS的应用场景（一）

消息中间件的产生主要是为了达到如下目的：

1. 异步
2. 解耦
3. 最终一致性
4. 并行

 下面咱们来看针对同一件事情，不一样的处理办法：

过年了拜年发微信：

• 普通青年：编辑微信，群发给全部人。
• 文艺青年：编辑微信，交给美腻秘书发送，本身已去......
• 二笔青年：编辑微信，发送；编辑微信，发送；编辑微信，发送；..........

咱们如今主要关注第二种场景，它的使用方式实现了解耦操做和异步操做。

• 举一个淘宝的简单例子：

一笔交易的完成涉及到不少系统协调操做的过程，如上多个系统，但若是只是串行的执行这些操做，可能还没执行完这些操做，用户可能已没有耐心，离开了操做界面。给用户留下很差的用户体验。

• 如今消息中间件就派上了用场：

（如下截图都取自阿里沈询消息中间件ONS讲解）

消息中间件具备减小延迟，提高用户体验（异步解耦）

最终一致性：若是因为消息中间件消费端的一个模块 crash 了，而出现的短暂不一致现象，而该模块恢复之后会从新完成它的操做，最终保证数据操做的一致性，咱们可使用消息中间件来保证最终状态的统一。

并行：由于消息时并行发送到各个消息队列的，也是并行的被各个系统进行处理的，系统的高效能够由此获得保证。

ONS的设计思路：

消息中间件的难点主要是在于权衡和取舍。

• 设计假定：
  • 每台PC机器均可能down机不可服务
  • 任意集群均可能处理能力不足
  • 最坏的状况必定会发生
  • 内网环境要低延迟来提供最佳用户体验
• 关键设计：
  • 分布式集群化
  • 强数据安全
  • 海量数据堆积
  • 毫秒级投递延迟

数据安全：交易物流等 数据不能丢失

使用队列多冗余的方式保证消息队列的高可用性。（包括数据的复制，服务器的切换等操做都是在消息队列后端来完成，对用户是不可见的）。

中间件设计保证：无论系统堆积了多少消息，系统自己的处理能力不能慢或不能挂。

• 消息投递的三种方式：

1. 推
2. 拉
3. 推拉结合

Kafkia 面向的场景是：日志的分析，处理 及 统计功能，它主要更关注于日志拉取的吞吐量。而不太关注数据拉取的延迟，它采起的主要地消息投递模式是拉模型。

ONS采起的是推拉结合的模式（长轮询的模式）

推送策略：

队列中收到消息后会主动推送给订阅者，订阅者返回一个ack，这样的数据延迟会比较小，而且订阅者比较轻量，主须要关注接收和处理消息就能够了。

拉取策略：拉消息是订阅者定时向消息服务器拉取消息，这样消息服务器压力会比较大，而且延迟相对来讲会比较大，拉消息模式关注的主要是吞吐量。

推拉结合：当队列中收到发布者发送的消息以后，会给消息订阅者一个通知，我这边收到消息了，而后订阅者会向消息中间件的服务器拉取消息。——缺点，拉取消息自己的交互次数会变得很是多。

另外一种方案：消息的订阅者在主动拉取消息的同时，ONSServer 会 hold住你拉的请求，知道有消息之后会返回给你。以这种方式能够实现 以拉取的模式（策略）来实现很是及时的通信。