互联网支撑亿级流量场景的三高架构师训练营之有状态-幂等-分布式事务讲解

这门课的名字很长，但真正要解决的问题很集中：当系统从单体拆成分布式，请求量从几千涨到亿级，那些平时不显眼的坑会集中爆发——服务实例能不能随时扩容、同一个请求重复打进来会不会扣两次钱、跨库操作到一半失败怎么办。有状态、幂等、分布式事务，就是这三个坑的名字。

如果你现在的工作里已经有分布式系统的影子，却还停留在「加个 Redis 就完事」的阶段，这篇导读可以先帮你判断：这门课到底补的是你哪一块缺口。

先看清自己缺的是哪一块

「三高」这类词容易被说空，但这门课切的是三个非常具体的工程问题，你可以对照自己的经历做个判断。

• 关于有状态：你的服务是不是只能靠 session 粘滞、靠固定 IP 才能跑起来？扩容一台机器，用户登录态就丢了？如果每次上线都要担心「这台机器上存了什么」，说明状态管理这块是空的。
• 关于幂等：支付回调、消息重投、用户连点两次提交，你的接口顶得住吗？很多人第一反应是「加个唯一索引」，但真正的问题在于幂等键怎么设计、放在哪一层、失败重试时怎么保证语义一致。
• 关于分布式事务：跨服务写数据时，你是不是默认「先这样，出问题人工修数据」？TCC、本地消息表、事务消息、SAGA 这些方案各自的代价在哪、什么场景该选哪个，如果不清楚，面试和实战都会卡住。

三个问题不是并列的知识点，而是同一条链路上的三个断面：状态决定了你能不能不依赖单机，幂等决定了重试是否安全，分布式事务决定了跨服务写入能不能收敛到一致。缺哪一个，另外两个都补不完整。

这门课讲的是决策，不是名词解释

幂等和分布式事务的概念，网上随便搜都有定义。真正难的是在具体场景里做选择：

• 幂等键用业务单号还是请求流水号？放在网关、服务层还是数据库层，拦截效果差在哪？
• 同一个订单的重复请求，是直接拒绝，还是返回上一次的结果？两种做法对上游调用方意味着什么？
• 分布式事务里，什么时候能接受最终一致，什么时候必须强一致？补偿逻辑写在哪、由谁触发、失败了怎么兜底？
• 有状态服务改成无状态，状态往哪挪？挪走之后一致性和性能各付出了什么代价？

这些问题的答案没有标准模板，取决于你的并发量、数据量和对不一致的容忍度。课程按「有状态—幂等—分布式事务」这条线展开，本质上是带着你把这条决策链走一遍，而不是背下几个方案的优缺点。

看完应该能回答的问题

判断自己有没有真的学进去，可以拿下面这几个问题自测。如果现在答不上来，看完之后应该能给出成体系的回答：

• 一个原本靠本地缓存维持登录态的服务，要改造成可以随意扩缩容，你会动哪些地方，代价是什么？
• 设计一个支付回调接口的幂等方案，从入口到落库，每一层分别拦什么？
• 跨三个服务完成一笔下单，中间某一步超时，你怎么判断这笔订单最终是成功还是失败？
• 同样是保证最终一致，本地消息表和事务消息分别适合什么团队和什么系统？

怎么用这门课

建议不要一口气看完。每看完一块，回到自己手上的系统里找一个真实接口，按课里的思路重新推一遍：它有没有状态、幂等靠什么保证、跨服务写入失败会怎样。能在自己的代码里找到对应位置，才算真的补上了。

这门课的门槛不低，默认你已经写过分布式服务、踩过重复请求或数据不一致的坑。如果你还在单体阶段、没接触过 RPC 和消息队列，先别急着上，把基础补齐再来，吸收效率会高很多。