以开发的角度重新认知消息中间件——起源简介

一，消息

消息，message，对于开发来说，也是应用程序消费的数据，消息可以非常简单，文本字符串，JSON，XML等，也可以很复杂，比如内嵌对象，图片，视频等。

二，消息与消息中间件

对于消息中间件来说，消息本身的复杂程度被其屏蔽，消息队列中间件（Message Queue Middleware，简称MQ）利用高效可靠的消息传递机制进行平台无关的数据交流（有没有想到Java虚拟机），并基于数据通信来进行分布系统的集成（有没有想到Restful）。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信（有没有想到RPC哈哈）。
消息队列中间件，一般有两种传递模式：点对点模式（P2P，Point-to-Point）和发布/订阅模式（Pub/Sub）。

• 点对点模式

  消息发布者与订阅者需要协商好一个共同的队列，然后消息发布者发送消息到队列，消息消费者从队列接收消息，队列的存在使得消息可以异步传输。

• 发布/订阅模式

  发布订阅模式定义了主题的概念，主题可以认为是消息传递的中介，基于队列的消息传递机制又拔高了一层。消息发布者将消息发布到某个主题，而消息订阅者则从主题中订阅消息。主题使得消息的订阅者与消息的发布者互相保持独立，不需要进行接触或者协商即可保证消息的传递。

消息中间件提供了基于存储和转发应用程序之间的异步程序发送的机制，即应用程序彼此不直接通信，而是与作为中介的消息中间件通信。开发人员无需了解远程过程调用（RPC）和网络通信协议的细节，其本身就保证了消息的有效发送。

三，消息中间件的作用

• 解耦
  消息中间件在处理过程中间插入了一个隐含的，基于数据的接口层。生产者和消费者只需要面对数据接口编程即可，所以可以独立地扩展或修改两边的处理过程。
• 冗余
  消息中间件可以把数据进行持久化知道确认被完全处理了，这一方式可以规避数据丢失的风险（需要接收到一个明确的处理完成的信号）。
• 扩展
  因为消息中间件的解耦特性，所以只需要提高消息入队和处理的效率即可（与代码解耦，无需调节参数）。
• 削峰
  以突发流量的峰值来投入资源太过浪费，使用消息中间件能够使关键组件支撑突发访问压力，不会因突发的超负荷请求而完全崩溃（双十一每年也就几天，如果每天的机器配置都以这个为标准的话，地主家也没余粮啊）。
• 可恢复
  同样是因为解耦，当系统一部分组件失效时，不会影响到整个系统，加入到消息中间件的消息仍然在系统恢复后继续处理。
• 顺序保证
  在大多数使用场景下，数据处理的顺序很重要（可以参考秒杀系统）。
• 缓冲
  在任何重要的系统中，都会存在需要不同处理时间的元素（查看订单详情的优先级跟付款的优先级能一样吗？）。消息中间件通过一个缓冲层来控制和优化数据流经过系统的速度。
• 异步通信
  有些消息不需要同步处理，在需要的时候再慢慢处理（很多日志系统都实现了此功能
  ）。

四，常见的消息中间件

1. RabbitMQ
2. ActiveMQ
3. Kafka
4. RocketMQ