字节 AI 后端秋招二面：Redis、RAG 与预约系统设计

《面试题目》

1. 能否做一下自我介绍？
2. Java 为什么区分 int 与 Integer，各适合哪些场景？
3. HashMap 如何扩容？
4. JVM 垃圾回收有哪些流程、算法和回收器？
5. Spring IoC 解决什么问题，实际有什么好处？
6. AOP 是什么，动态代理怎样实现它？
7. Redis 可以解决哪些问题？
8. Redis 哈希的底层如何实现？
9. Redis 字典怎样处理哈希冲突和渐进式扩容？
10. Redis 有哪些持久化方式，AOF、RDB 与混合持久化有什么区别？
11. 生成 RDB 会不会阻塞服务，怎样处理生成期间的数据更新？
12. Redis 分布式锁如何实现？
13. 缓存穿透、击穿、雪崩有什么区别，如何处理？
14. 布隆过滤器是什么结构？
15. RocketMQ、RabbitMQ 的延迟消息怎样实现？
16. RAG 是什么，完整流程如何组织？
17. 如何从一千名学生中找出成绩前十名？
18. 小顶堆方案的时间复杂度是什么，能否使用快速选择？
19. 实习中做了什么，得到哪些成长？
20. 小程序预约功能有多少订阅用户，扫一次表耗时多久？
21. 大规模直播开播预约功能应如何设计？
22. 配置变更追溯方案如何设计和实现？
23. 数据库代理中间件中负责了哪些工作？
24. 基础服务如何保证可靠性，如何处理并发、幂等、写后读和定时任务竞争？
25. 功能发布时采用什么流程，怎样灰度和切流？
26. 代码生成器解决什么问题，如何评估生成结果可用？
27. 端到端验证如何开展，自动化与人工检查如何分工？
28. 回溯到对应阶段重新解析、校验的机制，解决什么问题，如何实现？
29. 几段实习方向不同，当时如何选择？
30. 如何在旋转有序数组中查找 target，找到返回下标，否则返回 -1？

《参考解析》

RDB 后台生成不等于零停顿

Redis 的后台保存通常通过 fork 创建子进程，由子进程写出快照；父进程继续服务，内存通过写时复制维持快照视图。创建子进程本身仍可能带来停顿，修改大量内存页也会增加内存开销。原帖追问中把它口述成“后台线程”，回答时应区分进程与线程。参见 Redis 持久化文档。

一千人选前十，用容量十的小顶堆

扫描成绩，堆未满就插入；堆满后只让比堆顶更高的成绩替换堆顶。扫描结束得到前十的集合，若需要名次，再对十个结果排序。扫描复杂度 O(N log K)，额外空间 O(K)。快速选择也能找出分界点，但需要能访问和交换数组元素，且应说明枢轴策略及最坏情况。

预约系统把登记与通知分开

订阅关系需要唯一约束，避免同一用户重复预约。开播后按分片读取订阅记录，分批投递通知任务，消费端按用户、场次和通知类型做幂等。还要考虑取消预约、过期任务、发送速率和失败重试。单次扫表多久，应来自真实数据量和测量，而不是按题目中的知名主播猜一个数。

RAG 的检索和回答分别验证

文档解析与切分后建立检索索引，查询时找出相关片段，再把片段和问题交给模型生成回答。可以用一组带出处的问题，分别观察相关内容是否被检索到，以及回答是否忠实于片段。检索没命中与命中后答错，是两类不同问题。

布隆过滤器只排除一定不存在的项

插入一个键时，用多个哈希结果定位位数组中的位置并置一；查询时，只要其中一位为零，就能判定未插入过。所有位置都为一时，只能说可能存在，因为不同键可能占用相同位置。普通布隆过滤器不能直接把删除项对应的位置清零，那会影响其他键。用于缓存穿透防护时，还要处理新增数据与过滤器更新的先后顺序。

配置追溯与生成代码验证各有验收点

配置变更记录可以包含变更前后内容、版本、操作人和生效时间，并将某次运行实际使用的配置版本关联起来。这样才能回答“这次故障发生时，用的是哪份配置”，而不只是展示一份修改日志。

代码生成器则应从真实输入样例出发，检查产物能否编译、接口调用是否符合契约、异常分支是否按预期处理。回溯重解析时，保留失败阶段、输入和诊断信息，将问题交回对应阶段修正，并限制无结果的重复循环。这里是答题思路，原帖没有披露实习系统的具体实现。

旋转数组二分先找有序的一半

在元素互不相同的前提下，每次取中点，左右至少一半有序。判断 target 是否落在有序半区的取值范围内，决定保留哪一半，时间复杂度 O(log N)。若允许大量重复元素，仅凭端点可能无法判断有序方向，需要额外收缩边界，最坏会退化到 O(N)。

作者记录的反问反馈是知识广度尚可，回答深度仍需加强；这属于该次面试的反馈，不代表最终录用结果。