字节跳动各产品线需要处理海量实时数据。消息队列设计考察候选人对分布式系统基础、分区策略和可靠性权衡的掌握程度。字节内部也有自研的BMQ等消息中间件来满足独特的规模需求。
明确需求：吞吐量（百万级QPS）、延迟（P99 < 10ms）、持久化保障和消费组语义。
描述由Broker、分区和副本组成的架构——说明分区如何实现吞吐量的水平扩展。
讲解存储层：追加写日志分段、零拷贝传输、页缓存优化和冷热分层存储。
阐述可靠性机制：ISR同步副本集、生产者确认模式、消费位点管理和死信队列。
我会采用分布式Broker架构。每个Topic被切分为多个Partition，分布在不同Broker节点上以实现吞吐量水平扩展。生产者根据消息Key哈希选择目标分区，并通过批量发送和压缩来最大化吞吐。存储引擎每个分区使用追加写的提交日志，利用顺序写磁盘和操作系统页缓存获得高性能。为保证持久性，每个分区可配置多副本，采用Leader-Follower模型。消费组支持并行消费——每个分区只分配给组内一个消费者。我会实现一个基于一致性协议的协调服务来负责分区分配和Leader选举。针对字节的规模需求，还需加入冷热分层存储、零拷贝sendfile网络传输和自适应批量策略来平衡延迟与吞吐。
如果了解字节内部的BMQ系统可以主动提及，展示你对公司技术栈的研究。
量化权衡：解释不同的确认模式如何在延迟和持久性之间做取舍。
讨论运维层面的考量，如分区再平衡、Broker故障恢复和监控告警。
虽然借鉴了Kafka的日志式设计，但字节规模的系统还需要冷热分层存储、更激进的批量策略、自定义内存管理以避免GC停顿，以及和内部RPC框架的深度集成。
通过幂等生产者（每分区维护序列号）、跨分区原子写入的事务机制，以及消费端基于已提交位点和防护令牌的去重来实现。