客户案例

 

产品优势

功能 消息服务(CMQ) RabbitMQ Kafka RocketMQ
刷盘机制

同步刷盘,数据持久性99.999999%

同步刷盘

异步刷盘,丢数据概率高

允许未刷盘就向客户端返回确认,机器异常宕机时会丢消息

消息堆积能力

消息堆积量无上限,支持百亿级别

磁盘容量为堆积上限

磁盘容量为堆积上限

磁盘容量为堆积上限

强一致性算法对比

raft算法

GM算法(Guaranteed Multicast),定位问题复杂

弱一致性

无法保证强一致性

可用性对比

可用性高,broker 中存在 2 节点即可提供服务

GB算法要求在线的节点全部成功才返回成功,对于网络分区的处理不友好,可用性一般

不支持自动切换,master 故障后 salve 需要人工干预

横向扩展能力

平滑水平扩展,单集群提供 10万+ QPS,逻辑上单个 Queue 可跨多个集群提供服务

群扩容依赖前端 LVS 负载均衡等调度

扩展能力强

不支持水平扩展

消费模型

Push / Pull

Push / Pull

Pull

Pull

批量生产

支持

不支持

支持

支持

数据校验

checksum

CRC

CRC

消息回溯

支持

不支持

支持

不支持

路由匹配键消息过滤

支持

支持

不支持

支持

延迟消息

支持

不支持

不支持

支持

消息重试

支持,失败重试的消息不因为 cons

支持

不支持

支持

死信队列

支持

支持

不支持

不支持

性能对比(2core4GB 内存服务器压测)

读写 12w QPS

读写 10w QPS

读写 20w QPS

读写 10w QPS

 

产品功能

入门说明
异步的通信协议

腾讯云消息服务提供异步的通信协议。消息的发送者将消息发送到消息队列后可以立即返回,不用等待接收者的响应,消息会被保存在队列中,直到被接收者取出。

保证消息的传递

如果发送消息时接收者不可用,消息队列会保留消息,直到成功地传递它。

解耦

腾讯云消息服务降低了两个进程间的耦合度。只要消息格式不变,即使接收者的接口、位置或者配置改变,也不会给发送者带来任何改变;而且,消息发送者无需知道消息接收者是谁,使得系统设计更清晰;相反的,例如,远程过程调用(RPC)或者服务间通过 socket 建立连接,如果对方接口改变了或者对方 IP/端口改变了,那么另一方需要改写代码或者改写配置。

提供路由

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

队列模型(Queue)
消息推拉模式

PULL

丰富的队列功能

CMQ 提供了丰富的队列属性配置选项,您可以个性化配置队列属性来满足不同的应用场景,支持多次消费、批量发送消费、重试策略配置等。

支持并发访问

支持多个生产者和消费者并发访问同一个队列,无需特殊设置即可自由调整并发度,并能确保某条消息在取出之后的特定时间段内,无法被其他消费者获得。

消息并发发送及接收

支持批量并发发送和接收消息,提升业务的吞吐性能。

消息投递保障

在消息有效期内,确保消息至少能被成功消费一次。用户间资源隔离,确保您队列中的消息不会被非法获取。

支持多次消费

若应用程序在处理消息的过程中由于断电等原因处理失败,可多次重试。

主题模型(Topic)
消息推拉模式

PUSH

一对多消息投递

一条通知消息可以同时被多个订阅者订阅和消费,支持将某 Queue 设为订阅者。

多种投递方式

支持 HTTP/HTTPS 等多种投递方式。

消息过滤

可根据消息 TAG、订阅者 TAG 进行消费过滤,增加消费灵活性 。

消息投递保障

在消息有效期内,保证发布到 Topic 中的消息会按照指定的重试策略,进行多次重试投递,尽可能保证业务成功接收消息。

 

应用场景

消息永不丢失(微信)

红包系统的分布式事务性的问题让大家很头痛,微信架构组在红包系统引入了 CMQ,避免分布式事务增加对系统的开销。CMQ 红包队列,保证了红包消息的可靠存储、传递,实时落盘写三份保证数据不丢。资金入账失败时可多次重试,避免入账失败后 rollback 回写和频繁轮询 DB。

跨机房异步通信

腾讯云 CMQ 支持跨机房的数据交换能力,公司内部局域网也无须暴露在公网环境下,轻松实现企业 A 机房向企业 B 机房数据交换、同步的需求,同时支持消息传输过程中使用 KMS服务 加密消息。

厘米秀跨region异步双写高可用的场景:

  • 当主用 CKV、CMQ 存储所在机房故障时,及时发出告警,可以通过人工操作快速切换到跨城 CKV、CMQ 服务器,提供服务;
  • 主用CKV存储服务器恢复后,可以恢复一主一备。
实现高扩展性

CMQ 后端的集群对用户来说是透明无感知的,CMQ controller server 可根据集群的负载情况实时对 queue 进行调度搬迁。如果某个 queue 的请求量超过当前集群的服务阈值,controller server 可以将 queue 路由分布到多个集群上来提高并发量,理论上可以达到无限的消息堆积以及超高的 QPS,轻松应对业务需求。

阅文集团旗下的起点文学网,使用 CMQ 满足了 2 个核心需求:

  • 客户的促销系统,消费者入账的时候是异步的。入账信息先写到 MQ 里,消费者过来拉,且消费者确认已成功消费后,回调接口将 MQ 里的信息删掉。
  • 另一个场景是,起点文学网的各大系统,包括运维、告警、运营系统的日志流水,先聚合到 CMQ 中,后端的大数据分析集群按处理能力,不断到CMQ中拉取并分析。CMQ 理论上支持的消息堆积数量无上限,使用无后顾之忧。
同城容灾

CMQ 支持在金融机房下(2个可用区)分别部署两套 CMQ 集群(如深圳坪山、观澜),业务方可以根据实际需求将消息写入任意园区。

  • 消息 body 的存储,可根据业务特性选择,同步落盘(强一致性)、异步落盘(最终一致性)的不同策略。
  • 当主节点 MQ 数据彻底丢失时,主备节点的 RPO 在 5min 以内。腾讯云提供 failover、failback 切换的 API 接口,将灾难恢复、切换的控制权交给客户。准备切换后,存在数据的差异,可关联其他 DB 做对账等处理,补回数据。

金融级的容灾方案为 Webank、财付通等核心业务保驾护航。