消息队列应用场景

主要应用场景 

• 削峰

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

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

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

• 解耦

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

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

•  日志传输

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

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

• 分布式事务一致性

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

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

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