今日份面试笔记：那个27 届实习生把 MySQL 锁机制聊到 CPU 调度层的.....

【我给了offer】

在 PDD 面后端，我最怕听到候选人说“我用过某某框架”。在亿级订单洪峰面前，框架只是外壳，你对底层资源的极致压榨能力，才是你的护城河。

今天面的这个同学，在几个关键技术点上的表现，让我看到了什么叫“PDD 式的硬核”。

1️⃣ 聊 MySQL：他竟然知道“物理空洞”对扫描性能的影响

我问：“拼多多每天产生海量订单流水，即便做了分库分表，单表数据依然膨胀得很快，B+ 树扫描效率下降，你除了重构索引还能怎么搞？”

• 常规回答： “定期清理历史数据。”（这种回答在 PDD 只能算及格）
• 他的切入点： 他跟我讨论了 InnoDB Page 的填充因子（Fill Factor）。他提到在频繁插入删除的业务场景下，Page 内部会产生大量的碎片空洞，导致磁盘 IO 命中率下降。
• 深层暴击： 他甚至建议通过 Optimize Table 的底层逻辑 或 自研的搬迁工具，在业务低峰期进行物理层面的空洞压缩，从而提升索引页的缓存密度（Buffer Pool Density）。这种对磁盘空间和内存效率的抠门劲儿，非常有 PDD 范儿。

2️⃣ 聊 Redis：不仅仅是缓存，他聊到了“内核级别的伪共享”

我问：“热点 Key 探测出来后，如果单台机器的网络带宽（NIC）成了瓶颈，你怎么办？”

他给出的骚操作： 他不仅提到了多级缓存，还深入到了 Redis 的 I/O 多路复用模型。他分析了在 PDD 的大包传输场景下，如何通过调整 io-threads 的绑定策略 来减少 CPU 核心间的上下文切换开销。

• 极致细节： 他提出利用 Local-Memory（堆内内存） 做一层极薄的二级缓存，并配合 Lua 脚本的高级原子性 来解决缓存击穿时的“惊群效应”。他甚至考虑到了数据序列化带来的 CPU 开销，对比了 Protobuf 和 JSON 在万兆网卡环境下的吞吐差异。

3️⃣ 聊分布式：他懂“柔性事务”与“业务逻辑的错峰延迟”

我问：“双 11 秒杀，库存扣减和支付回调，你怎么平衡系统吞吐量和资金安全？”

• 他的战术： 他抛弃了传统的强一致性思维，跟我聊起了 “预扣减+异步延时回滚”。
• PDD 基因： 他提出在极端洪峰下，利用 消息队列（MQ）的优先级分发。让支付成功的核心链路走“绿色通道”，而将一些非核心的统计、券发放逻辑完全异步化，甚至利用 时间轮（Timing Wheel）算法 做精准的超时关单，释放库存。这种对业务场景的微观调控，正是我们 PDDA 架构的精髓。

📝 面试官感悟：

面试到最后，我出了道手写代码题，要求他实现一个高性能的滑动窗口限流器。

他没有用任何第三方库，直接用 Atomic 原子类 + 位运算 优化了时间戳的存储。代码非常简洁，没有任何多余的封装。我问他为什么这么写，他说：“在拼多多的规模下，每一个无意义的对象创建，都是对 GC（垃圾回收）的挑衅。”

这句话说到了我心坎里。

💡 给 27 届后端同学的技术清单：

如果你也想在 PDD 面试中拿 Strong Hire，这几个点必须吃透：

• 存储底层： 不止是索引，还有 Page 管理、Redo Log 的落盘机制。
• 网络 IO： Zero-copy、Reactor 模型、TCP 拥塞控制。
• 并发编程： 锁升级的代价、无锁队列（Disruptor 思路）、内存屏障。
• JVM 调优： 针对海量短生命周期对象的 G1/ZGC 策略。