消息中间件

消息中间件

要想完成一次任务，简单来讲，就分为两大块，任务的发送（在下图中即A系统）、任务的执行（在下图中即B系统）；这就是我要表达的第一张图的内容；

因为A系统和B系统并不在一起，因而在任务的发送和任务下达到某台机器上进行转码之间，那么下发这个转码任务就需要一个桥梁，即所需要的的“消息中间件”；而所谓的“消息中间件”，则是基于队列与消息传递技术，在网络环境中为应用系统提供同步或异步、可靠的消息传输的支撑性软件系统，简称为MQ（消息中间件则是将软件与软件之间的交互方式进行存储和管理的一种技术,也可以看做是一种容器）；目前市场上开源的消息中间件有很多：如Kafka、RabbitMQ、RocketMQ等等。

我们来说说什么是消息队列（Message queue，简称MQ）

消息队列是消息中间件的一种实现方式，从字面理解就是一个保存消息的一个容器。那么我们为何需要这样一个容器呢？其实就是为了解耦各个系统，我们来举个例子：

有这么一个简单的场景，系统A负责生成userID，并调用系统B、C。如果系统BC频繁变化是否需要userID参数，则系统A的代码就得不断变化，如果哪天又来了系统DEF……也需要这个参数，则系统A又要加入很多业务逻辑，这样子各他系统之间就容易产生相互影响，另外大量的系统与A发生交互也容易产生问题。

加了消息队列后，A只负责产生userID，至于谁要用这个参数，怎么用？系统A不管。对这个数据感兴趣的系统自己去取用即可，各个系统之间就实现了解耦。而且解耦后，整个服务业变成了一个异步的方式，系统A产生数据后，不用依次调用BCD来累计耗时，各系统可以同时来取用消息队列的数据进行处理，加大吞吐。

目前使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ等 ；

消息队列的特点（略）
1、先进先出：消息队列的顺序在入队的时候就基本已经确定了，一般是不需人工干预的。
2、发布订阅：发布订阅是一种很高效的处理方式，如果不发生阻塞，基本可以当成是同步操作。
3、持久化：持久化确保消息队列的使用不只是一个部分场景的辅助工具，而是让消息队列能像数据库一样存储核心的数据。
4、分布式：在现在大流量、大数据的使用场景下，支持分布式的部署，才能被广泛使用。消息队列的定位就是一个高性能的中间件。

消息中间件的组成

Broker：消息服务器，作为server提供消息核心服务
Producer：消息生产者，业务的发起方，负责生产消息传输给broker，
Consumer：消息消费者，业务的处理方，负责从broker获取消息并进行业务逻辑处理
Topic：主题，发布订阅模式下的消息统一汇集地，不同生产者向topic发送消息，由MQ服务器分发到不同的订阅者，实现消息的 广播
Queue：队列，PTP模式下，特定生产者向特定queue发送消息，消费者订阅特定的queue完成指定消息的接收
Message：消息体，根据不同通信协议定义的固定格式进行编码的数据包，来封装业务数据，实现消息的传输

消息中间件模式分类

点对点：PTP点对点:使用queue作为通信载体
说明：
消息生产者生产消息发送到queue中，然后消息消费者从queue中取出并且消费消息。
消息被消费以后，queue中不再存储，所以消息消费者不可能消费到已经被消费的消息。 Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。

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

queue实现了负载均衡，将producer生产的消息发送到消息队列中，由多个消费者消费。但一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者。
topic实现了发布和订阅，当你发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到一个消息的拷贝。

而现在我们的测试环境使用的是ActivateMQ和RedisMQ两种，下面来看下这两个MQ：

什么是ActiveMQ

ActiveMQ是由Apache出品的一款开源消息中间件，旨在为应用程序提供高效、可扩展、稳定、安全的企业级消息通信。
ActiveMQ是一种开源的基于JMS（Java Message Servie）规范的一种消息中间件的实现，ActiveMQ的设计目标是提供标准的，面向消息的，能够跨越多语言和多系统的应用集成消息通信中间件。所以，ActivateMQ本质还是一个消息中间件。

什么时候需要用ActiveMQ

ActiveMQ常被应用与系统业务的解耦，异步消息的推送，增加系统并发量，提高用户体验。

如何使用ActiveMQ

1.AcitveMQ的数据传送流程

2.ActiveMQ的两种消息传递类型（同消息中间件一样，ActivateMQ也分为以下两种消息模式）
（1）点对点传输，即一个生产者对应一个消费者，生产者向broke推送数据，数据存储在broke的一个队列中，当消费者接受该条队列里的数据；
（2）基于发布/订阅模式的传输，即根据订阅话题来接收相应数据，一个生产者可向多个消费者推送数据；有兴趣可见https://www.cnblogs.com/xiguadadage/p/11216463.html

两种消息传递类型的不同，点对点传输消费者可以接收到在连接之前生产者所推送的数据，而基于发布/订阅模式的传输方式消费者只能接收到连接之后生产者推送的数据。

我们测试环境中要达到的目的是，发出去的任务，然后被调度到某台机器上被转码，所以编码云的环境中使用的是第一种点对点的传输方式；

ActivateMQ的实例请参考：https://www.cnblogs.com/xiguadadage/p/11217604.html

RedisMQ

Redis是使用C语言开发的一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于如何实现Producer-Consumer，redis并没有比较直接的方案，但是在list中提供了一个方法RPOPLPUSH，其中官方的资料介绍如下，让我们来看以下对于RedisMQ实现消费者队列如何实现的吧！

模式：安全的队列
Redis通常都被用做一个处理各种后台工作或消息任务的消息服务器。 一个简单的队列模式就是：生产者把消息放入一个列表中，等待消息的消费者用 RPOP 命令（用轮询方式）， 或者用 BRPOP 命令（如果客户端使用阻塞操作会更好）来得到这个消息。
然而，因为消息有可能会丢失，所以这种队列并是不安全的。例如，当接收到消息后，出现了网络问题或者消费者端崩溃了， 那么这个消息就丢失了。
RPOPLPUSH (或者其阻塞版本的 BRPOPLPUSH） 提供了一种方法来避免这个问题：消费者端取到消息的同时把该消息放入一个正在处理中的列表。 当消息被处理了之后，该命令会使用 LREM 命令来移除正在处理中列表中的对应消息。

另外，可以添加一个客户端来监控这个正在处理中列表，如果有某些消息已经在这个列表中存在很长时间了（即超过一定的处理时限）， 那么这个客户端会把这些超时消息重新加入到队列中。

RedisMQ实现示例详见：https://blog.csdn.net/ZuoAnYinXiang/article/details/50263945