面试造核弹，入职拧螺丝 (2)

2025 年 12 月 5 日
 midsolo

继 面试造核弹，入职拧螺丝 之后，很不幸的再次被抽到，45 分钟 10 题，这次没公布有多少人顺利通过，估计大家都学聪明了。

  1. MySQL 表里只有 1 条数据，索引高度为几层？如果再加 1 条数据呢？什么时候变成 2 层？
  2. Redis 的红锁是不是一定没问题？如果在多个节点下一定要稳定的分布式锁该怎么做？
  3. 在转账业务中，如果网络一直波动导致分支事务悬挂时，如何设计补偿机制？
  4. 在同城双活架构中，如何实现交易请求的无缝切换？当主中心故障时，如何保证事务最终一致性？
  5. 在反洗钱监控中，如何用 Drools 实现实时规则匹配？单日交易超百万笔时，如何优化规则引擎性能？
  6. 在账户历史数据归档中，如何实现 TB 级数据迁移？当迁移中断时，如何保证数据的完整性？
  7. 在网关中，如何设计防刷限流策略？当检测到恶意请求时，如何实现自动封禁？
  8. 如何用 K8s 实现有状态服务部署？当 pod 漂移时，如何保证数据不丢失？
  9. 在新服务上线时，如何用 Istio 实现用户级灰度发布？当发现问题时，如何快速回滚并减少影响？
  10. 在 AI 智能客服场景中，如何实现多轮对话的上下文管理？当用户问题模糊时，如何设计引导策略？
7903 次点击
所在节点    职场话题
65 条回复
adimn
2025 年 12 月 5 日
@midsolo #14 dev 、test 的 k8s 环境我在 19 年也维护过， 后面的公司都再没用过
x86
2025 年 12 月 5 日
当年去地产公司做事的时候，一说做有需求啥的，总监来句给外包做就行了别浪费时间
我:啊这么爽...
k9982874
2025 年 12 月 5 日
这题目对标 3-5 年经验 p6 ，你确定能招到人？
这些题目做的好的来你这拿 3w/月？
falsemask
2025 年 12 月 5 日
@falsemask 第一个以前看过一本 mysql 小册，当时仔细研究过，现在忘了。第二个以前看过 DDIA 作者和 redis 作者的争论，研究过，忘了。转账业务没接触过，但是最终一致性有很多方案。4 5 没接触过。第六个，我们数据归档 dba 做的。后面的 k8s 开发基本不接触
tonytonychopper
2025 年 12 月 5 日
@k9982874 喵了一眼，这都是架构类型的题，起码也要给 P7 吧哈哈
Rat3
2025 年 12 月 5 日
这个在上海是 40K 起的
midsolo
2025 年 12 月 5 日
@tonytonychopper p6 跟 p7 的技术差距并不大，只不过 p7 多了管理能力跟自驱力，而且跟其他同事关系搞的比较好，目标性强，关键时候能扛事
midsolo
2025 年 12 月 5 日
@k9982874 题库系统目前还在内部测试中，会根据内部员工测试来调整难易程度，很多题内部员工都做不出来，不要在意
midsolo
2025 年 12 月 5 日
@Rat3 深圳薪资比上海要低一些，而且我司是跨境卖无人机跟运动相机的，销量跟年终强挂钩，卖得好年终就多一点，可以来弥补 base 过低的问题
JoeDH
2025 年 12 月 5 日
麻烦发多一点，我好复习下面试题
asdhak
2025 年 12 月 5 日
给多少工资？
wu00
2025 年 12 月 5 日
说实话这面试题出的挺不错的，大部分题回答出解决思路应该就算过关，挺难的
BraveRBT
2025 年 12 月 5 日
针对题目 2

对于这么高的强一致性要求,而且还是双活(上下文题目中已经提到了同城双活架构)
Redis redlock 方案真的有待商榷.
换句话说 redis 加锁真的能满足强一致性要求吗(同城网络抖动导致脑裂, 内部 NTP 时钟漂移), 从一开始就是陷阱提问方式
很符合面试八股文的基本定义, 即从公司里的历史故障出发, 而不是从技术本质出发

正常做法都是数据库事务做悲观锁,或者 etcd(Raft)做强一致性处理,而不是缓存做分布式锁
而且同城双活的可靠性, 实际上也有待商榷, 不引入外部跨地域可用区进行 OB 仲裁很难避免脑裂问题
通常做法都是"两地三中心"或异地多活, 仅靠同城双活基本都是吹的比较好听,实际业务炸了就紧张的修理中了


感觉整套题目能回答上的人, 基本都感觉公司的实际技术栈是老旧和有问题的....
我第一想法是这公司的业务系统设计水平不高, 可能还停留在 10 年前的水平, 如果配上薪酬水平估计投都不投了
midsolo
2025 年 12 月 5 日
@wu00 问题都是比较贴近实际工作的，都在业务线上曾经出现过，包括了 交易、账户、规则引擎、风控、网关、客服 这些服务模块，真的不是八股文
midsolo
2025 年 12 月 5 日
@JoeDH 可以的，只要抽到我做题，我就分享出来
BraveRBT
2025 年 12 月 5 日
另外题目中,已经反复提到了网络抖动相关的问题, 这就更说明公司在这方面吃过亏
如果从架构上可以避免,就不应该使用有缺陷的架构去解决问题, 这也是面试八股文的典型特征
而且题目中也提到了 Drools, 这东西本身就很老.....
主流做法早就用 Flink/Spark Streaming 做流式处理实时计算

就和有些公司会问 clickhouse 现在是否是数仓第一选择一样, 反映的都是公司技术栈老旧的问题
答案都是否定的
midsolo
2025 年 12 月 5 日
@BraveRBT #33 没错，该系统是 2017 年用 Java 开发的，一直在稳定迭代中，现在逐渐在用 Go 进行重构，异地多活这一块用的还是多年以前的 SET 单元化架构，早期团队成员大多来自阿里。
midsolo
2025 年 12 月 5 日
@BraveRBT #36 网络抖动这个问题一直没法解决，因为做的跨境业务，服务器部署在全球多个地方，数据很难保证一致性，并且尝试多多种最终一致性方案，都没能很好的解决现有的问题。技术栈老旧是历史原因，我入职的时候就用的这一套，已经规划重构升级了。
kingofzihua
2025 年 12 月 5 日
一个题也不会。有答案吗？ 需要根据答案补下知识
BraveRBT
2025 年 12 月 5 日
@midsolo #37 对的, 根据题目大概能猜测到贵司团队创始时间在 2015 年前后
有机会用 go 重构的话, 现在有蛮多先进中间件和框架可以选用
兵来将挡水来土掩, 只要架构设计合理, 性能问题和可靠性问题都能迎刃而解

另外最近几年半导体发展迅猛, 我们十年前担心的很多性能问题(尤其是算力和吞吐),现在已经不再是问题
有时候我们都感慨现在中间件/HATP 数据库的性能和起飞一样,在 15 年我们绝对不敢想会达到这个夸张的程度....

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1177112

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX