这两个词在后端简历上的出现率极高被追问的概率也极高。问题在于它们是能力声明不是事实。面试官验证能力声明的唯一办法就是从一个具体场景开始往下问。与其让他挑不如你自己给。把「熟悉分布式」拆成四个可写的场景场景一分布式事务订单与库存跨服务一致性采用本地消息表 定时补偿 日均 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」强十倍。一条判断标准写完之后假设面试官指着这句话说「展开讲讲」你能不能讲满十分钟并且不重复。不能就说明这句话超出了你的实际经验范围往回收。收的办法不是删掉整段而是换成你真正做过的那一层没设计过分片方案但参与过数据迁移那就写数据迁移。顺带说一句规模在小规模场景下做过完整链路的人比在大规模场景下只改过一个配置的人在面试里往往表现更好。规模不够不必心虚把你做过的那部分讲透就行。面试官为什么执着于追问这几个词因为这几个词是简历上最容易注水的地方也是区分度最高的地方。一个真正做过分布式事务的人一定踩过对账不平、补偿重复、消息乱序这些坑随口就能说出两三个具体场景。没做过的人只能背概念一问到「你们线上出现过什么问题」就没词了。所以面试官的策略很简单从你写的词切入问一个只有做过的人才知道的细节。反过来这也给了你一个准备方向与其背理论不如把你真实遇到过的两三个线上问题整理清楚现象、排查过程、根因、解决方案、后续预防。这几个故事讲透比背十道八股题有用。最后简历上的能力声明最好的状态是「说得比实际保守一点」。面试时对方发现你比简历上写的还懂这个印象分是花钱都买不到的。