1   背景

目前天翼云已支持Kafka、RocketMQ、RabbitMQ、MQTT四款款主流的消息中间产品，用户需要根据用途选择合适产品。

2   目标

主流的消息中间件有Kafka、RocketMQ、RabbitMQ、MQTT、PULSAR等多款组件，本文列举了一些选型指标，为用户消息选型提供方向。

2.1    总体目标

分析消息引擎的主要目标是增强天翼云的消息中间件产品服务能力，丰富产品类型、缩小与头部云厂商的差距。

2.2 选型目标

从架构、消息服务能力、性能、可靠性、可用性、扩展性、社区、生态等多维度对，对主流消息中间件进行分析，选择合适的消息中间件，匹配用户生产需求。

3   消息中间件概述

3.1 消息中间件特性

 消息中间件(MQ)在当前的分布式系统架构中承载着重要的作用，其核心的应用场景主要有以下三个：

异步，异步调用为非阻塞模式，延迟低，对于一些耗时的场景，比如订单完成后，实现短信或邮件通知，就适合采用消息分发机制。

解耦，消息系统采用生产订阅模式，生产者只负责将消息发送出去，而不关心谁来消费；消费者只负责获取并处理消息，而不用关心谁生产的，生产和消费系统的解耦，对于大型复杂的业务系统尤其重要，微服务的理念也是如此。

削峰，在高并发的场景下，通过消费系统的延迟消费，大大缓解服务器的压力，典型就是电商双十一的场景，瞬间产生海量消息，通过MQ的消息堆积能力，将消费端处理能力控制在合理的范围内。

3.2 消息中间件类型

消费中间件有很多种，目前主流的主要以下四款产品，分别为RabbitMQ，Kafka，RocketMQ，Pulsar。

 

3.2.1 Kafka

     Kafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。在MQ家族比较另类，它其实也是大数据家族的重要成员，设计之初就具备了高吞吐的特性，是一种高吞吐量的分布式发布订阅消息系统。

    现代互联网大数据中，如需要分析用户的特性，爱好，习惯等，就需要收集海量的用户行为数据，包括浏览路径，点击动作，行为日志等等，这些海量的数据的传递和汇聚可以通过Kafka完成，如其说Kafka是消息中间件系统，不如说是大数据交换通道系统，所以Kafka定位为流处理平台。

3.2.2 RocketMQ

      Rocket是由阿里巴巴开发，是为数不多的由国人开发，贡献给Apache组织的项目，其采用Java语言开发。经过阿里历年双十一流量洪峰的洗礼，并发性和可靠性得到了充分的验证，且支持的功能丰富，是活跃度较高的中间件之一，由于中文文档丰富，又有阿里巴巴支撑，在国内很有市场。

3.2.3 Pulsar

         Pulsar是由yahoo公司于2016年开源，2018年成为Apache的顶级项目，被誉为下一代的消息队列，业界对其期望很高。Pulsar采用Java开发，使用Bookeeper作为存储，具备了高吞吐，低延迟，计算存储分离，多租户，异地复制等特性，这些特性也使得Pulsar成为Kafka的有力竞争者，实际上，它也是对标Kafka的产品。

       Pulsar作为后起之秀，并没有Kafka为人熟知，但是近些年国内的一些大的互联网企业也逐渐关注，并在生产系统上线，比如腾迅的的计费系统、云消息产品TDMQ。

3.2.4 RabbitMQ

       RabbitMQ是采用Erlang语言实现AMQP(Advanced Message Queuing Protocol，高级消息队列协议)。AMQP是一个应用层协议的开放标准，解决消息中间件的需求和拓扑问题。RabbitMQ也是该协议最成功的产品实现。Erlang语言其实是比较小众的，最初用于交换机领域的架构模式，被用来实现AMQP协议，使得RabbitMQ在Broker之间进行数据交互的性能非常优秀。RabbitMQ以其可靠性，灵活路由，以及强大的集群模式，在MQ家族中大放异彩。

4   消息中间件选型

消息中间件的选型，具体要结合用于哪一种业务场景，底座的选型，考虑的因素更多，比如：功能、性能、可靠性、扩展性、社区生态、开发语言。

 

4.1 架构

这个是一个比较大的概念，对于消息中间件来说，我们比较关心2点，一是：服务 第二是：存储架构，架构首先就已经决定了性能、可靠性、可用性、扩展性等特点。

4.2 消息服务能力

对于消息中间件选型，功能是优先要考虑的因素，如果功能方面不满足生产要求，其他的也无从考虑。

• 优先级消息

对于消息可以设置优先级，优先级高的消息拥有优先被消费的特权，这种在是消费速度小于生产速度，产生消息堆积的时候才会有效。如果消息速度大于生产速度，即生产的消息马上被消息，优先级消息也就没有实际意义了。

• 延迟消息

某些场景中，希望投递的消息，不要立即被消息，而是延迟一段时间。比如购买火车票，选择对应的车次后，锁定10分钟，如果该时段内没有付款，将会取消本次购买，释放车票，该场景就可以使用延迟消息实现。从性能上考虑，一般采用固定的定时延迟，比如5s，10s,1m等等，这样可以将相同延迟时间的消息放在一个延迟队列中，批量处理和发送。

• 事务消息

在可靠性要求比较高的场景，预先发送或者消费消息，再本地逻辑处理，根据处理结果决定提交或者回滚消息。一般采用二阶段提交模式，当Broker没有接受到commit或者rollback指令，会回查该消息，确保消息被处理。

• 顺序消息

保证消息的生产和消费有序性，很常见的场景就是数据抽取CDC(Change Data Chapture)，以Mysql为例，需要确保binlog的抽取和消费的顺序性，否则会导致数据的不一致。

• 死信队列

某些异常场景下，导致消息投递失败，或者消费失败，为了确保消息的不丢失，并且不影响其他消息的正常消费，一般将该异常消费放置到特定的队列，这个队列被称之为死信队列，死信队列具有普通队列的所有特性，也可以被消费。通过监控死信队列，可以查看异常消息的状态。

• 重试队列

对于某些明确暂时无法处理，或者应用业务层面处理失败的消息，希望过一段时间重试处理，这种场景就需要使用到重试队列，通常重试队列可以指定重试次数，以免不断循环处理一些永远都无法处理成功的消息，重试队列通常也需要配合死信队列一起使用，重试策略中，指定消费多少次仍无法处理的消息，转移到死信队列，监控死信队列，以便业务补尝处理或者人工介入处理。

• 消息TTL

消息time to live，指消息发送后，间隔多长时间允许被清理，对于一些对消息有时效性的使用场景。

• 批量发送

发送时，支持量发送，以提高性能

• 消息压缩

支持消息压缩，减少带宽的占用，以提高性能

• 失败重试

支持失败重试策略，减少失败后，应用介入处理的工作量

• 消息去重

大部份主流消息中间件都做不到仅仅一次的语义，这个和分布式CAP的制约有关，如果实现仅仅一次的语义，需要使用事务消息，引入更为复制的机制来处理，消息重复，在生产阶段，一般是由于，失败重试造成的，消息去重能保证在发送阶段消息的仅仅一次的语义（要实现消息端到端仅仅一次的语义，消费端也需用一定的策略来处理）

• 持久化、非持久化

持久化是指对确认发送成功的消息，实现可靠的持久化；非久持久刚好相反，不需对消息做持久化，通常用在一些可接受消息丢失的场景，比如:日志、监控指标的采集，优点就是性能更优，而且不需要占用存储，有一定的应用场景

• 消费模式

消费模式分为"推"和"拉"两种模式，"推"模式是Broker主动将消息推送到消费端，这种模式，实时性较好，不过要有措施确保消息端的处理能力，不要被压垮；"拉"模式是消费端主动从Broker获取消息，消费端可以自身的处理能力确定获取消息的速度，但实时性较差。

• 消息签收

消息签收是指消息消费完成后，对已消费消息的ack确认信息，消息系统，一般有两种常见的签收策略，单条签收、累积签收，比如：Kafka、RocketMQ仅支持累积签收，服务端，单个消费组、单个分区，只保留一个签收进行，累积签收的的优点是：实现逻辑简单、性能好，但一旦消费实例重启、或者队列重平衡，可能导致大量的重复消息。

• 订阅模式

订阅模式包括点对点模式和发布订阅模式，点对点模式，生产的消息仅能被一个消费者消费；发布订阅模式，生产的消息被所有订阅的消费端消费。实际生产过程中，很多时候是这两种模式的组合，比如在电商业务中，用户下单成功的消息需要被物流，供应商等多个系统同时消费，这种是发布订阅模式；每个系统的消费者为集群模式，仅能被其中某个实例消费，此时又是点对点模式。

• 消息堆积

削峰是MQ主要场景之一，当消息洪峰到来，消息无法来得及处理，此时就需要依赖中间件的消息堆积能力，实现延迟消费。一般通过大容量磁盘实现消息的持久化存储。

• 消息回溯

在有些场景下，消息被正确的消费了，但是由于某些异常情况，导致下游的消息丢失，比如数据库磁盘损坏等，此时需要指定消息的位置，进行回溯和重新消费。消息回溯功能对于保证消息“不丢失”非常重要。

• 消息过滤

按一定的过滤规则为下游消费者提供消息，过滤规则包括值匹配，范围，以及SQL语句，当然，消息过滤会损耗一定的性能。在跨机房转发的场景中，可以通过消息过滤将特定的部分消息转发到其他机房。

• 消息的查询和追踪

消息从哪里来，最终又到哪里去了，消息的链路追踪对于问题的定位和排查非常重要。

• 消息清除

对于已消费过，或者超期的消息实施清除，以确保足够的空间接受新的消息。

• 资源隔离

在共享相同的系统或程序组件的场景下，实现租户之间数据的隔离。一套集群就可以服务多个租户，多租户带来了成本的降低和运营的简便；Pulsar的namespace、或者RabbitMQ的vhost同样属于支持资源隔离。

• 资源配额

不同接入用户或者客户端或者，不同的资源对象可以使用的资源配额，配额一般有：连接数、流量、TPS、存储容量等

• 安全性

消息中间件也可以看做是存储模块，如果存在敏感数据或者保密性要求高，那么安全性是必选项。MQ的安全性需要包括身份认证和权限控制，身份认证是指客户端与Broker，Broker与Broker之间的连接认证；权限控制是指对客户端的读写操作进行权限控制，另外部分消息中间件支持消息端到端的加密，当然在应用端自行实例加密也可以。

• 配置

支持资源级别的配置，比较Kafka的支持Broker级别、主题级别的配置，但像RocketMQ公支持Broker级别的配置，对于多业务应用共享的集群无法做到根据不同的业务需求灵活配置。

4.3 性能

消息中间件的性能是选型的重要考虑条件，消息中间件的架构、消息存储机器已经决定了消息中间件的性能范围，后续进行二次开发，如果在不变列架构、存储机制的前提下，性能一般很难会有大的突破，所以为了减少二次开发的难度及工作量，性能是选型最需关注的指标。

4.4 可靠性

可靠性也是消息中间件重要的指标，需要确保 消息的不丢失，对于某些特定的场景，比如金融，消息的可靠性是要严格得到保证。但是没有任何一款中间件能100%确保消息的不丢失，且可靠性要求越高，必然能损失部分性能，比如同步发送，事务消息，同步落盘等，都是以损耗性能为代价，鱼与熊掌不可兼得。

广义上的可靠性，也包含可用性，故障发送时，能快速转移和恢复，对业务的影响降到最低。中间件采用主从，分布式集群等架构模式，满足对可用性的要求。

 

4.5 可用性、扩展性

可用性，是指在在一个或者多个服务节点无法正常提供服务的情况下，整个集群仍能提供全部或者受限的服务，保证重要功能仍能正常使用。

扩展性，有两个方面，一是指集群的扩容，对应用来说能做受到无感知扩容，无论计算或者存储能力，都可以做到在线、透明扩容，二是指消息中间件本身可以进行扩展，通过二次开发达到扩展消息服务能力的目的。

4.6 社区生态度

这条也是选择中间的现实考虑因素之一，特别对于中小企业，这个可能成为最优先考虑因素，如果选择的中间件与团队的技能不匹配，或者中间件的社区活跃读不高，就意味后续需要投入更多成本进行学习和踩坑。

当然选型过程中，还有其他很多考虑因素，比如运维工具，项目的继承性等等。总之，没有一个中间件能包治百病，只能对症下药，综合各种因素，最大程度选择适合自己的。

4.7 SDK、协议

主要有两方面：1.SDK易用性 2.支持更多的的语言的SDK，易用性对应用使用更友好，不用过多的处理一些细节问题，比如：服务端有节点离线、连接断开等，当用易用性不单单这些，包括方方面面。多语言SDK，方便使用不同语语言开发的应用能轻松集成SDK，广义来说，SDK也包括了对公共应用层协议的支持，比如：HTTP、WebSocket等

4.8 运维管理

完善的运维管理机制，主要包括：

1. 命令行 基本主流的消息中间件都提供了命令行运维工具，方便专业运维人员对服务的运维工作
2. 运维控制台 通常是对命令行或者管理API的封装，对集群进行管理，运维控制台，以更直观的方观进行运维管理操作，更加友好，比如RabbitMQ managerment
3. 管理API 管理API通常是方便运维管理功能，对于用户开发非常重要
4. 规范的监控数据（比如Promethus规范）