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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

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

MySQL 表里只有 1 条数据，索引高度为几层？如果再加 1 条数据呢？什么时候变成 2 层？
Redis 的红锁是不是一定没问题？如果在多个节点下一定要稳定的分布式锁该怎么做？
在转账业务中，如果网络一直波动导致分支事务悬挂时，如何设计补偿机制？
在同城双活架构中，如何实现交易请求的无缝切换？当主中心故障时，如何保证事务最终一致性？
在反洗钱监控中，如何用 Drools 实现实时规则匹配？单日交易超百万笔时，如何优化规则引擎性能？
在账户历史数据归档中，如何实现 TB 级数据迁移？当迁移中断时，如何保证数据的完整性？
在网关中，如何设计防刷限流策略？当检测到恶意请求时，如何实现自动封禁？
如何用 K8s 实现有状态服务部署？当 pod 漂移时，如何保证数据不丢失？
在新服务上线时，如何用 Istio 实现用户级灰度发布？当发现问题时，如何快速回滚并减少影响？
在 AI 智能客服场景中，如何实现多轮对话的上下文管理？当用户问题模糊时，如何设计引导策略？

MySQL

Redis

分布式锁

65 条回复 • 2025-12-08 22:25:37 +08:00

Geekgogo

6 天前

好难啊，一题都不会做

midsolo

6 天前

@Geekgogo Java/Go 后端开发的题，比较贴近公司的实际业务，但平时都在写业务的 CRUD ，没怎么考虑过这些问题

JYii

6 天前

这有点难了，如果不用 AI 很难回答好。对于大头兵开发只能挑几道题，架构设计居多。

midsolo

6 天前

@JYii 面试只是为了筛人，进来都是写业务的 CRUD

BelovedOne

6 天前

这多正常啊，来的时候要打死东家，来了发现都是酒囊饭袋。虽然没有向着梦想前进，但性价比拔群。

JYii

6 天前

@midsolo #4 这个面试题你说它八股文吧，但又是开发中大概率遇到的，如果答的过的去，要价 25-30k 不过分吧

midsolo

6 天前

@JYii #6 这些问题比较贴近公司的实际业务，不算是八股文吧！

难度对标 3~5 年的中高级后端开发，面的好的话薪资能给到 30k 。

111111111111

6 天前

好题，每一题都值得写几篇博客
感觉能答出这些题的人，应该是团队里攻坚（技术研究、方案设计、优化保障）的少数人，在这些场景深度参与，并且留下了深刻影响，甚至可能还颇有心得
大多数人应该答不好

JYii

6 天前

@midsolo #7 5 年老兵老脸一红，除了几道题曾经做过类似解决方案，大部分只能泛泛而谈。

askfilm

6 天前

@midsolo 不算"八股文"吗？这是高端八股文呀，要求人人都是架构师那种.... 3~5 年后端要会这些，都神童了

adimn

6 天前

8.9 招的是运维吧

Aust1ng

6 天前

能在 45 分钟把这些题全答出来的人，还会来面试吗

alpha4zeta

6 天前

什么神仙公司, 这么闲, 把公司名发出来

midsolo

6 天前

@adimn 是的，这 2 个题有点偏运维，因为公司中 dev 、test 的 k8s 环境是开发自己维护的，运维只管 sit 、uat 、prod 环境，所以开发也需要懂点运维方面的知识

midsolo

6 天前

@Aust1ng 公司题库系统中直接给出的一个做题链接，时间限制 45 分钟，简答就行，目前还在内部测试中，后续公司会根据员工内部测试的通过率来调整难度

midsolo

6 天前

@alpha4zeta 某跨境公司，做的业务是把民用无人机跟运动相机卖到欧美或澳大利亚这些地方，真的不闲，只不过周五我想摸鱼，搞这种内部测试估计是领导的 KPI 吧

alpha4zeta

6 天前

@midsolo #16 DJI

FlashEcho

6 天前

感觉好难啊，有的问题如果没做过相关业务，干 3 年开发和 10 年开发都一样答不出来，比如很多时候用的是托管服务，根本不用关心双活怎么实现最终一致性，也不会用 statefulset

midsolo

6 天前

@askfilm 这些问题已经很贴近实际工作了，系统是公司交易业务线中的，问题也是正真出现并解决过的，薪资对标的是 p6 ，题目偏难纯粹是因为来面试的人多，部门老大为了提高面试效率而整出来的

falsemask

6 天前

太难了

adimn

6 天前

@midsolo #14 dev 、test 的 k8s 环境我在 19 年也维护过，后面的公司都再没用过

x86

6 天前

当年去地产公司做事的时候，一说做有需求啥的，总监来句给外包做就行了别浪费时间
我:啊这么爽...

k9982874

6 天前 via Android

这题目对标 3-5 年经验 p6 ，你确定能招到人？
这些题目做的好的来你这拿 3w/月？

falsemask

6 天前

@falsemask 第一个以前看过一本 mysql 小册，当时仔细研究过，现在忘了。第二个以前看过 DDIA 作者和 redis 作者的争论，研究过，忘了。转账业务没接触过，但是最终一致性有很多方案。4 5 没接触过。第六个，我们数据归档 dba 做的。后面的 k8s 开发基本不接触

tonytonychopper

6 天前 via iPhone

@k9982874 喵了一眼，这都是架构类型的题，起码也要给 P7 吧哈哈

Rat3

6 天前

这个在上海是 40K 起的

midsolo

6 天前

@tonytonychopper p6 跟 p7 的技术差距并不大，只不过 p7 多了管理能力跟自驱力，而且跟其他同事关系搞的比较好，目标性强，关键时候能扛事

midsolo

6 天前

@k9982874 题库系统目前还在内部测试中，会根据内部员工测试来调整难易程度，很多题内部员工都做不出来，不要在意

midsolo

6 天前

@Rat3 深圳薪资比上海要低一些，而且我司是跨境卖无人机跟运动相机的，销量跟年终强挂钩，卖得好年终就多一点，可以来弥补 base 过低的问题

JoeDH

6 天前

麻烦发多一点，我好复习下面试题

asdhak

6 天前

给多少工资？

wu00

6 天前

说实话这面试题出的挺不错的，大部分题回答出解决思路应该就算过关，挺难的

BraveRBT

6 天前

针对题目 2

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

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

感觉整套题目能回答上的人, 基本都感觉公司的实际技术栈是老旧和有问题的....
我第一想法是这公司的业务系统设计水平不高, 可能还停留在 10 年前的水平, 如果配上薪酬水平估计投都不投了

midsolo

6 天前

@wu00 问题都是比较贴近实际工作的，都在业务线上曾经出现过，包括了交易、账户、规则引擎、风控、网关、客服这些服务模块，真的不是八股文

midsolo

6 天前

@JoeDH 可以的，只要抽到我做题，我就分享出来

BraveRBT

6 天前

另外题目中,已经反复提到了网络抖动相关的问题, 这就更说明公司在这方面吃过亏
如果从架构上可以避免,就不应该使用有缺陷的架构去解决问题, 这也是面试八股文的典型特征
而且题目中也提到了 Drools, 这东西本身就很老.....
主流做法早就用 Flink/Spark Streaming 做流式处理实时计算

就和有些公司会问 clickhouse 现在是否是数仓第一选择一样, 反映的都是公司技术栈老旧的问题
答案都是否定的

midsolo

6 天前

@BraveRBT #33 没错，该系统是 2017 年用 Java 开发的，一直在稳定迭代中，现在逐渐在用 Go 进行重构，异地多活这一块用的还是多年以前的 SET 单元化架构，早期团队成员大多来自阿里。

midsolo

6 天前

@BraveRBT #36 网络抖动这个问题一直没法解决，因为做的跨境业务，服务器部署在全球多个地方，数据很难保证一致性，并且尝试多多种最终一致性方案，都没能很好的解决现有的问题。技术栈老旧是历史原因，我入职的时候就用的这一套，已经规划重构升级了。

kingofzihua

6 天前

一个题也不会。有答案吗？需要根据答案补下知识

BraveRBT

6 天前

@midsolo #37 对的, 根据题目大概能猜测到贵司团队创始时间在 2015 年前后
有机会用 go 重构的话, 现在有蛮多先进中间件和框架可以选用
兵来将挡水来土掩, 只要架构设计合理, 性能问题和可靠性问题都能迎刃而解

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

BraveRBT

6 天前

@midsolo #38 我们内部经常讨论的经验法则: 万事万物都要幂等, 什么业务场景都要考虑重放带来的影响和风险.
问题核心在业务重放和抖动后不幂等, 优先从业务逻辑上解决这个问题, 如果实在无法解决, 再从技术手段上来降低风险.

不清楚贵司实际业务场景是什么, 但我们的想法是: 异地多可用区监察(尤其要单数节点,并且最好大于不等于 3) + 可靠重放机制
数据库如果能上云并能接受阿里系的话, PolarDB 或者 OceanBase 跨地域部署都还可以(把复杂基础设施可靠性问题抛给公有云解决,换句话将来得有个人接锅)
AWS 就是 Aurora Global Database, 实际验证过跨区域容灾能力和 RPO/RTO 都还不错

BraveRBT

6 天前

@BraveRBT #40 勘误: HTAP 数据库(Hybrid Transaction / Analytical Processing), 打错了