广播

场景：分级通知

根据不同的用户角色，订阅不同的主题，推送时订阅了对应主题的用户才能收到该主题的相关信息，可以达到分级推送通知的效果。

作用于以群体为单位，批量操作。

----------------------------------------

消息通讯

场景：点对点会话、组群会话

利用queue及topic分别进行消息传递

queue：生产者发布、消费者接受、消息被消费后不再存储。

注意，消费者可能存在多个，但是消息只能被一个消费者消费，多个消费者消费的时候会根据负载均衡传递到单个消费者上

topic：生产者发布、消费者订阅接收(所有已订阅的消费者都会得到消息的副本)

----------------------------------------

场景：一对多系统同步数据

业务上数据同步/传输涉及多个系统对接的时候，可以把数据放入消息队列中，再由处理程序单独处理。这样一来不会由于某个对接系统异常而拖垮生产系统，业务系统扩展性也大大增加

----------------------------------------

场景：用户注册发生验证码流程

一般注册流程都是，用户提交注册信息后，接口就要生成验证码、入库、发送验证码(各种方式)，发送验证码的流程都需要网络请求的时耗。

所以在这里缓存消息队列过渡，把消息放进队列，交由对应的处理程序去处理发送验证码的逻辑，就会大大减少注册发送验证码等待的时间。

----------------------------------------

场景：商城秒杀等高并发场景

这里的做法跟一般的秒杀系统大同小异(只作可用性说明、不做对比)，一般常用做法都是用缓存(Redis、MongoDB)用来限制商品库存，一旦被库存清空则自动转跳错误页。

该场景下，请求进来的时候只要判定队列长度已满则抛弃用户请求or转跳到对应页面即可，后续则交由对应程序处理队列中的消息。

----------------------------------------

场景：业务系统日志采集

没错，这个流程图还是异步处理的图片，只是这个场景日常使用比较多，所以单独讲解。其实用户的每次请求、数据库操作日志等等的每条日志都是有分析的价值，除了对错误排查、优化系统有帮助之外，还可以对用户行为进行分析。

这做不仅仅为了加快系统效率，直接把日志放到消息队列进行处理，而且目前很多主流的日志分析、分析程序已消息队列的形式对接起来也比较方便。