百度后端开发岗面经 11：五场面试问题合集

《面试题目》

1. 请做一下自我介绍，并介绍主要技术栈
2. C++ 和 Java 在开发与内存管理方面有什么区别？
3. C++ 指针和智能指针分别是什么？
4. 什么是字节序？
5. 如何设计一个支持多次搜索的搜索平台？
6. 什么场景需要使用 Elasticsearch，为什么 Elasticsearch 搜索速度快？
7. 搜索平台还可以如何优化？
8. Java 中有哪些哈希表实现，是否线程安全，如何保证线程安全？
9. Java 中是否有协程，虚拟线程是什么？
10. 协程和线程有什么区别？
11. 创建大量协程可能带来什么问题，协程执行 IO 操作时会怎样？
12. 嵌入式开发和后端开发有什么区别？
13. TCP 为什么会出现粘包和半包？
14. 是否了解 ARP 协议？
15. 如果用 C++ 实现即时通信系统，相比 Java 的难点是什么？
16. 介绍实习经历及根因定位 Agent 的实现与难点
17. 如何评测根因定位 Agent 的效果？
18. 是否了解 DeepSeek Harness 的实现，为什么采用“一切皆插件”的设计？
19. 算法：给定有序数组和整数 k，统计 k 在数组中出现的次数
20. 请做一下自我介绍
21. 为啥要这么去设计腾讯的服务了？
22. Redis 在里面的场景是啥？
23. 知道哪一些限流的方法？
24. 服务雪崩知道吗？追问：怎么做的？
25. Redis 的主从同步知道吗？
26. Redis 和 MySQL 的区别是什么？
27. 为啥我们要用 Redis？
28. 你知道我们在高并发的场景下，如何避免请求直接到 DB 吗？
29. 有哪一些实战的方法，有了解过吗？
30. MySQL 的主从同步咋做的？
31. Redis 和 MySQL 如何确保数据一致性，他们对这一块比较看重？
32. 延时双删为啥是 100ms？
33. 算法：统计 Top-K 高频元素
34. 自我介绍
35. Agent 里面你是如何做风险闭环的，如何判断用户意图？
36. Redis 和 MySQL 在这个 Agent 项目里面的用途
37. 实习项目：知识树查询的一致性和性能优化拷打
38. Redis 和 MySQL 的本质区别
39. Redis 的基本数据结构
40. Redis 大量 key 同时过期怎么解决？
41. 缓存和数据库双写一致性怎么保证？
42. 聚簇索引和非聚簇索引
43. MySQL 行锁、临键锁、间隙锁
44. Redis 的持久化方式
45. 比如设计一个秒杀系统，Redis 和 MySQL 怎么设计（限流、缓存一致性、缓存雪崩等）？
46. Redis 内存满了怎么办？
47. 自我介绍；追问：为什么用 Harness 来做 Agent？追问：为什么用多 Agent 来做？
48. 如果三个 Agent（简单的 Agent），你的意图路由是要做大模型决策还是硬编码决策？
49. HashMap 为什么线程不安全？
50. 什么是线程安全的（ConcurrentHashMap）？
51. 联合索引 a、b、c，那么查询 a=1、c=1 用到了索引吗？
52. 设计一个数据库的表，你会考虑什么？
53. 手撕最长不重复子串
54. 实习项目整体概述
55. 多 Agent 体系是全新创新设计，还是在原有方案上迭代优化而来？
56. 多级召回流程是否必须完整执行多轮检索，还是满足条件后可提前返回结果？
57. 上下文召回的核心依据与匹配规则是什么？
58. 项目中是否涉及 context engineering 相关技术方案？
59. 会话 Session 的生命周期与状态维护方案是怎样的？
60. 服务端限流采用了哪种限流算法与实现方案？
61. 项目中如何使用线程池进行异步任务处理？
62. 线程池核心线程数、最大线程数等参数的配置思路与调优依据是什么？
63. 分层向量检索场景，两类检索结果的权重配比策略如何设计？
64. 向量数据入库是单条逐笔写入，还是批量写入处理？
65. 公共知识库与用户私有知识库如何做数据隔离，如何避免跨库语义召回产生污染？
66. 当前单体项目如何改造，设计架构支撑高并发业务请求？
67. 高并发调用大模型接口触发限流时，有哪些降级、熔断、重试的处理方案？
68. WebSocket 与 SSE 两种通信协议，各自适用场景及选型依据是什么？
69. HashMap 底层数据结构实现？
70. 链表转换为红黑树的触发条件是什么？追问：是线程安全的吗？
71. ConcurrentHashMap 的线程安全实现原理是什么？

《参考解析》

1. 延时双删为什么是 100ms。更新数据库后先删一次缓存，等一小段时间再删一次，用来盖住「旧值在第一次删除后被并发读回填」的窗口。那 100ms 不是算出来的精确值，而是一个经验估计：它要覆盖一次读请求「查库 + 写缓存」的最长耗时。正确说法是「这个数字应该按主从同步延迟和业务读耗时来估，估不准就监控缓存与库的不一致率」，直接背 100ms 会被追问到底。

2. 大量 key 同时过期。同一时刻过期会在 Redis 上形成一次密集的删除事件，随后所有请求一起穿透到 MySQL，这就是缓存雪崩的一种形态。三种解法：给过期时间加随机抖动（基础 TTL 上叠加几分钟的随机量）把压力摊平；热点 key 用逻辑过期，值里带一个过期时间戳、物理上不设 TTL，由后台线程异步重建；再加一层互斥锁或 Singleflight，只放一个请求回源。

3. 联合索引 a、b、c 只查 a 和 c。能用到索引，但只用得上最左前缀的 a 这一列。联合索引 (a,b,c) 按 a、再 b、再 c 排序，b 的空缺会让 c 无法用于定位，只在 MySQL 5.6 之后可能作为索引下推的条件在引擎层过滤，减少回表次数，但不会缩小扫描区间。想真正用上 c 就得建 (a,c) 这样的辅助索引。

4. 秒杀系统的 Redis 与 MySQL 分工。Redis 负责所有高频判定：库存预扣用 Lua 脚本把「查库存 + 判断是否重复下单 + 扣减」做成一次原子操作，避免超卖；用 Set 或 Bitmap 做一人一单，用令牌桶或队列在入口限流。MySQL 只承担落库和最终对账：订单异步写入，库存以 Redis 为准但定期与库做校准，超时未支付的订单回补库存。缓存穿透和雪崩用布隆过滤器、空值缓存、过期时间抖动来防。答题时一定要把「Redis 扣减成功但落库失败」这条链路单独说清补偿方案，这是面试官真正想听的。

5. 多级召回与 context engineering。这类问题没有标准答案，考的是你对自己系统的掌控。要点是先讲清楚每一级召回解决什么问题（粗排用量化向量在海量库里捞候选，精排用交叉编码器或规则重新排序），再讲提前终止的条件（候选已经足够、分数差距饱和、延迟接近预算上限）。私有库与公共库的隔离，常见做法是物理分库分表 + 元数据过滤，检索时把用户维度的过滤条件强制下推到向量检索之前，而不是召回后再过滤——后者既慢又容易漏掉真正相关的结果。

6. 高并发调用大模型接口的限流兜底。三层：入口按用户和租户做限流（令牌桶控制 QPS，配额控制总量）；调用层设置短超时加有限次指数退避重试，且只对幂等请求和 5xx、超时类错误重试，429 要读响应头里的重试窗口而不是盲目重试；兜底层准备降级模型与降级答案（换更小的模型、返回缓存结果或明确提示），并配合熔断器在半开状态下小流量探测恢复。分布式限流用 Redis + Lua 保证多实例共享计数。