企业官网建设流程全解析

上篇把分布式事务的基本概念和几条主干路线理了一遍，大家最关心的其实不是哪个方案名字更好听，而是落到自己系统里到底该怎么选、怎么写、怎么上线。这篇接着往下走，不重复讲理论，直接聚焦到最经典也最折磨人的场景——订单与库存的分布式事务，把"一致性"这个词掰开揉碎，再把一套能落地的方案从表结构讲到期满失败补偿。

我会把篇幅重点放在三块：一致性到底是什么级别才够用、订单库存场景的完整拆解、以及本地消息表/事务消息这套组合在生产环境里的真实坑和运营细节。适合已经了解分布式事务基本概念、准备动手改造或正在排查数据不一致问题的后端工程师。

1. 这一篇要往下走多远：从概念到可落地的世界

先回顾一下上篇留下的关键结论：分布式事务本质上没有银弹，你只能在一致性强度、可用性、性能、业务侵入度之间做取舍。XA两阶段提交能拿到强一致，但代价是数据库资源锁持有时间变长、吞吐掉得厉害，并且参与者越多越容易出prepare后宕机的尴尬局面；TCC把补偿逻辑交给业务方，灵活但开发成本极高，一个正向接口配一个confirm一个cancel，字段多一个都得跟着改；Seata AT模式用undo_log做反向补偿，看起来省事，但全局锁和undo_log在数据量上来之后也有不少隐性成本；而本地消息表/事务消息这套思路，靠状态机和重试把"最终一致"落地，是目前生产环境里性价比最高、也最容易被团队接受的方式。

这篇既然叫第二部分，就不再花篇幅罗列概念了，重点回答三个实际问题。第一个问题是意识层面的：订单和库存到底需要多强的一致性，是不是必须做到强一致才不会出事。很多人被"数据不能错"这句话吓住，一上来就奔着强一致去，结果引入了大量复杂性，最后发现业务根本承受不了那个吞吐和延迟，这个方向性问题需要先拎清楚。

第二个问题是设计层面的：一个标准的下单扣库存流程，如果用本地消息表+事务消息来推，完整链路长什么样。订单服务先写库还是先发消息，消息里塞什么内容，库存服务收到重复消息怎么兜底，订单创建成功但库存扣减失败的那部分单子谁来管——这些问题我会用一个接近真实业务的案例逐步拆开讲。

第三个问题是运营层面的：方案上线之后，怎么知道它还在正常运转。分布式事务和单机事务最大的区别在于，单机事务错了马上报错回滚，分布式事务错了往往是"暂时看不出来"，要等到对账或者用户投诉才发现。所以幂等设计、兜底对账、降级开关和故障演练，这些"看不见的工作"才是线上稳定的基石。

我见过不少团队，方案讨论时头头是道，一上线就翻车，原因基本都一样：只设计了一条happy path，异常路径全凭嘴说。这一篇我会把happy path和异常路径都写清楚，尤其是那些常规文档不会写、但线上一定会遇到的情况。

2. 一致性到底是什么：先分清你要的是强一致还是最终一致

这个坑我踩得很深。早些年做电商订单系统，领导一句"数据必须强一致"，我们组就上了XA，把所有涉及库存扣减的接口全部包进全局事务。结果压测一跑，数据库连接池被打满，事务成功率反而下降了，因为跨服务的事务分支把连接占用时间拉长了好几倍。后来才想明白，很多业务场景压根不需要强一致，需要的是"最终能对上账"。

先看清楚CAP这件事在实际系统中意味着什么。CAP说了，网络分区不可避免，分区发生时C和A只能二选一。分布式事务是把多个节点的数据变更绑成一个逻辑整体，这本身就是一种对抗分区的操作。你越追求C，就越要在A上付出代价——最典型的就是XA的准备阶段，所有参与者把资源锁住等待协调者指令，协调者一挂，全员卡死。而如果选择A，就得接受一个事实：在某个时间窗口内，各节点数据看起来是不一致的，但只要最终收敛到一致，对业务来说就是可接受的。

这里有个很关键的分层认知：数据库层面的强一致（单机ACID）是"要么全做要么全不做"，而分布式事务追求的往往只是"最终结果是正确的"。拿用户下单来说，用户看到"下单成功"，但这笔订单对应的库存扣减可能还躺在消息队列里等消费，这在系统内部确实不一致，但用户不关心，交易链路也不受影响——只要库存最终被扣掉，超卖没有发生，这笔交易就是正确的。

所以第一个要敲定的问题是：你的业务能容忍多大的不一致窗口。转账到银行卡这种场景，用户转完账号上没第一时间扣款，体验就崩了，而且金融监管要求实时幂等，这种通常是强一致诉求；电商下单扣库存，窗口期几百毫秒甚至几秒，用户无感，完全可以走最终一致；积分赠送、优惠券发放这类就更无所谓了，延迟十分钟也没人发现。明确了这个窗口，你就能决定要不要为了一致性付出那么多代价。

第二个要敲定的问题是：不一致会不会被"自动修复"。银行转账扣款没成功会直接挂账，必须人等处理；但订单超时未支付可以自动关闭并回滚库存——这类业务本身自带补偿机制，天然适合最终一致。如果你发现业务里所有的不一致都需要人工介入才能修复，那说明要么你的补偿设计有缺陷，要么你确实选错了技术路线。

还有一点容易被忽略：方案选择要看写入量。同一条业务数据，每天几百笔和每秒几百笔，设计思路完全不同。小流量场景哪怕半夜跑个全量对账脚本都行，大流量场景必须把对账和补偿做进正常业务流程里。这也是为什么我在后文推荐本地消息表方案——它对小流量团队友好，对高并发大厂也扛得住，区别只在于消息表怎么分片、任务怎么调度。

3. 订单与库存这个最经典的分布式事务场景，怎么拆

先给业务定个性质：用户下单时，订单服务要创建订单，库存服务要扣减库存，这两个动作分属不同数据库甚至不同机房。常见错误做法是把扣库存和建订单放进一个接口里同步调用，一个失败了全部回滚。这个做法在单机时代没问题，拆了服务之后就成灾难根源了。

问题本质在于：跨服务调用的原子性是靠"网络请求成功返回"来判断的，但网络请求超时了，你分不清对方到底是执行成功还是执行失败。同步调用的回滚也难做，订单已创建但库存扣减接口超时，这时候你回滚订单，可能用户已经看到了订单号，也可能支付回调已经打进来了，整个状态就乱套了。所以订单与库存事务必须拆成"本地事务 + 异步消息"的方式，把跨节点的原子性问题转化成单节点的原子性问题，再靠消息投递补偿来解决。

拆分之后的理想流程是这样：下单请求进来，订单服务在自己的数据库里开启一个本地事务，插入订单主记录，同时往本地消息表插入一条"待发送"状态的扣库存消息，一起提交。本地事务提交成功意味着"订单创建 + 扣库存意图"已经持久化，接下来由发送端组件把消息投递到MQ，投递成功后更新消息状态。库存服务消费到消息后，在自己的数据库里执行扣减，扣减成功回执一个确认消息，订单侧看到确认后更新消息状态为"已完成"。整个过程没有跨库事务，每一步都是本地操作，唯一的协调者就是消息表的状态机。

再看扣库存的顺序问题。是先扣库存再建订单，还是先建订单再扣库存？我推荐先建订单，再通过消息触发扣库存。原因很简单：订单才是用户感知的业务实体，库存是一种资源。先建订单，哪怕扣库存最终失败了，我们可以把订单标记为异常并让用户重试；反过来先扣库存再建订单，库存扣掉了但订单没建出来，用户根本不知道发生了什么，你还得半夜跑脚本去找那些"消失的扣减"，排查成本高得多。

还有一条更贴合电商业务的细节：不要把库存扣减设计成"直接扣实物库存"，而是要引入预占/冻结模型。用户下单那一刻，库存服务冻结N件（改变的是冻结字段），用户支付成功后，再把冻结转为实际扣减；如果订单超时未支付被取消，再执行解冻。这个模型的好处在于，库存的变更被分成了"预占"和"确认"两个阶段，中间隔着很长的支付窗口，你根本不需要保证订单状态和库存扣减在同一个瞬间强一致，只要支付完成时确认扣减、支付失败时解冻释放，两边最终一定对得上。

那订单创建成功但扣库存消息弄丢了呢？这事不能只依赖MQ重试兜底。设计上必须让"订单是否存在"和"库存扣减是否发生"这两个事实产生对照关系。最简单的做法是给订单表和库存扣减记录都带上同样的业务单号，然后一个定时任务每天扫描订单表，找出"已支付但库存扣减记录不存在"的订单，主动触发补偿扣减。这个兜底对账任务，比你在MQ上堆一万次重试都管用。

再往下就是性能考量。为什么上MQ而不直接同步RPC调用，除了解决超时无法判定结果的问题，还有一个被低估的原因是削峰。大促场景下瞬时下单量可能是平均值的几十倍，同步调用库存服务，库存数据库直接被流量打垮；但放到MQ里，消费端可以按自己的最大处理能力慢慢拉，队列积压一点没关系，只要最终扣完就行。削峰填谷本身也是最终一致的一部分——你换取了短暂的延迟，换回了系统的存活。

4. 本地消息表 + 事务消息的落地细节：这套方案到底怎么写得滴水不漏

先说说本地消息表这套设计的核心思想：它把"消息发送"这件事也变成了一个本地事务的一部分。你要发消息，不是直接调用MQ的send，而是先在自己的库里插入一条消息记录，然后在同一个事务里完成业务操作和消息记录插入；事务提交后，再由一个后台任务或发送器去真正投递这条消息。这样，消息一定不会丢——因为消息记录和业务数据在同一个库里，要么同时成功，要么同时失败。

所以我特别不推荐那种"先发MQ再执行本地操作"的写法。你发了消息，MQ也拉了，消息也消费了，结果本地数据库事务提交失败，这不就乱套了吗？反过来的"先本地操作成功再发MQ"也有问题，本地事务提交了，发送MQ时网络抖动，消息没发出去，库存就没扣。本地消息表就是把这个"窗口期"消灭掉：消息先落库，本地事务提交后再投递，投递失败就重试，重试失败还有定时任务扫描。

消息表的结构样例如下，字段不多但每个都有用处：

CREATE TABLE local_message ( id BIGINT AUTO_INCREMENT PRIMARY KEY, biz_type VARCHAR(32) NOT NULL COMMENT '业务类型：ORDER_CREATE / STOCK_DEDUCT', biz_id VARCHAR(64) NOT NULL COMMENT '业务单号，对应订单号', content TEXT NOT NULL COMMENT '消息体，如扣减库存所需的信息', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待发送 1已发送 2已完成 3死亡', retry_count INT NOT NULL DEFAULT 0, next_retry_time DATETIME NOT NULL, created_at DATETIME NOT NULL, updated_at DATETIME NOT NULL, KEY idx_status_retry (status, next_retry_time), UNIQUE KEY uk_biz (biz_type, biz_id) ) ENGINE=InnoDB;

投递消息的后台任务逻辑也简单：定期扫描status=0且next_retry_time小于当前时间的记录，把content反序列化后发送到MQ，发送成功的标记为已发送，发送失败的重试次数加一，下次重试时间按指数退避来计算。超过最大重试次数就标成死亡状态，触发告警让人工介入。这套东西看起来很朴素，但稳定，而且消息表就在本地库，做事务、做查询都很顺手。

RocketMQ的事务消息是本地消息表思路的一个变种：把消息表搬到了MQ内部。基本流程是发送端先把消息以half状态投递到Broker，Broker此时不把消息推给消费者；发送端收到half成功回执后，开始执行本地事务；本地事务提交则再次通知Broker把消息标记为可消费，本地事务回滚则通知Broker删除消息；如果发送端在本地事务执行过程中宕机了，Broker会定时回查发送端，发送端根据本地事务的结果回应该消息的状态。这个机制天然解决了本地消息表和MQ之间的双写问题，也是现在很多生产系统选择RocketMQ事务消息的原因。

不管用哪种方式，消费端的幂等设计都是生死线。消息队列为了保证不丢消息，默认至少送达一次，也就是说同一消息可能被重复投递。库存扣减如果没做幂等，重复消费一次，库存就多扣一次，超卖就是这么来的。幂等的常规做法是消费端建一张去重表，以业务单号或消息ID为唯一键；处理消息前先尝试插入这条处理记录，插成功了才真正执行业务逻辑，插不进去说明已经处理过，直接返回成功。这个去重表的唯一键必须包含业务单号，不能只靠MQ的messageId，因为不同消息可能携带同一个业务单号。

还有消息顺序的问题。在订单库存场景里，同一笔订单的消息不是很多，但理论上可能有一条"扣库存"和一条"释放库存"的消息先后发出。如果这两条消息落到不同队列被并行消费，就可能出现释放先执行、扣减后执行的倒序结果，库存数据直接错乱。解决思路是按订单号做hash，让同一订单的消息都进同一个消费队列，消费端单线程或分区顺序消费。大部分业务消息其实没有全局顺序要求，只有同一实体的局部顺序要求，用分区顺序就够了。

个人建议：不要一上来就直接用MQ的事务消息。先从本地消息表起步，等整个链路跑顺了、重试和幂等机制都验证过了，再考虑要不要引入RocketMQ事务消息来简化模型。本地消息表和事务消息在一致性的最终效果上没有本质区别，区别只是在"消息表归谁管"——自己管还是MQ帮你管。自己没有额外中间件、团队对MQ不够熟的时候，本地消息表反而是风险更低的方案。

5. 线上跑起来的那些事：幂等、对账、降级与故障演练

方案设计得再漂亮，一旦进了生产环境，考验就从"能不能实现"变成了"能不能长期稳定运行"。这一章我要讲的是那些不进技术方案文档、但真正决定系统口碑的运营细节。

先说对账任务。用最终一致方案，就意味着你必须接受系统在某个时刻是不完全一致的，所以"定期检查并纠正"不是可选项，是必需项。我见过有团队本地消息表上线半年都没做对账，靠MQ控制台看到有死信才去处理，结果一堆订单和库存对不上。对账任务不要设计得太复杂，核心就是对两组数据：找出"订单已支付但库存扣减记录缺失"的异常数据，以及"订单已取消但冻结库存未释放"的异常数据。每天凌晨跑一次，发现问题发送到告警群，同时向补偿逻辑发送修复指令。SQL和逻辑可以先做出一版最简单，再根据报警量慢慢完善。

监控指标也要围绕最终一致这条链路来建。队列积压数量、最老消息的堆积时间、消息死亡数量、重试次数分布，这四个指标能覆盖大部分问题。最老消息堆积时间尤其重要——一个队列如果出现了特别旧的消息，往往不是消费慢，而是某一条消息卡住导致后续消息无法继续消费，这时候要赶紧排查业务逻辑里的死循环或者外部依赖超时。死亡消息告警更要即时，能做到分钟级最好，因为死亡消息背后往往是业务异常，拖得越久数据偏得越远。

降级方案是很多人忽略的。MQ挂了怎么办？消息表越积越多？线上真正出问题的时候，你需要的不是更完善的分布式事务方案，而是能让业务先跑起来的临时手段。我见过比较务实的做法是：生产环境保留一个开关，当MQ不可用时，扣库存的调用从异步转同步RPC，直接请求库存服务接口；即使同步调用超时，订单也能标记为失败让用户重试，总比用户下单后库存一直没扣要安全。这个开关是要提前写好的，不是出事的时候临时改代码。

主从延迟也是个容易踩的坑。后台任务在扫描本地消息表或对账时，如果扫的是从库，而主从复制有延迟，可能把刚提交的事务漏掉，或者把还没完全同步的数据当成死信处理。建议扫描任务直接连主库，或者对延迟敏感度高的查询统一走主库，避免因为一层复制延迟导致误判和误补偿。

最后一定要做故障演练。分布式事务方案的可靠性不是靠代码review看出来的，是靠故障演练练出来的。最简单的演练是杀掉消费者进程，观察消息积压情况，再启动进程看消息能不能继续消费积压。更狠一点的演练是模拟MQ broker挂掉，看本地消息表是不是正常积压、恢复后是不是能自动重发。还有更极端的——主库磁盘写满、订单服务重启导致事务消息状态都没更新，这套补偿机制能不能把数据追回来。这些演练做下来，你对自己系统的信心比看十篇文档都管用。

我用这套"本地消息表 + 定时补偿 + 兜底对账"的组合，帮两个团队落地过订单库存场景的事务改造，最终效果都差不多：正常流量下延迟没有明显增加，大促流量下通过MQ削峰保证了库存服务的可用性，最重要的是数据从来不需要人工修。倒是早期做TCC的那段时间，每天半夜收到补偿失败告警是常态，后来才意识到，很多业务场景的根本不需要那么强的可控性，把状态机和重试设计好，最终一致带来的收益远超那一点点延迟窗口。对了，如果你刚开始改造，给消息消费端加个处理耗时日志，线上排查不一致问题的时候，你会发现它比任何监控大盘都好使。