{ "topic": "message-queue", "type": "fill_blank", "schema_version": "1.0.0", "generated": "2026-09-09T16:12:31+08:00", "questions": [ { "id": "fb-001", "type": "fill_blank", "difficulty": 1, "tags": [ "kafka", "durable" ], "question": "Kafka 中消息被追加到 Topic 的______末尾，这种写入方式被称为______写。", "answer": [ "partition", "append-only" ], "answer_rule": "all", "explanation": "Kafka 中 Topic 是逻辑概念，实际数据存储在 Partition（分区）中。每个 Partition 本质上是一个有序的、不可变的消息序列，新消息只能追加到末尾（append-only），这种顺序写方式极大减少了磁盘寻址开销，是 Kafka 高吞吐量的核心设计之一。", "source": null, "related": [] }, { "id": "fb-002", "type": "fill_blank", "difficulty": 2, "tags": [ "rocketmq", "transactional-message" ], "question": "RocketMQ 事务消息采用______消息机制：先发送半消息（Half Message）给 Broker，本地事务执行成功后再发送______（Commit/Rollback）指令，Broker 据此决定是否投递该消息。", "answer": [ "two-phase", "commit" ], "answer_rule": "all", "explanation": "RocketMQ 的事务消息基于两阶段提交思想。第一阶段发送 Half Message，此时消息对消费者不可见；第二阶段根据本地事务执行结果发送 Commit（提交，消息投递）或 Rollback（回滚，消息丢弃）。若 Broker 长时间未收到第二阶段指令，会主动回查生产者本地事务状态，确保最终一致性。", "source": null, "related": [] }, { "id": "fb-003", "type": "fill_blank", "difficulty": 2, "tags": [ "kafka", "durable", "zero-copy" ], "question": "Kafka 利用操作系统的______系统调用实现零拷贝技术，将磁盘文件数据直接传输到网络 Socket，避免了用户态与内核态之间的数据拷贝。", "answer": [ "sendfile" ], "answer_rule": "all", "explanation": "零拷贝（Zero-Copy）是 Kafka 高性能消费的关键技术。传统 I/O 需要经历：磁盘→内核缓冲区→用户缓冲区→内核 Socket 缓冲区→网卡，涉及多次拷贝和上下文切换。Kafka 通过 sendfile 系统调用，让数据直接从 PageCache 传输到网卡，仅需一次内核态操作，显著降低了消费延迟和 CPU 开销。", "source": null, "related": [] }, { "id": "fb-004", "type": "fill_blank", "difficulty": 2, "tags": [ "dead-letter-queue" ], "question": "当消费者连续消费某条消息失败超过最大重试次数后，该消息会被投递到______队列，以避免阻塞后续正常消息的消费。", "answer": [ "dead-letter", "死信" ], "answer_rule": "any", "explanation": "死信队列（Dead Letter Queue，DLQ）是消息中间件中处理消费失败消息的重要机制。当消息消费失败次数超过配置的阈值（如 RocketMQ 默认 16 次重试），Broker 会将该消息转入死信 Topic。运维人员可以对死信队列中的消息进行人工排查、修复后重新投递或直接丢弃，防止问题消息无限重试阻塞消费流程。", "source": null, "related": [] }, { "id": "fb-005", "type": "fill_blank", "difficulty": 3, "tags": [ "kafka", "transactional-message" ], "question": "Kafka 事务机制中，生产者通过______ API 开启事务，所有跨分区的消息写入在该事务内是原子性的，即要么全部提交，要么全部回滚。", "answer": [ "initTransactions / beginTransaction" ], "answer_rule": "any", "explanation": "Kafka 事务支持通过 Producer 的 initTransactions() 方法初始化事务协调器，然后在 sendMessages 过程中调用 beginTransaction() 开启事务，最后通过 commitTransaction() 或 abortTransaction() 提交或回滚。事务消息通过 Transaction Coordinator 和 __transaction_state 内部 Topic 来管理事务状态，保证跨分区的原子性写入，实现 Exactly-Once 语义。", "source": null, "related": [] }, { "id": "fb-006", "type": "fill_blank", "difficulty": 3, "tags": [ "kafka", "cluster" ], "question": "Kafka 集群中，每个 Partition 有一个 Leader 和多个______副本。只有 Leader 处理读写请求，Follower 仅负责同步数据。当 Leader 宕机时，Controller 从满足条件的 Follower 中选举新 Leader。", "answer": [ "Follower", "follower" ], "answer_rule": "any", "explanation": "Kafka 采用 Leader/Follower 主从架构。ISR（In-Sync Replicas）是与 Leader 保持同步的副本集合。Controller（集群中的一个 Broker）负责管理 Partition 的 Leader 选举。当 Leader 宕机，Controller 优先从 ISR 中选择第一个存活的 Follower 作为新 Leader，保证数据一致性。若 ISR 全部不可用，根据 unclean.leader.election.enable 配置决定是否允许不同步的副本接管。", "source": null, "related": [] }, { "id": "fb-007", "type": "fill_blank", "difficulty": 3, "tags": [ "push-pull", "consumer-group" ], "question": "Kafka 消费者采用______模式获取消息，消费者主动向 Broker 拉取数据。当某个消费者组中某个消费者宕机时，Broker 会触发______，将该消费者的 Partition 分配给组内其他消费者。", "answer": [ "pull", "rebalance" ], "answer_rule": "all", "explanation": "Kafka 采用 Pull（拉）模式，消费者根据自身处理能力主动从 Broker 拉取消息，相比 Push 模式有更好的流量控制能力。当 Consumer Group 中有消费者加入或离开时，会触发 Rebalance（重平衡），重新分配 Partition 的消费归属。Rebalance 期间消费暂停，因此需合理设置 session.timeout.ms 和 heartbeat.interval.ms 来平衡故障检测速度与误判风险。", "source": null, "related": [] }, { "id": "fb-008", "type": "fill_blank", "difficulty": 4, "tags": [ "rocketmq", "kafka", "topic" ], "question": "RocketMQ 相比 Kafka，原生支持______机制，允许生产者在发送消息时附加 Tag，消费者可通过 Tag 过滤订阅感兴趣的消息，减少不必要的网络传输。", "answer": [ "Tag", "tag", "消息过滤" ], "answer_rule": "any", "explanation": "RocketMQ 在 Topic 之下引入了 Tag 概念，生产者发送消息时可设置 Tag（如 OrderCreate、OrderCancel），消费者订阅时通过 Tag 表达式（如 * 或 || 或 &&）过滤消息。Broker 端支持基于 Tag 的服务端过滤，减少消费者拉取无关消息。Kafka 则依赖消息 Key 或消息体内容在客户端侧过滤，原生不支持服务端 Tag 过滤。", "source": null, "related": [] }, { "id": "fb-009", "type": "fill_blank", "difficulty": 4, "tags": [ "kafka", "durable" ], "question": "Kafka 的高性能写入依赖操作系统的______作为磁盘和网络之间的缓冲区。写入时数据先写入该缓存区，再由后台线程异步刷盘。若配置 acks=all 且______，则消息写入不会丢失。", "answer": [ "PageCache", "min.insync.replicas >= 2" ], "answer_rule": "all", "explanation": "Kafka 利用 PageCache（页缓存）实现高效的写入：生产者的消息先写入内核 PageCache，由 OS 后台线程异步刷盘（flush），避免同步 I/O 阻塞。配合 acks=all（所有 ISR 副本确认）和 min.insync.replicas >= 2 的配置，即使单个 Broker 宕机，只要 ISR 中还有其他副本持有数据，消息就不会丢失。这种设计在吞吐量和可靠性之间取得了平衡。", "source": null, "related": [] }, { "id": "fb-010", "type": "fill_blank", "difficulty": 5, "tags": [ "kafka", "pulsar", "transactional-message" ], "question": "Kafka 的 Exactly-Once 语义通过幂等生产者（Producer）和______机制结合实现：幂等 Producer 为每条消息分配序列号，Broker 据此去重；事务机制则保证跨 Partition 写入的原子性。在消费端，需配合手动提交______和幂等消费逻辑才能端到端保证不丢不重。", "answer": [ "transaction", "offset" ], "answer_rule": "all", "explanation": "Kafka Exactly-Once 语义（EOS）由三层保障实现：(1) 幂等 Producer（enable.idempotence=true）通过 Producer ID + Sequence Number 在 Broker 端去重单分区内重复消息；(2) 事务机制（Transactional API）保证跨分区原子写入；(3) 消费端需配合 consumer.commitSync() 手动提交 offset，确保消费与提交在同一事务中完成（配合 transactional.id），再结合业务幂等（如数据库唯一键）实现端到端 Exactly-Once。", "source": null, "related": [] } ] }