之前我们讲过rocketmq，这是一个消息队列，这次我们看看它的使用场景一般有哪些吧。
一、应用解耦(异步)
系统之间在进行数据交互的时候，我们会需要在时效性和稳定性之间进行选择。如果为基于线程的异步处理，那么用户体验就能解决，但有个问题是，在极端情况下系统有可能会出现异常，会极大的影响系统的稳定性，但同步调用大多时候又无法保证性能达到理想地步，这时我们就可以使用MQ来进行处理。如：上游系统把数据投递到MQ，下游系统取MQ中数据进行消费，其中，投递和消费可以使用同步的方式处理，因为MQ接收数据的性能是非常高的，不会影响上游系统的性能，同时MQ也能够保证下游系统的及时率。
二、通知
MQ中，下游系统会一直监听MQ数据，如若MQ有数据，下游系统就会按照”先进先出”这样的规则,一条条进行消费，然上游系统就只需把数据存入MQ里，酱就既降低了不同系统之间的耦合度，同时也确保了消息通知的及时性，且也不影响上游系统的性能。
三、限流
我们知道MQ有一个非常重要的特性，MQ 中数据是只有一条数据在使用中。 那在很多存在并发，又对数据一致性要求高，且对性能要求也高的场景中MQ就能发挥大作用了。它不管多少流量进来，MQ都会让你遵守规则，排除处理，不会因为任何原因，导致并发。
四、数据分发
在MQ中，MQ的中间件一般都能够支持一对多或广播的模式，且它们都可以根据规则选择分发的对象。因此在上游的一份数据，和众多下游系统中，就可以根据规则选择是否接收这些数据了，这样扩展性会非常强。
五、消息中间件示例
例1：电商系统
消息队列会采用高可用，可持久化的消息中间件。如：Active MQ，Rabbit MQ，Rocket Mq。
(1)应用将主干逻辑处理完成后，写入消息队列。消息发送是否成功可以开启消息的确认模式。(消息队列返回消息接收成功状态后，应用再返回，这样保障消息的完整性)
(2)扩展流程(发短信，配送处理)订阅队列消息。采用推或拉的方式获取消息并处理。
(3)消息将应用解耦的同时，带来了数据一致性问题，可以采用最终一致性方式解决。比如主数据写入数据库，扩展应用根据消息队列，并结合数据库方式实现基于消息队列的后续处理。
例2：日志收集系统
分为Zookeeper注册中心，日志收集客户端，Kafka集群和Storm集群(OtherApp)四部分组成。
Zookeeper注册中心，提出负载均衡和地址查找服务
日志收集客户端，用于采集应用系统的日志，并将数据推送到kafka队列
Kafka集群：接收，路由，存储，转发等消息处理
Storm集群：与OtherApp处于同一级别，采用拉的方式消费队列中的数据
注明:以上文章中的上游和下游，在MQ中一般会叫做生产者(producer)与消费者(consumer)。
以上就是关于rocketmq使用场景的全部内容了，如果对你有所帮助的话并且你还需要了解更多有关Java架构师知识的话，就请多多关注我们网站吧。
推荐阅读：