分布式消息队列（MQ）的应用场景

分布式消息队列（MQ）的应用场景说明1

• 服务解耦
  • 服务之间强依赖：同步dubbo调用、同步HTTP调用，比如spring cloud、GRPC。
  • 服务之间弱依赖：消息中间件
    • 弱依赖调用也不能失败，则在上游做一个可靠性投递。
• 削峰填谷
  • 把流量的高峰和低谷的速率做一个平衡。MQ最早期就是做这么一件事情。
  • 当下游服务处理不过来的时候，可以把缓存到一个地方，然后慢速去消费，这就是削峰。
  • 即时性很高、流量很大的场景，比如秒杀大促。
  • 大促不可能持续的时间很长，比如说双十一大促，可能持续半小时一小时，后面相对而言就比较平稳了，可以把大促开始的消息积压到囤积到MQ中，慢慢去做一个消费，这也是可以的。
• 异步化缓冲
  • 有些业务逻辑可以做异步操作，只需要做到最终一致性即可，不需要做到实时强一致性。

分布式消息队列（MQ）的应用场景说明2

• 消息驱动
  • 跨系统异步通信
  • 应用解耦
    • 下单生命周期。支付、订单履约、配送这些在下单接口做负担很大，新加入返券功能还得改下单接口。
    • 这种场景可以通过消息驱动的模式完美解决。下单接口只需要推送一条消息到消息中间件中，如果下游应用需要在下单后进行其他的业务流程，只要订阅这个消息主题就可以。
    • 下单这个上游应用并不需要知道哪些下游应用需要对接，只需要简单发送一个消息就可以了。
  • 流量削峰
    • 电商秒杀，东西少，抢的人多。瞬时流量大，服务器扛不住，把用户的下单请求放到消息队列中，让消费者也就是处理下单请求的服务器主动拉取下单消息。
    • 在这种情况下下单请求并不是强行推送给下单服务器，而是业务服务器根据自己的能力主动从队列中领取消息。

分布式消息队列（MQ）应用思考点

高可用解决方案：HaProxy（High Available）、Keepalived

可靠性解决方案：replicate 分片副本（Kafka、Elasticsearch、Redis Cluster）

• 生产端可靠性投递
  • 比如金融领域
• 消费端幂等
  • 不能让消息消费多次
• 高可用
  • broker 宕机、磁盘不可用
• 低延迟
• 消息可靠性
  • 消息在MQ肯定不会丢失，磁盘损坏等
• 堆积能力
  • 消息在高峰期能堆积到什么程度
• 扩展性
  • 天然无感知横向扩容