- 消息队列使用场景：
- 异步解耦
异步解耦是消息队列RocketMQ的主要特点，主要目的是减少请求响应时间和解耦。将比较耗时而且不需要即时（同步）返回结果的操作作为消息放入消息队列。使用消息队列RocketMQ，只要保证消息格式不变，消息的发送方和接收方并不需要彼此联系，也不需要受对方的影响，即实现解耦。 - 削峰填谷
在秒杀或团队抢购活动中，由于用户请求量较大，导致流量暴增，秒杀的应用在处理如此大量的访问流量后，下游的通知系统无法承载海量的调用量，甚至会导致系统崩溃等问题而发生漏通知的情况。为解决这些问题，可在应用和下游通知系统之间加入消息队列RocketMQ - 消息的顺序收发
消息队列RocketMQ顺序消息为全局顺序：
对于指定的一个Topic，所有消息将按照严格的先入先出（FIFO）的顺序，进行顺序发布和顺序消费。 - 大规模机器的缓存同步
在某些网页数据实时变化的场景下，缓存技术便无法满足对数据的实时访问需求，多次的查询将会对页面打开速度产生影响。
使用消息队列RocketMQ的广播消费模式，那么这条消息会被所有节点消费一次，相当于把相关数据信息同步到需要的每台机器上，取代缓存的作用。
- 如上图所示，RocketMQ 主要包含以下四个组件：
(1)Nameserver: 负责维护集群内所有 Broker 的状态信息，包括 Topic 信息、Broker 节点信息等。
(2)Broker: 消息存储和消息传递的主要组件，负责接收生产者发送的消息并存储在磁盘上，同时也负责消费者订阅消息并将消息传递给消费者。每个 Broker 都可以存储多个 Topic的消息。
(3)Producer: 消息的生产者，负责将消息发送到指定的 Topic。
(4)Consumer: 消息的消费者，负责从指定的 Topic 消费消息。 - RocketMQ 的消息传递过程大致如下：
(1)生产者将消息发送到指定的 Topic，消息发送的过程有同步和异步的。
(2)Broker 接收到消息后，将消息存储到指定的 Topic 中，同时将消息的索引信息写入 CommitLog 文件，以确保消息不会丢失。
(3)消费者从指定的 Topic 订阅消息，并从 Broker 拉取消息进行消费。
(4)消费者消费消息成功后，向 Broker 发送确认消息。
(5)Broker 收到确认消息后，更新当前Consumer的消费进度（CommitLog的offset），保证当前消息不会再次被当前Consumer消费。
