RocketMQ笔记

写在前面

本文参考OSChina和rocketMQ官方文档整理而成，我也是初学rocketMQ，欢迎各位在评论区指正，
转载请注明来源

rocketMQ架构

转自OSChina

NameServer

可集群，一台NameServer挂掉之后，另一台顶上充当路由表作用，各个NameServer之间没有直接关联，broker集群发送心跳包同时向NameServer集群中的每一个节点发送（意味着各个节点的路由表是实时同步的）
1.主要功能：

• 路由router，producer和consumer通过NameServer找到对应的Broker（根据topic来查找对应的broker），如果路由表发生更新，NamerServer会及时通知相应的producer和consumer。
• 包含broker集群的信息，如果broker集群中的任意一台机子发生问题，将通过心跳包及时通知NameServer

producer

1. 工作机制：
   producer定期从NameServer获取可用的Topic路由信息，并缓存至本地，包括可用的broker列表。当 producer需要发送消息时根据路由表选择一个broker，根据某种发送策略将消息发送至该broker中。如果NamerServer挂掉，producer就使用本地的路由表查找broker，如果在NameServer挂掉的情况下重启producer，那么就没有路由信息，也就无法发送消息了。
   生产者将产生的消息投递到对应的broker上，生产者是无状态的，不可以集群，但可以分组（一个组只允许一个producer实例存在）
2. 发送方式：

• 同步发：一直等到broker的响应（返回一个sendResult包含发送状态）
• 异步发：调用callback函数处理broker的响应（返回一个sendResult包含发送状态）
• 单向：只发不接受响应，适用于对消息可靠性要求不高的场景（如发送日志）

3. 发送状态：

• FLUSH_DISK_TIMEOUT：broker配置了FlushDiskType策略，并且在默认时间内没有完成刷新磁盘返回该状态
• FLUSH_SLAVE_TIMEOUT：broker配置了SYNC_MASTER，但从服务器没有在规定刷盘时间内与主服务器完成同步
• SLAVE_NOT_AVAILABLE：broker配置了SYNC_MASTER，但是没有配置从服务器
• SEND_OK：表示成功，但是并不意味着他可靠，如果想要得到可靠信息，需给broker配置SYNC_MASTER

4. 关于消息重复发送（Duplication）和消息丢失
   如果获得的sendResult是 FLUSH_DISK_TIMEOUT或者FLUSH_SLAVE_TIMEOUT，那么就意味着broker在那一时刻可能停止运行了，此时有两种做法：1. 什么也不做 2. 消息重发
5. 超时
   producer发送完消息直到broker返回响应中间等待的时间如果超出等待时间（默认为3秒，支持自定义），会抛出Remoting TimeoutException。并不建议将等待时间调的过短，因为broker需要将消息写入磁盘或者与从从服务器进行同步，

consumer

通过NameServer拿到路由表并缓存至本地
消费者，并发的从消息队列中取消息，随之而来的问题就是消息的顺序问题（比如必须要创建订单之后，才能确认订单，最后支付订单），rocketMQ完美支持消息顺序问题。
消费者也可以成组，但是一组必须订阅相同的topic。

1. 获取消息的方式：

• pull consumer: 主动从broker中的消息队列中拉取消息
• push consumer: 当消息到达时，调用callback函数进行处理

2. MessageListener

• Orderly：保证消息被顺序消费
• Concurrently：不保证消息被顺序消费，并发消费队列中的消息

3. Consume Status

• RECONSUME_LATER：Consumer可能正在消费其他队列，稍后再消费当前队列
• SUSPEND_CURRENT_QUEUE_A_MONENT：保证消费队列中被消费的顺序，告诉Consumer等待当前消息被消费完毕之后再消费其他消息

4. ConsumeFromWhere
   当一个新的Consumer被加入后，它需要根据如下策略选择性的消费

• CONSUME_FROM_OFFSET_LAST：只消费producer新产生的消息，Consumer加入之前所产生的消息都不再进行消费
• CONSUME_FROM_OFFSET_FIRST：将队列中的所有消息从头开始消费一遍
• CONSUME_FROM_TIMESTAMP：消费在指定时间戳之后产生的消息

5. 重复消费的问题
   出现场景：

• 消息重复发送
• Consumer挂掉但是broker那边并没有更新consumer消费的offset

broker

broker负责存储队列信息，维护消费进度，定时向NameServer上报topic路由信息。

1. 配置策略：
   ASYNC_MASTER with SLAVE：可以容忍消息丢失，但要保证broker的高可用
   SYNC_MASTER with SLAVE：强制主从服务器同步刷新，这样做会丢失相当一部分性能，但是换来的是消息的绝对可靠性（不会丢失消息）
   ASYNC_MASTER：适合简单上手
2. 容错机制：
   如果一台broker挂掉，那么producer不会立即感知，而是NameServer发现该broker心跳超时的时候，会将该broker从broker集群中清除并且告知相应的producer该broker已经挂掉，那么producer会重新选择一个broker；如果在broker挂掉这一段时间内producer已经发送消息给broker，由于producer内部有重试机制（如果发送到某个broker失败，那么会重新选择新的broker发送），最终消息还是会发送到一个新的broker上，不会造成消息的丢失。
3. 磁盘刷新类型：

• ASYNC_FLUSH：推荐使用该种方式进行刷新，如果需要保证消息可靠性，可配置SLAVE
• SYNC_FLUSH：每一条producer产生的消息到来之后，先将消息存储到硬盘之后再给producer返回响应，会造成相当一部分性能损失

Topic

producer产生的每个消息都必须指明该消息的Topic，consumer消费消息时就是通过查路由表找到对应的broker来获取消息的。
一个Topic可以被多个consumer group所消费