RocketMQ 是一款高性能，高吞吐量，低延迟，高可用，高可靠的分布式消息中间件
RocketMQ架构
RocketMQ角色
Producer，消息发送者
-
Consumer，消息接受者
- 消费者与 Broker Master ,Slave都建立连接
- 与NameServer 建立长连接
-
Broker,暂存和传输消息
- Broker对应一台服务器
- 指定相同的BrokerName表示集群 BrokerId 0表示master，非0表示slave
- 每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有 NameServer。
-
NameServer，管理Broker,无状态
- producer 与NameServer 保持长连接，定期从 NameServer获取 Topic路由信息,向Broker master写
- Consumer 与NameServer 保持长连接,定期从 NameServer获取 Topic路由信息. Consumer与Broker 保持长连接，从Broker master,slave1消费消息
- NameServer不去连接别的机器，不主动推送消息
- 单个Broker与所有NameServer 进行定时注册
Topic，区分消息的种类
Message Queue，Topic的分区,并行发送和接收消息
RocketMQ特性
- 订阅与发布，
- 消息的订阅是指某个消费者关注了某个topic中，带有某些tag的消息。
- 消息顺序
- 消息过滤，Broker端根据tag过滤
- 消息可靠性
- 至少异常，每个消息必须投递一次
- 回溯消费，时间维度回退消费进度
- 事务消息，应用事务和发送消息定义到全局事务中
- 定时消息，
- 消费重试
- 消息重投，可能会造成消息重复
- 流量控制
- 死信队列
消费模式
Push和Pull模式本质都是采用消费端主动拉取的方式，即consumer轮询从 broker拉取消息。
- pull模式
- Push方式里，consumer把长轮询的动作封装了，并注册MessageListener监听器，取到消息后， 唤醒MessageListener的consumeMessage()来消费
- 优点实时性高，缺点消费者处理能力有限，造成消息堆积
- push模式
- 优点主动权掌握在消费端自己手中，根据自己的处理能力量力而行；缺点就是如何控制Pull的 频率。
安装
mqnamesrv
mqbroker -n localhost:9876
高级特性
提高Consumer的处理能力
- 提高消费并行度，增加Consumer实例
- 以批量方式进行消费，设置Consumer的 consumeMessageBatchMaxSize这个参数
- 检测延时情况，跳过非重要消息
消息存储
顺序写可以达到 600MB/s,RocketMQ采用顺序写入
- CommitLog：消息主题及元数据的存储主体
- ConsumeQueue: 逻辑消费队列，提高消息消费的性能。ConsumeQueue 作为消费消息的索引
- 8个字节的 CommitLog物理偏移量
- 4字节的消息长度
- 8字节 tag hashCode
- IndexFile: 根据key或时间区间查询消息，底层文件系统实现了 HashMap结构
同步复制和异步复制
同步复制
同步复制方式是等Master和Slave均写 成功后才反馈给客户端写成功状态；在同步复制方式下，如果Master出故障，Slave上有全部的备份数据，容易恢复，但是同步复制会 增大数据写入延迟，降低系统吞吐量。异步复制
异步复制方式是只要Master写成功 即可反馈给客户端写成功状态。在异步复制方式下，系统拥有较低的延迟和较高的吞吐量，但是如果Master出了故障，有些数据因 为没有被写 入Slave，有可能会丢失；
消息重试
- 顺序消息 消费失败，消费队列会每秒重试一次，应用出现消息消费阻塞
- 无序消息 消费失败，设置 ConsumeConcurrentlyStatus.RECONSUME_LATER 返回状态达到重试效果，只对集群消费生效，广播方式无效。
死信队列
RocketMQ中消息重试超过一定次数后（默认16次）就会被放到死信队列中
- 一个死信队列对应一个 Group ID， 而不是对应单个消费者实例。
- 一个死信队列包含了对应 Group ID 产生的所有死信消息，不论该消息属于哪个 Topic。
顺序消息
部分有序
- 发送要把同一业务ID的消息发送 到同一个Message Queue
- 消费过程中，要做到消费者从同一个Message Queue 消费消息。消费端通过使用MessageListenerOrderly
事务消息
2阶段提交
- 一阶段事务消息对用户不可见对消息的Topic和Queue等属性进行替换， 同时将原来的Topic和Queue信息存储到Half消息的属性中，
- Commit和Rollback操作以及Op消息的引入，Op消息标识 事务消息已经确定的状态（Commit或者Rollback）
- Op消息的存储和对应关系，Op消息的内容为对应的Half消息的存储的Offse
- Half消息的索引构建，二阶段构建索引时需要读取出Half消息，并将Topic和Queue替换成真正的目标的 Topic和Queue
NameServer作用
- NameServer 用来保存活跃的 broker 列表，包括 Master 和 Slave 。
- NameServer 用来保存所有 topic 和该 topic 所有队列的列表。
- NameServer 用来保存所有 broker 的 Filter 列表。
- 命名服务器为客户端，包括生产者，消费者和命令行客户端提供最新的路由信息。
