MQ 产品选型方案

1       需求描述

报修状态推送给瑞云小程序，解决工单状态不能实时获取的问题。

目前运营平台报修接口API，能够提供工单列表和工单详情，但是如果要获取工单状态及时更新，目前只能通过轮询的方式。增加了运营平台接口请求压力，实时性也不能保证。

所以，运营平台开始选型消息队列(MESSAGE QUEUE,简称MQ)，以下是MQ选型和技术对比。

2       RabbitMQ

消息系统允许软件、应用相互连接和扩展．这些应用可以相互链接起来组成一个更大的应用，或者将用户设备和数据进行连接．消息系统通过将消息的发送和接收分离来实现应用程序的异步和解偶．

进行数据投递，非阻塞操作或推送通知。实现发布／订阅，异步处理，或者工作队列。所有这些都可以通过消息系统实现。

RabbitMQ是一个消息代理 - 一个消息系统的媒介。它可以为你的应用提供一个通用的消息发送和接收平台，并且保证消息在传输过程中的安全。

2.1      技术亮点

1. 可靠性：RabbitMQ提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制。
2. 灵活的路由：消息在到达队列前是通过交换机进行路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。如果你有更复杂的路由需求，可以将这些交换机组合起来使用，你甚至可以实现自己的交换机类型，并且当做RabbitMQ的插件来使用。
3. 集群：在相同局域网中的多个RabbitMQ服务器可以聚合在一起，作为一个独立的逻辑代理来使用。
4. 联合：对于服务器来说，它比集群需要更多的松散和非可靠链接。为此RabbitMQ提供了联合模型。
5. 高可用的队列：在同一个集群里，队列可以被镜像到多个机器中，以确保当其中某些硬件出现故障后，你的消息仍然安全。
6. 多协议：RabbitMQ 支持多种消息协议的消息传递。
7. 广泛的客户端：只要是你能想到的编程语言几乎都有与其相适配的RabbitMQ客户端。
8. 可视化管理工具：RabbitMQ附带了一个易于使用的可视化管理工具，它可以帮助你监控消息代理的每一个环节。
9. 追踪：如果你的消息系统有异常行为，RabbitMQ还提供了追踪的支持，让你能够发现问题所在。
10. 插件系统：RabbitMQ附带了各种各样的插件来对自己进行扩展。你甚至也可以写自己的插件来使用。
11. 商业支持：可以提供商业支持，包括培训和咨询。
12. 大型社区：围绕着RabbitMQ有一个大型的社区，有着各种各样的客户端、插件、指南等等。

3       消息队列 CMQ

腾讯云消息队列（Cloud Message Queue，CMQ）是一种分布式消息队列服务，它能够提供可靠的基于消息的异步通信机制，能够将分布式部署的不同应用（或同一应用的不同组件）之间的收发消息，存储在可靠有效的 CMQ 队列中，防止消息丢失。 CMQ 支持多进程同时读写，收发互不干扰，无需各应用或组件始终处于运行状态。

3.1      腾讯云 CMQ 的特性

1. 高性能：消息队列 CMQ 高效支持亿级消息收发和推送，海量消息堆积且消息堆积容量不设上限；CMQ 吞吐量巨大，单集群 QPS 超过 10 万，满足您的业务之间的消息收发需求。
2. 高可用：CMQ 在每条消息返回到用户时，将消息数据备份 3 份写到不同物理机上，当某台物理机出故障时，后台数据复制机制能够对数据快速迁移，保证用户数据3 个备份可用，可靠保证达99.999999%，业务连续可用性99.95%承诺，引入 Raft 算法实现数据强一致性。
3. 横向扩展：底层系统根据业务规模，自动弹性扩展消息队列的队列数量和队列存储容量，对上层业务无感知，提供北京、上海、广州等多地域服务。平滑水平扩展，单集群提供超 10 万 QPS，逻辑上单个队列服务可跨多个集群提供服务。
4. 安全可靠：CMQ 支持 HTTPS 安全访问连接，并基于腾讯云平台多维度的安全防护，抵御网络攻击，保护您的业务隐私。同时支持主子账号，协作者账号等账号管理，支持基于细粒度资源访问控制权限，细化管理。
5. 易用免运维：提供 API 访问接口和 java，C++ 等多种 SDK，简化开发成本，方便上云。支持多维度的监控告警功能，无须关心底层资源的运维，专注您的业务开发。
6. 异步通信协议：消息的发送者将消息发送到消息队列后可以立即返回，不用等待接收者的响应。消息会被保存在队列中，直到被接收者取出。消息的发送与处理是完全异步的。
7. 提高可靠性：传统模式下消息可能因为长时间等待而导致请求失败。消息队列模式下，如果发送消息时接收者不可用，消息队列会保留消息直到成功传递它。
8. 进程解耦：消息队列帮助减少两个进程间的耦合度。只要消息格式不变，即使接收者的接口、位置或者配置改变，也不会给发送者带来任何改变。并且，消息发送者无需知道消息接收者是谁，使得系统设计更清晰；相反的，进程间使用远程过程调用（RPC）或者 socket 连接，当一方接口、IP 或端口改变了，另一方则必须修改请求配置。
9. 消息路由：发送者无需与接收者建立直接连接，双方通过消息队列保证消息能够从发送者路由到接收者，甚至对于本来网络不易互通的两个服务，也可以提供消息路由。
10. 多终端：用户系统的多个部分可以同时发送或接收消息，腾讯云 CMQ 通过消息状态来进行消息可用性的控制。
11. 多样性：每个队列均可独立配置，并非所有队列都要完全相同。在不同业务场景下的队列可以进行个性化的配置，例如一个队列中消息处理时间较长，可以针对队列属性进行优化。
12. 云函数触发：CMQ 主题模型可将消息传递给云函数 SCF，并将消息内容和相关信息作为参数来调用该函数。

3.2      腾讯云 CMQ 与 RabbitMQ 的对比分析

RabbitMQ 是具有代表性的开源消息中间件，当前较多地应用于企业系统内，用于对数据一致性、稳定性和可靠性要求较高的场景中。     腾讯云 CMQ 基于 RabbitMQ/AMQP 高可靠的原理，并使用 Raft 协议重新设计实现，在可靠性、吞吐量和性能上有了大幅提升。

本文将重点介绍 RabbitMQ 的可靠性原理、腾讯云 CMQ 进行的改进以及性能对比。

3.2.1 RabbitMQ 的消息可靠交付

3.2.1.1     确认机制

网络异常、机器异常、程序异常等多种情况都可能导致业务丢失消息。对消息进行确认可以解决消息的丢失问题，确认成功意味着消息已被验证并正确处理。

 

RabbitMQ 使用生产消息确认、消费者确认机制来提供可靠交付功能。

· 生产消息确认：生产者向MQ发送消息后，等待 MQ 回复确认成功；否则生产者向 MQ 重发该消息。此过程可以异步进行，生产者持续发送消息，MQ 将消息批量处理后再回复确认；生产者通过识别确认返回中的 ID 来确定哪些消息被成功处理。

· 消费者确认：MQ 向消费者投递消息后，等待消费者回复确认成功；否则 MQ 重新向消费者投递该消息。该过程同样可以异步处理，MQ 持续投递消息，消费者批量处理完后回复确认。

可以看出 RabbitMQ/AMQP 提供的是“至少一次交付”（at-least-once delivery），异常情况下，消息会被重复投递或消费。

3.2.1.2     消息存储

为提高消息的可靠性，保证在 RabbitMQ 重启服务不可用时，要对收到的消息持久化写入磁盘。在收到消息时 RabbitMQ 将消息写入文件中，当写入达到一定数量或一定时间周期后 RabbitMQ 将文件落盘存储。

生产消息确认就是在消息落盘存储后，MQ向生产者回复已落盘存储的消息 ID。

CMQ 与 RabbitMQ 的底层原理、实现方式有很多相似之处，但在更大程度上进行了升级改造：

3.2.2.1     功能升级

除了生产、消费确认机制，CMQ 还提供了消费回溯功能。

用户可以指定腾讯云 CMQ 保存生产消息一定天数，随后将消费回溯到该时间段内某一时间点，从该点开始重新消费。在用户业务逻辑异常时，以时间为起点的消息重放功能对业务恢复非常有帮助。

3.2.2.2     性能优化

3.2.2.3     可用性提升

CMQ 和 RabbitMQ 都能够使用多台机器进行热备份，提高可用性。CMQ 基于 Raft 算法实现，简单易维护。RabbitMQ 使用自创的 GM 算法（Guaranteed Multicast），学习难度较高。

Raft 协议中，Log 复制只要大多数节点向 Leader 返回成功，Leader 就可以应用该请求，向客户端返回成功：

GM 可靠多播将集群中所有节点组成一个环。Log 复制依次从 Leader 向后继节点传播，当 Leader 再次收到该请求时，发出确认消息在环中传播，直至 Leader 再次收到该确认消息，表明 Log 在环中所有节点同步完成。

GM 算法要求 Log 在集群所有节点同步之后才能向客户端返回成功；Raft 算法则只要求大多数节点同步完成。Raft 算法在同步路径上比 GM 算法减少了近一半的等待时间。

3.2.2.4     CMQ 对比 RabbitMQ 的性能测试

测试场景如下：三台同样配置的机器组成一个集群，腾讯云 CMQ、RabbitMQ 均配置为镜像队列，数据均在三台机器上同步。腾讯云 CMQ 和 RabbitMQ 都开启生产、消费消息确认机制。测试中的生产消息大小为1KB。

测试数据如下：

在高可靠场景中，CMQ 吞吐量优于 RabbitMQ 的四倍以上。

3.3CMQ产品优势

3.3.1 对比 RabbitMQ 的优势

**CMQ-QPS 优势：**在保证高可靠前提下，同等物理设备，CMQ 的吞吐量优于 RabbitMQ 四倍以上。单集群 QPS 超过10万。

**RabbitMQ 不支持消息回溯：**RabbitMQ 不支持消息回溯，CMQ 支持按照时间回溯消息。例如从一天之前的某时某分某秒开始重新消费消息。典型业务场景如 Consumer 做订单分析，但是由于程序逻辑或者依赖的系统发生故障等原因，导致今天消费的消息全部无效，需要重新从昨天零点开始消费，那么以时间为起点的消息重放功能对于业务非常有帮助。

**一致性算法对比：**CMQ 和 RabbitMQ 都能够使用多台机器进行热备份，提高可用性。CMQ 基于 Raft 算法实现，简单易维护。RabbitMQ 使用自创的 GM 算法（Guaranteed Multicast），学习难度较高。

**RabbitMQ 运维难度大：**RabbitMQ 的开发语言用的是 Erlang，较小众、学习成本高。

3.3.2       对比 RocketMQ 的优势

**RocketMQ 在极端情况下，会丢失数据：**RocketMQ 允许未刷盘就向客户端返回确认，在机器异常宕机时，会丢消息。

**RocketMQ 需搭建多 Master、Slave 才能保证业务高可用：**RocketMQ 只有在 ISR 中有存活节点时，才能保证可用性和可靠性，ISR 中无存活节点时，可用性和可靠性无法保证，开销较大。

因此，相比传统开源 MQ 应用，腾讯云 CMQ 具有以下优势：