1. rocket mq 总结

# 生产者
1. 生产者重试,rocketMQ 服务端支持幂等吗?
2. 生产者两种发送方式。
异步发送:调用线程不会阻塞,但调用结果会通过回调的形式,以异常事件或者成功事件返回。
同步发送:调用线程阻塞等待发送结果。
3. 生产者发送的消息结构。
主题:topic。
标签:消息的标签,用于进一步分类消息,支持在消费时进行标签过滤。
唯一键:业务标识,用于幂等、方便查询和追踪。
消息体:业务数据。
用户自定义属性:一个键值数据结构。
4. 生产者发送消息到 broker 的3种ack级别。由低到高,可靠性增强,但是吞吐量降低。
不等待服务端 broker 确认。
等待服务端 master broker 确认。
等待服务端 master broker 和 slave broker 都确认。

# 服务端
5. broker 的刷盘机制
同步刷盘:只有当消息被成功写入磁盘后,Broker 才返回确认给生产者(确保消息持久化)。
异步刷盘:消息首先写入内存,然后异步写入磁盘(性能高但有数据丢失的风险)。
6. broker 与 topic 的关系。
Topic 是消息的逻辑分组单位。
Broker是负责存储、传递和查询消息的服务器。一个 RocketMQ 集群由多个 Broker 组成,每个 Broker 又可以划分为主(Master)和从(Slave)。
一个 Topic 的队列可以分布在不同的 Broker 上,用来实现高可用性和负载均衡。

# 消费者
7. 消费者消费消息有两种模式:
拉取:消费者主动从 broker 拉消息。
优势:流量控制:消费者可以精确控制消息的拉取和处理速率,避免过载。
劣势:有一定延迟。
推送:broker 推送消息到 consumer。
优势:低延迟。
劣势:容易造成 consumer 过载。
8. 如果有个消息一直消费失败,会影响后续的消息消费吗?
一般情况下不会,因为会发回重试队列。但是发回重试队列失败,会影响后续消息消费。
9. 重试消息有单独的队列吗
有。
10. 消费者超时是谁来控制的。
消费者自己来控制的。
11. rebalance 触发时机:
消费者数量变更 或者 队列数量变更。具体来说:
消费者周期性地向 Broker 发起心跳请求,并获取当前消费者组内所有活动消费者,如果消费者数量变更,则 rebalance。
消费者会定期查询 NameServer 以获取主题的最新路由信息,从而知道该主题的消息队列的变化情况。如果队列数量变更,则 rebalance。
12. rebalance 是哪个角色负责的?
消费者。
13. rebalance 具体流程:
检测到变化 -> 获取最新消费者列表 -> 获取最新队列列表 -> 重新分配消息队列 -> 更新本地消费状态。

# 总结
14. 丢消息的原因
生产者发送消息到 broker 阶段,采取低级别的 ack 策略,消息未同步到 slave broker,同时 master broker 崩溃。
broker 采取异步刷盘机制。消息未保存到磁盘,broker 崩溃。
生产者端业务逻辑写的有问题。比如发送消息后,不处理超时异常、错误处理。

15. 重复消费消息的原因
只要消费者拉取后,没有向 broker 提交位移,就会重复消费。比如:
消费者重启。
网络等原因,发送 ack 失败。
消费者处理较慢,超过了设置的最大超时时间。
rebalance。消费者在 Rebalance 前处理了部分消息,但未及时向 Broker 提交消费进度。Rebalance 后,新的消费者可能从上次提交的进度位置开始消费,导致已经处理的消息被重复消费。
生产者重复发送消息。比如第一次发送消息超时,会重试发送。