消息中间件

消息中间件

一、什么是MQ?

MQ全称为Message Queue, 消息队列（MQ）是应用程序“对”应用程序的通信方法。从字面意思上看，本质是个队列，FIFO(First Input First Output)先入先出，只不过队列中存放的内容是message而已

• 其主要用途：不同进程Process/线程Thread之间通信.

为什么会产生消息队列？有几个原因：

• 不同进程（process）之间传递消息时，两个进程之间耦合程度过高，改动一个进程，引发必须修改另一个进程，为了隔离这两个进程，在两进程间抽离出一层（一个模块），所有两进程之间传递的消息，都必须通过消息队列来传递，单独修改某一个进程，不会影响另一个；

• 不同进程（process）之间传递消息时，为了实现标准化，将消息的格式规范化了，并且，某一个进程接受的消息太多，一下子无法处理完，并且也有先后顺序，必须对收到的消息进行排队，因此诞生了事实上的消息队列;

目前MQ具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能，成为异步RPC的主要手段之一。

二、MQ特点

1、先进先出

不能先进先出，都不能说是队列了。消息队列的顺序在入队的时候就基本已经确定了，一般是不需人工干预的。而且，最重要的是，数据是只有一条数据在使用中。这也是MQ在诸多场景被使用的原因。

2、发布订阅

发布订阅是一种很高效的处理方式，如果不发生阻塞，基本可以当做是同步操作。这种处理方式能非常有效的提升服务器利用率，这样的应用场景非常广泛。

3、持久化

持久化确保MQ的使用不只是一个部分场景的辅助工具，而是让MQ能像数据库一样存储核心的数据。

4、分布式

在现在大流量、大数据的使用场景下，只支持单体应用的服务器软件基本是无法使用的，支持分布式的部署，才能被广泛使用。而且，MQ的定位就是一个高性能的中间件。

三、消息中间件的组成

• broker:消息服务器，做为server提供消息核心服务
• producer:消息生产者，业务的发起方，负责产生消息并发送给broker
• consumer:消息消费者，业务的处理方，负责接从broker获取消息，并且即时进行业务逻辑处理
• Topic：主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的广播。
• Queue：队列。基本上，一个队列就是一个先入先出（FIFO）的数据结构,PTP(Point-to-Point)模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收。
• Message：消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输

四、消息中间件模式分类

• 点对点
  点对点:使用queue作为通信载体

消息生产者producer生产消息发送到queue中，然后消息消费者consumer从queue中取出并且消费消息。消息被消费以后，queue中将不再存储消息，所以消息消费者不可能消费到已经被消费的消息。 Queue支持同时存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

queue实现了负载均衡，将producer生产的消息发送到消息队列中，由多个消费者消费。但一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者。

• 发布/订阅
  Pub/Sub发布订阅（广播）：使用topic作为通信载体
  
  消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

topic实现了发布和订阅，当你发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到一个消息的拷贝。

五、消息中间件应用场景

• 异步通信
  有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。就比如你坐地铁，用支付宝扫码支付成功后，通知消息并不是需要立即知道的。还比如银行转账短信通知，也不是必须立马知道的，这些都是异步通信。
• 冗余
  有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
• 解耦
  降低了各工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
• 扩展性
  消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。
• 过载保护
  在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提取预知；如果仅为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑会浪费巨大的资源。但使用消息队列就能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
• 可恢复性
  系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
• 顺序保证
  在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。
• 缓冲
  在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。
• 数据流处理
  分布式系统产生的海量数据流，如：业务日志、监控数据、用户行为等，针对这些数据流进行实时或批量采集汇总，然后进行大数据分析是当前互联网的必备技术，通过消息队列完成此类数据收集是最好的选择。

六、主要消息中间件的比较

                （图片来源与网络）