参考 https://github.com/apache/rocketmq/tree/master/docs/cn
RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。
Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。
Message Queue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中。
ConsumerGroup 由多个Consumer 实例构成。
RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。
同步和异步方式均需要Broker返回确认信息，单向发送不需要。
消息的发布是指某个生产者向某个topic发送消息；
消息的订阅是指某个消费者关注了某个topic中带有某些tag的消息，进而从该topic消费数据。
- 全局顺序 对于指定的一个 Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费。 适用场景：性能要求不高，所有的消息严格按照 FIFO 原则进行消息发布和消费的场景
- 分区顺序 对于指定的一个 Topic，所有消息根据 sharding key 进行区块分区。 同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。 Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 Key 是完全不同的概念。 适用场景：性能要求高，以 sharding key 作为分区字段，在同一个区块中严格的按照 FIFO 原则进行消息发布和消费的场景。
4 消息可靠性 RocketMQ支持消息的高可靠，影响消息可靠性的几种情况： Broker非正常关闭 Broker异常Crash OS Crash 机器掉电，但是能立即恢复供电情况 机器无法开机（可能是cpu、主板、内存等关键设备损坏） 磁盘设备损坏 1)、2)、3)、4) 四种情况都属于硬件资源可立即恢复情况，RocketMQ在这四种情况下能保证消息不丢，或者丢失少量数据（依赖刷盘方式是同步还是异步）。 5)、6)属于单点故障，且无法恢复，一旦发生，在此单点上的消息全部丢失。RocketMQ在这两种情况下，通过异步复制，可保证99%的消息不丢，但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极高的场合，例如与Money相关的应用。注：RocketMQ从3.0版本开始支持同步双写。
生产者在发送消息时，同步消息失败会重投，异步消息有重试，oneway没有任何保证。
11 流量控制 生产者流控，因为broker处理能力达到瓶颈；消费者流控，因为消费能力达到瓶颈。 生产者流控： commitLog文件被锁时间超过osPageCacheBusyTimeOutMills时，参数默认为1000ms，返回流控。 如果开启transientStorePoolEnable == true，且broker为异步刷盘的主机，且transientStorePool中资源不足，拒绝当前send请求，返回流控。 broker每隔10ms检查send请求队列头部请求的等待时间，如果超过waitTimeMillsInSendQueue，默认200ms，拒绝当前send请求，返回流控。 broker通过拒绝send 请求方式实现流量控制。 注意，生产者流控，不会尝试消息重投。 消费者流控： 消费者本地缓存消息数超过pullThresholdForQueue时，默认1000。 消费者本地缓存消息大小超过pullThresholdSizeForQueue时，默认100MB。 消费者本地缓存消息跨度超过consumeConcurrentlyMaxSpan时，默认2000。 消费者流控的结果是降低拉取频率。
12 死信队列 死信队列用于处理无法被正常消费的消息。当一条消息初次消费失败，消息队列会自动进行消息重试；
达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。 RocketMQ将这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），将存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）。
在RocketMQ中，可以通过使用console控制台对死信队列中的消息进行重发来使得消费者实例再次进行消费。