这两个词在后端简历上的出现率极高，被追问的概率也极高。

问题在于它们是能力声明，不是事实。面试官验证能力声明的唯一办法，就是从一个具体场景开始往下问。

与其让他挑，不如你自己给。

把「熟悉分布式」拆成四个可写的场景

场景一：分布式事务

订单与库存跨服务一致性：采用本地消息表 + 定时补偿， 日均 12 万笔订单，最终一致性延迟控制在 3s 内， 补偿任务幂等由唯一业务号保证，上线一年未出现资金类不一致

面试官接着问的通常是：为什么不用 TCC、消息丢了怎么办、补偿失败几次之后怎么处理。这三个问题你都该有答案。

场景二：分布式锁

用 Redis 实现秒杀场景的分布式锁（Redisson 看门狗续期）， QPS 峰值 3 万，解决了超卖； 明确了锁粒度按商品维度而非全局，减少锁竞争

接着会问：主从切换时锁失效怎么办、锁超时怎么设、有没有考虑过 RedLock 的争议。

场景三：服务治理

为 20+ 服务接入限流与熔断（Sentinel）， 按接口维度配置阈值，大促期间非核心服务降级， 核心链路可用性保持在 99.95%

场景四：数据分片

用户表 2000 万行拆分为 16 库 64 表（ShardingSphere）， 分片键为用户 ID； 遗留的跨片查询改由离线宽表承接，迁移期双写 3 周后切流

「高并发」同理

不要写「具备高并发经验」。写清楚三个数：峰值 QPS、响应时间、以及为达到这个数你做了什么。

接口峰值 QPS 从 2000 提升到 1.5 万： 引入本地缓存 + Redis 二级缓存，热点 key 做分片打散， 连接池参数按压测结果调整，P99 从 800ms 降到 120ms

分布式相关的经历，深度分三层

第一层：用过。项目里有这套东西，你按现有方式调用。

第二层：调过。遇到问题时你去查、去改配置、去调参数，知道每个参数的含义和影响。

第三层：定过。方案是你选的，你知道备选方案是什么、为什么没选、以及当前方案的边界在哪。

简历上写的时候，如实反映你在哪一层。三年以内的开发者在第一、二层是正常的，硬写成第三层，面试时的追问会非常难受。

写第二层的标准句式是这样的：

排查并解决一次消息重复消费导致的重复扣款： 定位到消费者在 rebalance 期间未提交 offset， 补充幂等表 + 业务唯一键，此后未再出现

这段没有宣称任何架构能力，但它证明了你真的在生产环境里和这套东西打过交道，说服力比「熟悉 Kafka」强十倍。

一条判断标准

写完之后，假设面试官指着这句话说「展开讲讲」，你能不能讲满十分钟并且不重复。

不能，就说明这句话超出了你的实际经验范围，往回收。收的办法不是删掉整段，而是换成你真正做过的那一层：没设计过分片方案，但参与过数据迁移，那就写数据迁移。

顺带说一句规模

在小规模场景下做过完整链路的人，比在大规模场景下只改过一个配置的人，在面试里往往表现更好。规模不够不必心虚，把你做过的那部分讲透就行。

面试官为什么执着于追问这几个词

因为这几个词是简历上最容易注水的地方，也是区分度最高的地方。

一个真正做过分布式事务的人，一定踩过对账不平、补偿重复、消息乱序这些坑，随口就能说出两三个具体场景。没做过的人只能背概念，一问到「你们线上出现过什么问题」就没词了。

所以面试官的策略很简单：从你写的词切入，问一个只有做过的人才知道的细节。

反过来，这也给了你一个准备方向：与其背理论，不如把你真实遇到过的两三个线上问题整理清楚，现象、排查过程、根因、解决方案、后续预防。这几个故事讲透，比背十道八股题有用。

最后

简历上的能力声明，最好的状态是「说得比实际保守一点」。面试时对方发现你比简历上写的还懂，这个印象分是花钱都买不到的。