1 使用场景

1.1 异步解耦

用户注册场景，一般需要创建用户，发送消息，赠送积分等流程。在没有MQ的情况下，流程耗时，影响消费者使用，并且创建用户登录需要处理多个流程，导致代码复杂。
使用MQ，发送创建用户消息，其他服务和业务监听消息，异步处理。注册场景只关注创建用户业务流程。

1.2 顺序消息

消息FIFO机制，可以保证消息顺序被消费。
例如订单创建，付款，发货业务场景，发货步骤必须在付款步骤后面，所以可以通过顺序消息，让同一个订单ID的步骤顺序执行。
例如数据同步场景，使用cannel同步binlog数据，同一个订单的数据回放需要保证顺序。

1.3 削峰填谷

秒杀，抢红包等高并发和高流量场景，通过MQ承载前端请求，后端服务根据自己的消费能力，消费数据，避免大流量场景，服务负载过高宕机。

1.4 缓存同步

淘宝双十一，一个商品在多个分会场上架。通过广播消息，将商品价格，上下架等消息，广播到各个分会场服务集群，进行缓存刷新，避免集中缓存IO和带宽的瓶颈。

1.5 延时消息

微信支付，支付宝支付等一些开放平台，需要等用户支付成功之后，把交易结果通知给对接平台，对接平台可能由于发布，网络等原因不可能永远总是收到回调结果通知。所以需要间隔一段时间，继续投递。这个场景可以使用延时消息，对接平台响应失败，继续投递。

2 相关概念

2.1 架构

rocketmq_architecture_1.png

  • NameServer：是Topic路由注册中心，支持Broker的动态注册与发现。包括两大核心功能。
    • Broker管理：
      • 接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。
      • 心跳检查机制，检查Broker是否存活。
    • 路由信息管理：
      • 保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。
      • Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费
  • Producer：通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递。
  • Consuemer：支持push推，pull两种模式对消息进行消费，同时也支持集群方式和广播方式的消费。