力鑫科技全栈二面：简历拷打与 1.6T 数据库上云迁移方案

《面试题目》

1. 请做自我介绍。
2. 简历信息对齐：23-27 年就读、大四、第一学历确认。
3. 绩点前 10% 的具体排名是多少？
4. 两段实习分别的离职原因是什么？
5. 追问：为什么这段实习没有转正？
6. 追问：三个实习生里，你和转正的那位差在哪？
7. 简历里写的「线程安全的无人机池、无锁读写」，你的设计方案是什么？你是主设计还是主开发？
8. 追问：这个过程中你主导的设计具体体现在哪？
9. 追问：ConcurrentHashMap 的优势是什么？整体方案说一下。
10. 项目里单机 QPS 1388.7 是怎么测算出来的？本地硬件配置如何？
11. 一个 SQL 查询要 20 秒，怎么优化？可能有哪些原因？
12. 追问：用了索引还是很慢，还有什么原因？
13. 追问：除了机器性能、分库分表，还有什么情况？
14. 追问：数据的离散程度（索引选择性）你聊过吗？
15. 你做过 RAG 知识库的开发吗？
16. 你们是怎么测试确认知识库准确率的？
17. 场景题：1.6T 数据库从本地上云，业务白天不能停机、每天 0-4 点可停，迁移方案怎么设计？
18. 追问：定时迁移具体怎么迁？数据一致性怎么考虑？
19. 追问：数据没有创建/修改时间、没有常规 ID，无序数据怎么处理增量？
20. 追问：双写怎么保证数据一致性？
21. 追问：4 小时迁 1.6T 带宽够吗？算一下。
22. 追问：一分钟传 7G，带宽要多少？
23. 追问：增量迁移 + 全量比对会陷入无限循环，怎么解？
24. 追问：怎么加标记位/偏移量，方案才更落地？
25. AI 情况下你对自己的发展前景怎么看？
26. 你的职业发展规划是什么？
27. 你在江西哪个城市读书？你是哪里人？
28. 择业城市主要考虑哪些地方？没想回老家吗？
29. 目前在参加校招吗？整体感受怎么样？
30. 目前看的是什么类型的公司、偏哪些城市？
31. 手上有比较确定的 offer 吗？
32. 追问：实习结束后没想过继续留在那边吗？
33. 和一面面试官、研发负责人聊完，有什么心得？
34. 投简历时/面试前对公司有了解吗？自己有没有再搜索了解？
35. 在实习期间，你做的最难的一件事？怎么应对的、结果如何？（举个案例）
36. 这个过程中你最大的成长和收获是什么？
37. 有没有收获到不错的沟通方式方法？
38. 意见相左时你们怎么碰撞最终达成共识？
39. 怎么平衡时间参加比赛？比赛对你除了荣誉资质之外有什么实质性帮助？
40. 参加比赛遇到过困难吗？怎么解决的？
41. 你对苏州这个城市就业的薪资期望是多少？

《参考解析》

「无锁读写 + 线程安全对象池」怎么讲才算讲清设计：面试官连追三层（主设计还是主开发、你主导的体现在哪、ConcurrentHashMap 优势），考的是你到底是在用别人的方案还是在做设计。回答结构建议：先说清问题与约束（谁在并发、竞争点在哪、性能要求是什么），再说方案演进（最初加全局锁 → 瓶颈在哪 → 换成什么结构 → 数据怎么组织、扩容怎么处理），最后说验证（用什么场景压测、看到什么数据、有什么已知不足）。ConcurrentHashMap 的优势要讲对：JDK 8 起它放弃了分段锁，改成 CAS + synchronized 只锁桶头节点，读操作基本无锁（用 volatile 保证可见性），扩容时多线程协同搬迁（transfer），因此并发度接近桶的数量、读多写少时扩展性好；但它只保证单个操作原子，get 后再 put 这种复合逻辑仍要 computeIfAbsent、merge 或额外加锁。对象池的关键设计点是池容量与拒绝策略、借还的成对性（用 try-finally 或自动释放）、空闲对象的健康检查、以及池化带来的共享状态风险——池化之后对象就不再是线程私有的，任何可变字段都要重新审视，这也是「无锁」说法最容易被追问翻车的地方。

单机 QPS 1388.7 是怎么来的：这个数字带小数，说明面试官想验证它是否来自真实压测，而不是编的。要说清五件事：压测工具与协议（wrk/JMeter/Gatling、HTTP 还是 RPC）、压测拓扑（单机直压还是过网关、是否跨网络）、并发模型（线程数/连接数、是否 keep-alive）、请求内容与数据规模（读接口还是写接口、数据量多少、有无缓存命中）、以及统计口径（成功率、P50/P95/P99 延迟、统计窗口多久、压测持续多长时间、机器配置的 CPU/内存/磁盘）。常见的「算出来好看」的坑：并发数写太高导致请求排队、只统计成功请求、只跑几十秒、用空数据表压测、或者把网关层的限流当成了服务端能力。主动补一句「这个数据是在什么配置下、测的是什么接口、瓶颈在哪里」，比死守数字更有说服力；如果确实记不清，就诚实说是当时压测的平均值、并给出当时的瓶颈定位（CPU、GC、还是数据库连接数）。

20 秒慢 SQL 怎么排查：先分层归因，再谈手段。可能的根因大致五类：① 没走索引或走错索引——EXPLAIN 看 type 是否为 ALL/index、key 是否命中、rows 估算多大、filtered 多低；常见诱因是对索引列做函数运算、隐式类型转换、前导模糊匹配、违反最左前缀、或者 OR 连接了无索引列。② 索引选择性差——区分度低的列（性别、状态这类）建了索引也没用，优化器会直接放弃走全表；这题追问「用了索引还是很慢」时最该答的就是它：回表次数太多（二级索引命中大量行后逐条回聚簇索引）、或者索引覆盖不了查询需要回表。③ SQL 本身的问题——SELECT *、大 OFFSET 深分页、笛卡尔积式多表 JOIN、子查询导致物化、排序与分组落盘（Using filesort、Using temporary）。④ 并发与锁——被 FOR UPDATE、MDL 或长事务挡住，看 SHOW PROCESSLIST、information_schema.innodb_trx、performance_schema 里的等待。⑤ 数据与统计信息——表太大且无分区、统计信息过期导致执行计划失真（ANALYZE TABLE）、磁盘 IO 或网络瓶颈。优化的顺序是：先拿真实执行计划与耗时分布，再改 SQL/加合适索引（含覆盖索引）、再考虑归档与冷热分离、最后才读写分离与分库分表。回答时给出「我是怎么定位的」比罗列手段更得分。

1.6T 上云迁移：方案骨架与带宽账：先说策略：既然每天只有 0-4 点可停，就采用「全量 + 增量」两段式。全量阶段不必等停机窗口，可以在业务运行期间分批搬迁历史数据（按主键区间或时间分片，限速以免影响线上 IO），把搬迁进度与位点记录下来；到了 0 点开始做最后一段增量追平，追平后短暂停写、做校验与切换，把不可用时间压到分钟级。增量必须有一个可靠的位点：有自增主键或更新时间就用它做游标，没有就靠 binlog（把 binlog 位点当游标，配合全量快照的位点做衔接），或者引入一个迁移标记表记录已迁范围。带宽账要能当场算：1.6 TiB ≈ 1.6 × 1024 × 1024 ≈ 1.68 × 10⁶ MiB，4 小时 = 14400 秒，纯数据吞吐约 116 MiB/s，换算成带宽约 930 Mbps——也就是说理论底线是跑满一条千兆链路，实际还有协议开销、重传、压缩比、磁盘读速与目标端写入速度，所以要么预留余量（万兆或数条千兆聚合）、要么先把 4 小时窗口撑长、要么上压缩与并行分片。第二问「一分钟传 7G」：7 GiB ≈ 7168 MiB / 60 s ≈ 119 MiB/s，同样约 0.95 Gbps，两个数字互相印证——答题时把结论落在「千兆口刚好卡在临界值，必须留余量」上。

增量迁移 + 全量比对为什么收敛不了：根因是「校验的对象在变」——你在比对的同时业务还在写入，比对期间产生的新差异会被当成不一致，于是又要重新迁移、重新比对，循环不断。解法有三条并用的思路：① 定义收敛窗口——把迁移分成若干片（按主键范围/业务单元），一次只冻结一片（片内短暂停写或只读），在这一片内做「迁移 → 校验 → 差异回补 → 再校验」，片与片之间可以并行、业务整体不停；② 校验比对必须针对同一个位点或快照——用 binlog 位点/时间戳作为基准，比对的是「该位点之前的数据」，位点之后的写入由增量流程负责，不与比对纠缠；③ 差异处理走按主键回补而不是重跑全量，并且设明确的收敛判据（例如连续两轮零差异，或差异率低于阈值即视为收敛，剩余差异进入人工清单）。面试里如果被问「怎么加标记位/偏移量」，答法是把「迁移进度」做成持久化的元数据：记录已迁主键区间、每片的位点（时间戳/binlog pos）、校验轮次与结果，任务重启后能续跑而不是从头再来——这才是让方案可落地、可中断、可观测的关键。至于双写一致性：双写本身很难保证强一致（两边事务不同源、失败无法同时回滚），所以要配「本地消息表/事务消息 + 对账补偿」或者干脆用 binlog 订阅做单向同步，并明确以哪一侧为准。

RAG 知识库的准确率怎么测：这题答「人工看看效果不错」会被追着打。要把准确率拆成三段分别量化：① 召回层——建一批「问题 → 应召回的文档/片段」评测集（可以从真实日志里标注，几十到几百条就够起步），看 Recall@K、命中率、MRR，判断是检索没找到还是生成写错了；② 生成层——看答案的事实正确性、是否引用了检索到的内容（引用覆盖率/出处可追溯）、以及拒答与幻觉率；人工评估用统一的打分标准（正确/部分正确/错误/拒答）并做双人交叉，或用模型当裁判但要抽样人工校准；③ 端到端——按业务场景造问题集，看整体通过率与用户反馈（追问率、点踩率）。工程侧的辅助手段：把评测集固化成回归用例，每次改切分策略、embedding 模型、提示词、重排器都跑一遍，防止改一处坏一处；线上做 badcase 收集闭环，把错答样本补进评测集。要能指出常见错误来源：切分粒度不当（把语义切碎或把多个主题塞进一块）、只有向量检索没有关键词补足（专有名词、编号类查询召回差）、没有重排导致噪声进上下文、以及上下文里出现冲突信息时模型不会取舍。

HR 与职业规划类追问的应对：这一轮的后半段（绩点排名、离职原因、为什么没转正、城市与薪资期望、offer 情况、比赛收获）本质上是在验证稳定性、动机和表达。几个原则：① 关于离职/未转正，用事实 + 反思，不评价前公司也不自我攻击——说清客观约束（转正名额、业务调整、个人方向）加上「我从这段经历里明确了什么」；被问「你和转正的人差在哪」时，答一个具体可改进的点（比如交付边界的前置沟通、主动性），比说「都很好只是名额有限」更让人信服。② 绩点、排名、比赛这类硬指标，报实数、给口径（专业排名/综合排名），不确定的不要编。③ 薪资期望不要报绝对数字陷阱，先给区间与依据（城市、岗位、自身经历、同届行情），表示可谈；被问城市与老家，给明确的排序和理由，含糊等于减分。④ 「AI 时代你的发展前景」这类问题，答行动而非情绪：AI 承担了多少重复编码、你把时间投向了什么（系统设计、问题定义、工程判断），并举一个自己用 AI 提效同时守住质量的具体例子。⑤ 面试节奏上，40 问的高密度拷打说明对方在压力测试你的表达与耐心，回答控制在 1-2 分钟、先结论后展开，比长篇铺陈更容易拿到下一轮。