腾讯音乐后台开发一面：50 分钟全程拷打项目，Kafka 一路问到操作系统

《面试题目》

1. 讲讲你的项目，重点讲你负责的部分和具体实现。
2. 这个项目的性能数据是多少？具体是怎么测出来的？
3. Kafka 这条链路在操作系统层面是怎么实现的？

《参考解析》

性能数据必须带口径：这种面试里「QPS 多少」只是开场，接下来一定是「多大消息、几条线程、几台什么规格的机器、压测工具是什么、测的是服务端还是端到端」。所以准备项目时要给每个数字配三样东西：测量方法（压测脚本、并发模型、预热时长、采样窗口）、环境（CPU 核数、内存、磁盘类型、网络带宽、是否同机部署）、口径（P99 还是均值、成功请求还是全部请求、含不含下游耗时）。答不出这些，数字就是编的，面试官会立刻转去问「那这个瓶颈你是怎么定位的」。

瓶颈定位要讲过程和取舍：常见追问是「压测到多少开始上不去、先看什么指标」。可用的叙述是：先看资源饱和度（CPU 的 us/sy/wa、内存与 GC、磁盘 IOPS 与 await、网卡带宽与重传），再看应用内部（线程池队列积压、锁竞争、连接池耗尽、序列化开销），然后做单变量验证（关掉某个下游、加大批量、换压缩算法），最后给出结论和代价。要能说出「优化后 P99 从多少降到多少、为此牺牲了什么」。

Kafka 深挖到操作系统层：链路按「生产者 → broker 落盘 → 消费者」讲。生产者侧批量攒消息（batch.size、linger.ms）减少系统调用与网络往返，压缩在客户端做；broker 侧消息顺序追加到分区日志文件，靠 page cache 承接写入，sendfile 让数据从页缓存直接送到 socket，省掉内核态与用户态的两次拷贝（零拷贝）；索引文件用 mmap 映射，查 offset 时不必 read 进用户缓冲。顺序写避开了机械盘寻道，SSD 上也减少写放大；分区让读写并行，副本同步走 FETCH 请求批量拉取。追问常落在「page cache 丢了会不会丢消息」——可靠性由副本与 acks 决定，不靠刷盘，flush.messages 调小反而伤吞吐。

被问「为什么用 Kafka」别只答解耦：要给出这个业务的具体理由——峰值削平、上下游速率不匹配、多消费方各自回放、还是为了跨团队解耦。再说清代价：消息重复与顺序问题、消费积压的监控与扩容、以及端到端延迟变大。能主动讲代价，说明你参与过选型而不是照抄架构。

没有八股意味着基础在项目里考：TCP、页缓存、文件系统、线程模型这些不会单独问，而是嵌在「为什么这么快」「消息怎么保证不丢」里。准备方式是把项目链路上每一跳都往下追两层，追到自己讲不清的地方就是会被问穿的地方。