# 生产者
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 后，新的消费者可能从上次提交的进度位置开始消费，导致已经处理的消息被重复消费。
生产者重复发送消息。比如第一次发送消息超时，会重试发送。
