消息中间件相关知识

概述

消息队列已逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠交付、广播、流量控制、最终一致性等一系列功能RPC的主要手段之一。当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等。

2.消息中间件的组成

2.1 Broker

作为消息服务器server提供核心新闻服务

2.2 Producer

新闻制作人、业务发起人负责向生产新闻传递broker，

2.3 Consumer

负责消息消费者、业务处理方broker获取消息并进行业务逻辑处理

2.4 Topic

主题，发布订阅模式下的新闻统一收集地，不同的生产者向topic发短信，由MQ服务器分发给不同的订阅者，实现新闻 广播

2.5 Queue

队列，PTP在模式下，特定生产者向特定生产queue发送消息，消费者订阅特定信息queue接收指定信息

2.6 Message

根据不同通信协议定义的固定格式编码的数据包，包装业务数据，实现消息传输

3 新闻中间件模式分类

3.1 点对点

PTP点对点：使用queue作为通信载体

说明：

新闻制作人的生产消息发送到queue然后消息消费者从queue取出并消费消息。

消息消费后，queue不再存储，所以消费者不能消费已经消费的消息。 Queue支持多个消费者，但对于一个消息，只有一个消费者可以消费。

3.2 发布/订阅

Pub/Sub发布订阅(广播):使用topic作为通信载体

说明：

消息制作人(发布)将消息发布topic同时，消费者(订阅)也有多个消息消费这个消息。不同于点对点，发布到topic所有订阅者都会消费消息。

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

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

4 新闻中间件的优点

4.1 系统解耦

交互系统之间没有直接的调用关系，只是通过信息传输，所以系统侵入性不强，耦合度低。

4.2 提高系统响应时间

例如，在完成支付之前，可能需要修改订单状态、计算会员积分和通知物流配送；通过MQ架构设计可以将重要(需要立即响应)的紧急业务放入调用方法中，并将响应要求低的使用消息队列放入调用方法中MQ消费者在队列中处理。

4.3 为大数据处理架构提供服务

在大数据的背景下，新闻队列还与实时处理架构集成，为数据处理提供性能支持。

4.4 Java消息服务——JMS

Java消息服务（Java Message Service，JMS）一个应用程序接口Java平台关于面向新闻的中间部件（MOM）的API，用于在两个应用程序之间或分布式系统布式系统中发送信息。

JMS中的P2P和Pub/Sub新闻模式：点对点（point to point， queue）与发布订阅（publish/subscribe，topic）最初是由JMS定义的。这两种模式主要区别或解决的问题就是发送到队列的消息能否重复消费(多订阅)。

5 新闻中间件应用场景

5.1 异步通信

有些企业不想也不需要立即处理这些信息。消息队列提供了一种异步处理机制，允许用户将消息放入队列，但不会立即处理。把你想把的信息放在队列中，然后在必要时处理它们。

5.2 解耦

降低工程之间的强依赖性，适应异构系统。在项目启动之初，极难预测项目未来会遇到什么需求。通过在处理过程中间插入一个基于数据的隐含接口层，在处理过程中实现两侧的处理过程。当应用程序发生变化时，只要它们遵守相同的接口约束，就可以独立扩展或修改两侧的处理过程。

5.3 冗余

在某些情况下，处理数据的过程会失败。除非数据持久，否则会丢失。消息队列将数据持久化，直到它们完全处理，以避免数据丢失的风险。在插入-获取-删除范式中，在从队列中删除消息之前，您的处理系统需要明确指出消息已经处理好，以确保您的数据安全保存，直到您使用。

5.4 扩展性

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。

5.5 过载保护

当访问量急剧增加时，应用程序仍然需要继续发挥作用，但这种紧急流量无法提取预测；投资资源随时待命无疑是一种巨大的浪费，以应对此类瞬时峰值访问。使用信息队列可以使关键组件承受紧急访问压力，而不会因紧急超载要求而完全崩溃。

5.6 可恢复性

当系统的部分组件失效时，不会影响整个系统。消息队列减少了过程之间的耦合，因此即使处理消息的过程被挂断，系统恢复后仍然可以处理添加到队列中的消息。

5.7 顺序保证

在大多数使用场景中，数据处理的顺序非常重要。大多数新闻队列最初是排序的，并且可以确保数据按特定的顺序处理。

5.8 缓冲

在任何重要的系统中，都会有需要不同处理时间的元素。缓冲有助于控制和优化数据流通过系统的速度，通过缓冲层帮助任务最高效地执行。调整系统响应时间。

5.9 数据流处理

分布式系统产生的大量数据流，如业务日志、监控数据、用户行为等，实时或批量收集和总结这些数据流，然后进行大数据分析是当前互联网的必要技术，通过消息队列完成这些数据收集是最好的选择。

6 常用的新闻中间件协议

6.1 AMQP协议

AMQP即Advanced Message Queuing Protocol,提供统一消息服务的应用层标准高级消息队列协议是为面向消息的中间件设计的应用层协议的开放标准。基于本协议的客户端和消息中间件可以传输消息，不受客户端/中间件不同产品和不同开发语言的限制。

优点：可靠、通用

6.2 MQTT协议

p>MQTT（Message Queuing Telemetry Transport，消息队列遥测传输）是IBM开发的一个即时通讯协议，有可能成为物联网的重要组成部分。该协议支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当做传感器和致动器（比如通过Twitter让房屋联网）的通信协议。 

优点：格式简洁、占用带宽小、移动端通信、PUSH、嵌入式系统

 

      6.3 STOMP协议

 

STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息协议，是一种为MOM(Message Oriented Middleware，面向消息的中间件)设计的简单文本协议。STOMP提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理（Broker）进行交互。 

优点：命令模式（非topic\queue模式）

 

      6.4 XMPP协议

 

XMPP（可扩展消息处理现场协议，Extensible Messaging and Presence Protocol）是基于可扩展标记语言（XML）的协议，多用于即时消息（IM）以及在线现场探测。适用于服务器之间的准即时操作。核心是基于XML流传输，这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息，即使其操作系统和浏览器不同。 

优点：通用公开、兼容性强、可扩展、安全性高，但XML编码格式占用带宽大

 

      6.5 其他基于TCP/IP自定义的协议

 

有些特殊框架（如：redis、kafka、zeroMq等）根据自身需要未严格遵循MQ规范，而是基于TCP\IP自行封装了一套协议，通过网络socket接口进行传输，实现了MQ的功能。

 

 

 

7 常见消息中间件MQ介绍

      7.1 RocketMQ

 

阿里系下开源的一款分布式、队列模型的消息中间件，原名Metaq，3.0版本名称改为RocketMQ，是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品（Notify、metaq）进行整合，只维护核心功能，去除了所有其他运行时依赖，保证核心功能最简化，在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构，目前主要多用于订单交易系统。

 

具有以下特点：

 

能够保证严格的消息顺序

提供针对消息的过滤功能

提供丰富的消息拉取模式

高效的订阅者水平扩展能力

实时的消息订阅机制

亿级消息堆积能力

官方提供了一些不同于kafka的对比差异： 

https://rocketmq.apache.org/docs/motivation/

 

      7.2 RabbitMQ

 

使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP,STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。同时实现了Broker架构，核心思想是生产者不会将消息直接发送给队列，消息在发送给客户端时先在中心队列排队。对路由(Routing)，负载均衡(Load balance)、数据持久化都有很好的支持。多用于进行企业级的ESB整合。

 

      7.3 ActiveMQ

 

Apache下的一个子项目。使用Java完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现，少量代码就可以高效地实现高级应用场景。可插拔的传输协议支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多种语言客户端 C++、Java、.Net,、Python、 Php、 Ruby等。

 

      7.4 Redis

 

使用C语言开发的一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

 

      7.5 Kafka

 

Apache下的一个子项目，使用scala实现的一个高性能分布式Publish/Subscribe消息队列系统，具有以下特性：

 

快速持久化：通过磁盘顺序读写与零拷贝机制，可以在O(1)的系统开销下进行消息持久化；

高吞吐：在一台普通的服务器上既可以达到10W/s的吞吐速率；

高堆积：支持topic下消费者较长时间离线，消息堆积量大；

完全的分布式系统：Broker、Producer、Consumer都原生自动支持分布式，依赖zookeeper自动实现复杂均衡；

支持Hadoop数据并行加载：对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。