189 lines
9.3 KiB
JSON
189 lines
9.3 KiB
JSON
|
{
|
|||
|
|
"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": []
|
|||
|
|
}
|
|||
|
|
]
|
|||
|
|
}
|