1. rocket mq 总结
# 生产者<br>1. 生产者重试，rocketMQ 服务端支持幂等吗？<br>2. 生产者两种发送方式。<br> 异步发送：调用线程不会阻塞，但调用结果会通过回调的形式，以异常事件或者成功事件返回。<br> 同步发送：调用线程阻塞等待发送结果。<br>3. 生产者发送的消息结构。<br> 主题：topic。<br> 标签：消息的标签，用于进一步分类消息，支持在消费时进行标签过滤。<br> 唯一键：业务标识，用于幂等、方便查询和追踪。<br> 消息体：业务数据。<br> 用户自定义属性：一个键值数据结构。<br>4. 生产者发送消息到 broker 的3种ack级别。由低到高，可靠性增强，但是吞吐量降低。<br> 不等待服务端 broker 确认。<br> 等待服务端 master broker 确认。<br> 等待服务端 master broker 和 slave broker 都确认。<br><br># 服务端<br>5. broker 的刷盘机制<br> 同步刷盘：只有当消息被成功写入磁盘后，Broker 才返回确认给生产者（确保消息持久化）。<br> 异步刷盘：消息首先写入内存，然后异步写入磁盘（性能高但有数据丢失的风险）。<br>6. broker 与 topic 的关系。<br> Topic 是消息的逻辑分组单位。 <br> Broker是负责存储、传递和查询消息的服务器。一个 RocketMQ 集群由多个 Broker 组成，每个 Broker 又可以划分为主（Master）和从（Slave）。<br> 一个 Topic 的队列可以分布在不同的 Broker 上，用来实现高可用性和负载均衡。<br> <br># 消费者<br>7. 消费者消费消息有两种模式：<br> 拉取：消费者主动从 broker 拉消息。 <br> 优势：流量控制：消费者可以精确控制消息的拉取和处理速率，避免过载。<br> 劣势：有一定延迟。<br> 推送：broker 推送消息到 consumer。<br> 优势：低延迟。<br> 劣势：容易造成 consumer 过载。<br>8. 如果有个消息一直消费失败，会影响后续的消息消费吗？<br> 一般情况下不会，因为会发回重试队列。但是发回重试队列失败，会影响后续消息消费。<br>9. 重试消息有单独的队列吗<br> 有。<br>10. 消费者超时是谁来控制的。<br> 消费者自己来控制的。<br>11. rebalance 触发时机：<br> 消费者数量变更 或者 队列数量变更。具体来说：<br> 消费者周期性地向 Broker 发起心跳请求，并获取当前消费者组内所有活动消费者，如果消费者数量变更，则 rebalance。<br> 消费者会定期查询 NameServer 以获取主题的最新路由信息，从而知道该主题的消息队列的变化情况。如果队列数量变更，则 rebalance。<br>12. rebalance 是哪个角色负责的？<br> 消费者。<br>13. rebalance 具体流程：<br> 检测到变化 -> 获取最新消费者列表 -> 获取最新队列列表 -> 重新分配消息队列 -> 更新本地消费状态。<br> <br># 总结 <br>14. 丢消息的原因<br> 生产者发送消息到 broker 阶段，采取低级别的 ack 策略，消息未同步到 slave broker，同时 master broker 崩溃。<br> broker 采取异步刷盘机制。消息未保存到磁盘，broker 崩溃。<br> 生产者端业务逻辑写的有问题。比如发送消息后，不处理超时异常、错误处理。<br> <br>15. 重复消费消息的原因<br> 只要消费者拉取后，没有向 broker 提交位移，就会重复消费。比如：<br> 消费者重启。<br> 网络等原因，发送 ack 失败。<br> 消费者处理较慢，超过了设置的最大超时时间。<br> rebalance。消费者在 Rebalance 前处理了部分消息，但未及时向 Broker 提交消费进度。Rebalance 后，新的消费者可能从上次提交的进度位置开始消费，导致已经处理的消息被重复消费。<br> 生产者重复发送消息。比如第一次发送消息超时，会重试发送。来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！
页:
[1]