腾讯云消息队列CMQ-分布式消息队列服务

CMQ 消息队列介绍

CMQ（Cloud Message Queue）是基于腾讯自研消息引擎的分布式消息队列系统，CMQ 通过腾讯自研分布式 Raft 算法消息强一致，消息同步3副本落盘保障消息高可靠，提供消息队列、发布订阅、消息回溯、延时消息、顺序消息、消息轨迹等服务。具有高可靠、高可用、、动态伸缩等优势。 CMQ 的开发迭代历程超过7年，为腾讯内部包括、webank、 秀、手机 等大型业务提供异步的消息服务支持。

CMQ 已经正式商用，目前在腾讯云多个地域提供了高可用消息云服务，机房硬件设施按照腾讯自建 IDC 的高标准来实施。单个地域内采用多机房部署，即使整个机房都不可用，仍然可以为应用提供消息发布服务。同时在深圳金融专区、上海金融专区均有部署，提供金融级数据高可靠消息队列服务。

CMQ 目前提供 HTTP(S)、TCP 协议的接入。提供 PHP、Java、Python 等丰富语言的 SDK 接入。

说明：

• CMQ TCP 接入方式，正在内测中，欢迎工单联系售后工程师，将有专人为您开通内测服务。

• CMQ 支持私有化部署，欢迎工单联系售后工程师，将有专人为您开通内测服务。

在需要进行异步通信的应用情景中推荐使用 CMQ。例如：

• 应用需要确保消息的可靠传递，即使发送消息时接收者由于断电、宕机或 CPU 负载过高等原因不可用，消息也可以在接收者可用时被送达。传统的消息队列把消息储存在内存中，故而不具备这一功能。腾讯云 CMQ 分布式消息队列中的消息会被持久化保存，直到接收者成功获取它。

• 需要在访问量与日俱增、囤积在队列中的消息数日益增长的情况下也能正常运转。传统的消息队列把消息存在本地内存中，单机的处理能力和内存容量都是有限的，不具备可扩展性。腾讯云 CMQ 的分布式架构了其扩容的简易性，更重要的是扩容对 CMQ 的使用者是完全透明的。

• 两个服务在网络不能互通或者应用的路由信息（例如 IP 和端口）不确定的情况下需要通信。例如，两个腾讯云上的服务在不知道对方地址的情况下需要进行通信，则可以通过约定队列名，一个向队列发送消息，一个从队列中收取消息而实现。

• 系统组件之间或者应用之间通信较多，需要组件或者应用自身维护彼此的网络连接，而且通信的内容不仅一种。这时，使用传统的架构会使得系统设计复杂。例如：当有一个中央处理服务需要向多个任务处理服务分派任务时（类似于 master-worker 模式），master 需要维护与所有 worker 的连接，并判断 worker 是否开始处理任务从而决策是否需要重新分派任务。同时，worker 的任务结果也需要汇报给 master。要在一个层面维护这样的系统会导致设计复杂，实现难度和维护成本大。如下图所示，使用腾讯云 CMQ 减轻两方的之间耦合性会使系统简洁许多。
  

• 系统组件之间或者应用之间耦合较紧，尤其对依赖的组件可控性较弱的情况下，希望降低耦合度。例如公司业务 CGI 收到用户提交的内容，将部分数据存储在自身的系统中，并将处理后的数据转发给其他业务应用（如数据分析系统、数据存储系统等）。传统的解决方案是服务间通过 socket 建立连接，此时如果接收方的 IP 或端口改变，或换了另一个接收方，则需要数据发送者进行修改。使用腾讯云 CMQ，发送者和接收者对彼此信息无感知，耦合度大大降低。

异步通信协议

消息的发送者将消息发送到消息队列后可以立即返回，不用等待接收者的响应。消息会被保存在队列中，直到被接收者取出。消息的发送与处理是完全异步的。

提高可靠性

传统模式下消息可能因为长时间等待而导致请求失败。消息队列模式下，如果发送消息时接收者不可用，消息队列会保留消息直到成功传递它。

进程解耦

消息队列帮助减少两个进程间的耦合度。只要消息格式不变，即使接收者的接口、位置或者配置改变，也不会给发送者带来任何改变。并且，消息发送者无需知道消息接收者是谁，使得系统设计更清晰；相反的，进程间使用远程过程调用（RPC）或者 socket 连接，当一方接口、IP 或端口改变了，另一方则修改改写请求配置。

消息路由

发送者无需与接收者建立直接连接，双方通过消息队列消息能够从发送者路由到接收者，甚至对于本来网络不易互通的两个服务，也可以提供消息路由。

多终端

用户系统的多个部分可以同时发送或接收消息，腾讯云 CMQ 通过消息状态来进行消息可用性的控制。

多样性

每个队列均可立配置，并非所有队列都要完全相同。在不同业务场景下的队列可以进行个性化的配置，例如一个队列中消息处理时间较长，可以针对队列属性进行优化。

云函数触发

CMQ 主题模型可将消息传递给云函数 SCF，并将消息内容和相关信息作为参数来调用该函数。

对比 RabbitMQ 的优势

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

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

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

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

调用 CMQ 时出现 10250 qps throttling 异常如何解决？

出现该异常是由于 QPS 达到了上限值。QPS 默认值为5000，表示每秒发送（发布）消息的上限为5000 条，消费的消息条数默认为生产的1.1倍。如果对 QPS 有要求，可以提工单申请提高 QPS 上限。

如果没有需要的 SDK 应该如何操作？

如果没有对应的语言，可以按照官网文档中的规范自己组包调用 CMQ 服务。

如何使 API 密钥只对 CMQ 的接口有用？

API 密钥是全局的密钥，目前 CMQ 已经接入 CAM，您将可以使用 CAM 进行权限控制。

CMQ 可以使用外网域名吗？

CMQ 可以使用外网域名，需要将内网域名的 tencentyun 替换为 qcloud。推荐您使用内网域名，使用外网会收取流量费用，且外网时延可能较高。

CMQ 支持 HTTPS 吗？

目前内网域名不支持 HTTPS，外网域名支持 HTTPS。

协作者账户可以使用 CMQ 吗？

目前协作者、子账户均可以使用 CMQ, 需要在 CAM 开通 CMQ 对应的资源操作权限。

CMQ 目前有几种 SDK？

CMQ 目前有 C++、PHP、Python 和 Java 四种 SDK。

当前队列的消息数小于当前请求的批量消费数量，请求会阻塞吗？

不会阻塞。

目前 SDK 是异步模式吗？

HTTP SDK 所有操作均为同步模式，TCP SDK 接入可选择异步模式。

可以在图形管理界面中查看队列的情况吗？

CMQ 提供可视化控制台，您可以很方便地查看当前队列情况。

CMQ 目前支持 MQTT 协议吗？

CMQ 目前不支持 MQTT 协议。