系统解耦

紧耦合系统中，消费者出现任何问题（升级停服、宕机、不可用等），都会影响生产者的业务；

使用CMQ提供的松耦合服务，生产者无需了解消费者，消费者无需关心生产者，系统很方便地做到异步化。

削峰填谷

对于突发流量，数据可先堆积在CMQ server，消费者按照实际能力来消费，防止雪崩效应和消息丢失。

消息复用

数据生产一次并堆积到CMQ server，不同消费场景可多次复用。例如订单数据生产一次，逻辑、业务、计费、监控、统计模块都可以消费。

免费API

CMQ屏蔽了不同平台、不同编程语言的差异，提供标准API接入，使系统之间的数据交互变得非常简单。

数据交换

CMQ还支持机房的数据交换能力，无需打通企业A和B的内网，公司内部局域网也无须暴露在公网环境下，即可轻松实现企业A向企业B数据交换及同步。

架构说明

红包海量并发处理的场景下，若使用传统的事务处理方式，红包拆取失败时回滚且频繁轮询数据库，将会给系统造成并发压力甚至系统崩溃。微信红包系统引入了腾讯云CMQ，有效避免了分布式事务增加对系统所造成的开销。

以A用户向B用户发送10元红包为例。

定义三种角色：红包发送系统、CMQ红包队列、红包接收系统

• 红包发送系统执行：读取A账户余额、A账户减去10元、结果写回A账户
• 红包接收系统执行：读取B账户余额、拆取红包读取数值、B账户增加10元、结果写到B账户
• B账户更新余额失败时，红包入账失败的请求将转入CMQ，而手机客户端显示等待状态。账户系统将不断从CMQ拉取并重试此更新操作，直至红包金额被取出，从而保证红包入账永不丢失。

CMQ消息队列保证了红包消息的可靠存储、传递，实时写三份保证数据不丢。资金入账失败时可多次重试，避免失败回滚和频繁轮询数据库等传统方式的弊端。

架构说明

大数据入门的第一步，就是对海量数据进行挖掘分析，提炼有价值的结果，引导未来的商业模型。

大众点评、滴滴打车等企业在腾讯云已有深度的实践。

在数据处理的场景中，消息生产者是海量日志数据的输入，在线分析的Storm集群是消费者。从经验来看，消息消费端Storm处理消息的业务逻辑可能很复杂（涉及到实时计算、数据流式处理、Topology的数据处理）；且消息消费端Storm出现故障的概率较高，这种情况会导致短暂时间内无法消费或消费不畅。

Push方式下，由于无法得知当前消息消费者的状态，所以只要有数据产生便会不断进行推送。在Storm集群处于高负载时，使用Push的方式可能会导致消息消费者的负载进一步加重，甚至崩溃。

腾讯云CMQ提供PULL/PUSH两种数据获取方式，消费者可用并且准备好时才允许读取数据，为消息生产者与消息消费者之间加了一层缓冲区，缓解消息生产者与消息消费者之间不同步问题。

架构说明

某美图公司在腾讯云搭建了在线图片处理服务，该服务可以让用户上传照片，并指定需要对这些照片执行的操作，比如裁剪、生成缩略图等。用户上传图片后，提交任务，然后等待图片处理完，下载处理后的图片。不同的操作会耗费不同的处理时间，从几秒到几分钟不等，而且用户可能一次上传几张也可能是几十张甚至几百张图片，所以总的处理时间就与上传的图片数量、图片大小以及用户选择的操作有关。

利用CMQ实现上述需求，用户的图片存储在腾讯云存储中（CBS/COS等），用户的每一个操作请求都会作为一个消息存入请求队列（Request Queue）中，消息内容为图片索引，由图片名称+用户请求的操作类型+图片存储的位置索引key等组成。

运行在CVM的图片处理服务，从Request Queue中获取消息（图片索引），图片处理服务器从云端下载数据，并进行图片编辑，完毕后把处理结果发送到结果队列（Response Queue），结果图片存储到云存储中。