应用场景

• 削峰

引入腾讯云消息中间件 CMQ，将非即时处理的业务逻辑进行异步化。例如服务接收请求、处理请求和返回请求三个不同的业务逻辑。

引入 CMQ 后，当预约活动开始时，海量并发访问汹涌袭来：

• 所有客户的预约申请，页面均立即返回成功。客户便可关闭网页进行其他活动。预约码稍后推送到客户的邮箱/手机；
• 超过千万级别的注册、预约申请，先暂存在腾讯云 CMQ 消息队列集群；
• 后端服务进行处理，按照数据库实际的 select、insert、update 能力处理注册、预约申请；
• 处理成功后返回结果给用户。预约结束后，用户大约在5 - 30min内，都收到了预约码。

• 解耦

以电商的 IT 架构作为例子，在传统紧耦合订单场景里，客户在电商网站下订单（如买一台手机），订单系统接收到请求后，立即调用库存系统接口，库存减一；但这种模式存在巨大风险：

• 订单系统与库存系统强耦合，假如库存系统无法访问（升级、业务变更、故障等），则订单减库存将失败，从而导致订单失败；
• 传统的解决方案是服务间通过订单系统与库存系建立 socket 连接，但是如果库存系统的 IP/端口变更、增加库存系统的接收者，都需要订单系统进行修改；
• 短时间内大量的请求，对库存系统的 SQL，频繁查询库存，修改库存，库存系统负载极大；
• 用户的感受：订单失败，重试，依然失败，导致顾客流失。

• 事务

MQ解决分布式事务是这样做的，A服务保证消息发送成功，MQ保证消息不会丢失，B服务保证消息消费成功。会出现以下情况：

• A服务生产消息失败，回滚支付操作，业务回到最初状态，保证了一致性。
• A服务生产消息成功，完成支付操作，MQ宕机，MQ重启后，消息还存在，订单服务消费消息，完成修改订单操作。保证了一致性。
• A服务生产消息成功，MQ良好，订单服务消费消息失败。但是消息还存在，等订单服务重启后继续消费消息，保证了一致性。

以上就是分布式事务中的最终一致性：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

• 日志

日志处理是指将消息队列用在日志处理中，比如Kafka的应用，解决大量日志传输的问题。

• 日志采集客户端，负责日志数据采集，定时写受写入Kafka队列
• Kafka消息队列，负责日志数据的接收，存储和转发
• 日志处理应用：订阅并消费kafka队列中的日志数据 

技术选型

• RocketMQ

• Java语言编写的。
• 性能、稳定性和可靠性都是值得信赖，每秒钟大概能处理几十万条消息。
• 没有那么流行，与周边生态系统的集成和兼容程度要略逊一筹。

• RabbitMQ

• Erlang 语言编写的。
• 开箱即用的消息队列，非常容易部署和使用。
• 路由的规则也非常灵活，甚至你可以自己来实现路由规则。
• RabbitMQ 的客户端支持的编程语言大概是所有消息队列中最多的，如果你的系统是用某种冷门语言开发的，那你多半可以找到对应的 RabbitMQ 客户端。
• 性能比较差，大概每秒钟可以处理几万到十几万条消息，当大量消息积压的时候，会导致 RabbitMQ 的性能急剧下降。

• ActiveMQ

• 最老牌的开源消息队列，是十年前唯一可供选择的开源消息队列，目前已进入老年期，社区不活跃。
• 无论是功能还是性能方面，ActiveMQ 都与现代的消息队列存在明显的差距。

• ZeroMQ

• 不能称之为一个消息队列，而是一个基于消息队列的多线程网络库，如果你的需求是将消息队列的功能集成到你的系统进程中，可以考虑使用 ZeroMQ。

• Kafka

• 在数据可靠性、稳定性和功能性等方面都可以满足绝大多数场景的需求。
• Kafka 与周边生态系统的兼容性是最好的没有之一，尤其在大数据和流计算领域，几乎所有的相关开源软件系统都会优先支持 Kafka。
• 设计上大量使用了批量和异步的思想，这种设计使得 Kafka 能做到超高的性能。与 RocketMQ 并没有量级上的差异，大约每秒钟可以处理几十万条消息。
• Kafka 这种异步批量的设计带来的问题是，它的同步收发消息的响应时延比较高，因为当客户端发送一条消息的时候，Kafka 并不会立即发送出去，而是要等一会儿攒一批再发送。

• Redis

• 和很多专业的消息队列系统（例如Kafka、RocketMQ、RabbitMQ）相比，Redis的发布订阅略显粗糙。