字节广告平台二面面经

《面试题目》

1. 在海量流量和百万级广告量场景下，如何设计内存占用小、查询效率高的数据结构或架构，避免用户频繁刷到看过的广告？
2. 这种方案下，需要为每个用户都维护一个 RoaringBitmap 吗？
3. 如果广告量级达到百万级，这个结构怎么支撑？
4. 如果使用 ZSet，Key 是广告 ID 的话，用户维度的信息该如何存储？
5. 如果 Key 包含用户 ID 和日期，具体的广告信息要怎么存、怎么做判重？
6. 如何实现 LRU 缓存机制？
7. 你平时写 Go 语言多还是 Java 语言多？先讲一下整体设计思路。
8. 请详细解释一下 LRU 实现中 Put 方法的逻辑。
9. 如果有一个基于 RAG 的 Agent，在实际业务中会通过哪些方式提升效果和召回质量？
10. Kafka 是如何进行负载均衡的？
11. 如果消费端的消费者实例部分宕机，Kafka 的负载均衡机制会发生什么变化？

《参考解析》

1. 广告频控与去重：按用户和时间窗口记录已曝光广告，使用压缩位图、分片集合或布隆过滤器降低存储开销。在线判重只保留必要窗口，历史数据异步过期；对需要精确去重的场景，用分片 KV 存储记录广告 ID 并设置 TTL。
2. RoaringBitmap 取舍：不一定要给每个用户长期维护一个完整位图。可以按活跃用户和时间窗口懒创建，并对广告 ID 做分片；低频用户使用压缩集合或布隆过滤器，热点用户再升级到位图。
3. ZSet 与用户维度：用户维度应进入 key 或哈希字段，例如按用户和日期分片保存曝光记录，而不是让广告 ID 单独充当全局 key。写入时通过成员唯一性和 TTL 控制窗口，必要时用 Lua 脚本保证判重与写入原子化。
4. LRU 缓存：用哈希表实现 O(1) 的键查找，用双向链表维护访问顺序。命中或更新时把节点移到表头，插入新节点也放在表头；容量超限时删除表尾节点并同步从哈希表移除。
5. RAG 效果优化：先建立可评测的数据集，分别观察召回率、准确率和答案引用完整性。通过改进文档清洗与切分、混合检索、重排、查询改写、权限过滤和上下文压缩提升质量，并用离线评测与线上反馈迭代参数。
6. Kafka 负载均衡：生产者根据分区器把消息分配到各分区，分区在 Broker 间分布；同一消费组内每个分区只分配给一个消费者。消费者数量和分区数共同决定并行度，分区是吞吐扩展的基本单位。
7. 消费者宕机与 Rebalance：协调者检测到成员离开后触发重平衡，把宕机消费者负责的分区重新分配给存活实例。重平衡期间消费可能短暂停顿，恢复后从已提交 offset 继续；应设置合理的心跳、会话超时和幂等消费逻辑，降低重复处理影响。