返利系统架构实践：分布式事务、最终一致性与对账机制

双十一前一天晚上，我和团队盯着监控大屏，订单流入量曲线开始以近乎垂直的角度往上走。那一瞬间所有人想的不只是"订单系统扛不扛得住"，还有一个更折磨人的问题：每一笔成功交易的返利记录，有没有可能丢？有没有可能给用户多发？ 返利APP和普通电商有个本质区别——用户下单在别的平台，返利APP只负责"记账"和"发钱"这两件事。正是这两件事，把架构难度拉到了一个相当高的水位。这篇博文就围绕我们这套返利系统的核心架构展开：分布式事务怎么做、最终一致性如何落地、数据可靠性靠什么兜底。适合正在做电商中台、交易类系统、返利/分销类业务的架构师和高级后端开发参考，哪怕你只负责其中一环，里面关于幂等、对账、状态机的思路也能直接套用。

1. 返利链路到底难在哪：一笔返利从用户下单到提现的全过程

返利业务表面看很简单：用户从APP领券，跳转到电商平台下单，平台确认订单后，我们给用户返一笔钱。但要把这个闭环跑通且不出错，技术侧面对的问题远不止"记一条数据"这么简单。

1.1 返利业务的核心链路拆解

我们系统里一条返利记录的生命周期是这样的：

1. 用户在返利APP点击商品，生成带有渠道标识的跳转链接，进入电商平台。
2. 用户在电商平台完成下单支付。
3. 电商平台通过开放接口或订单同步任务，把订单状态回传给我们的订单同步服务。
4. 订单同步服务判断订单状态（已支付、已结算、已退款等），计算返利金额。
5. 返利服务写返利流水，更新用户账户余额或返利券余额。
6. 用户发起提现，资金从公司账户划出。

这一步链路跨了两个大系统边界：外部电商平台的订单系统，以及我们自己的账户和返利系统。外部平台的订单我们"管不着"，只能靠接口轮询或回调感知状态变化；内部系统之间则需要靠消息队列、任务调度和数据库事务协作。也就是说，整个过程天然就是一个跨系统、跨网络的分布式场景。

1.2 记返利这件事的两个技术死结

第一个死结是金额不能多也不能少。返利比例是运营配的，商品可能在下单后发生退款、售后、维权，订单金额可变，返利金额必须跟着变。如果返利比该给的多，公司直接损失真金白银；如果少给，用户投诉和流失立刻就来。

第二个死结是外部订单状态有延迟且不可控。电商平台不会在我们下单那一刻就立刻告知"订单已结算"，往往要等确认收货、售后期结束后才会推送最终状态。这中间可能隔了几天甚至一个月。在这个过程中，用户可能退款，可能部分退款，可能换货，每一种情况都会改变最后该返的金额。

所以我们一开始就明确了一个原则：返利系统绝对不能在"未确认"状态下就拍板给用户打钱。 这决定了整个架构必须围绕状态机、对账和最终一致性来设计，而不是追求"一次调用立即成功"的强一致。这也是标题里"最终一致性"不是一句口号，而是每一条返利记录必须经过的确认步骤。

2. 分布式事务选型：我们为什么没有迷信全局事务框架

提到分布式事务，大部分人第一反应是Seata、TCC、Saga这类框架。我们调研过，也做过POC，但最后在核心返利链路上没有采用全局事务框架，而是走了一条更"朴素"但更可控的路：状态机加本地消息表。下面说清楚为什么。

2.1 本地事务能解决的部分

先画一条边界：在我们自己的系统内部，MySQL的单库事务依然可靠。比如用户发起提现，需要同时更新"用户余额"和"提现流水"两张表，这个强一致直接用本地事务解决，不需要引入任何分布式事务组件。

需要分布式事务协作的，主要是两类场景：

• 订单状态变更后，通知多个下游系统同步更新。 比如订单确认了，要写返利流水、更新用户的累计消费额、更新商品维度的返利统计。三个操作不要求同一毫秒完成，但要求最终都完成。
• 外部系统的状态流转和我们内部状态流转无法放在一个事务里。 外部平台说"订单已结算"，我们内部要把订单状态从"已支付"改成"已结算"，并生成返利记录。这两个动作跨组织边界，只能靠异步协调。

对于第一类场景，我们要求"数据库写入和消息发送必须同时成功或同时失败"。这其实是一个经典问题——先写库再发消息，数据库提交了消息发失败怎么办？先发消息再写库，消息发了数据库没写怎么办？

我们的答案不是引入消息事务，而是用本地消息表。把"业务操作"和"待发送消息"放在同一个本地事务里写入数据库，再由一个定时任务把消息表里的记录可靠地投递到MQ。这样数据库和消息之间的一致性就被"本地事务"保住了。

2.2 用本地消息表保证"发消息不丢"

具体流程长这样：

code复制业务操作 + 写待发送消息表   ->  在同一个MySQL事务内提交
定时任务扫描待发送消息表     ->  将消息写入MQ
MQ消费者处理消息             ->  完成后回调更新消息表状态为"已发送"

每个步骤都在代码里做了可重入设计。消息表的核心字段包括：消息ID、业务类型、业务主键ID、消息内容（JSON）、状态（待发送/已发送/已死信）、重试次数、下次重试时间。

定时任务扫描时会跳过"未到达重试时间"的记录，避免失败后立即反复重试打爆MQ。连续失败超过阈值（我们设的是10次）的消息，自动转成"已死信"状态，由告警通知开发人员人工介入。

这套方案的好处是：所有状态都在数据库里有据可查，出了问题可以从消息表直接看到哪条消息卡住了、卡了多久、内容是什么。相比引入Seata这类框架，它少了一层全局锁和协调器，性能开销更低，也更适合我们这种"大部分操作都是异步最终完成"的业务模型。

2.3 状态机：把大事务拆成可重试的小步骤

另一个关键设计是订单返利状态机。我们没有把"订单同步→计算返利→发消息→用户余额更新"做成一个大事务，而是拆成多个带状态的小步骤。每一步执行失败，都停留在当前状态，等下次重试继续，而不是回滚整个流程。

状态机设计如下：

每个状态流转都对应一个独立的"任务"，任务有独立的消费组和重试机制。这样任何一个环节出问题，最多卡住那一条数据，不会影响整个系统。

举个最典型的例子：订单已支付但还没确认收货，这时候用户发起退款。退款状态下，返利必须取消。但"订单退款"和"返利流水取消"不是同时发生的，退款请求到达时可能返利流水还没生成。我们的处理是让状态机停在WAIT_CONFIRM，等后续同步到最终状态后再决定是生成还是取消。这个设计彻底避免了"退款和返利同时发生"的竞态。

3. 最终一致性落地的关键设计：消息对账与自愈机制

状态机保证的是"流程能走下去"，但没法保证"外部数据和我们内部数据始终一致"。外部平台的订单状态可能变了而我们的同步接口没有收到推送；消息队列丢了消息没有重试；定时任务漏跑了一次。这种场景下，最终一致性靠的不是消息可靠投递，而是对账。

3.1 对账任务如何发现并修正漏单

我们在订单同步服务里加了一个每小时跑一次的对账任务。逻辑很直接：

1. 从电商平台接口拉取过去24小时内状态有变化的订单ID列表。
2. 与本地订单表中的订单ID做比对。
3. 找出本地缺失的订单，重新执行同步流程。
4. 找出本地状态与外部不一致的订单，触发状态校正。

这个对账任务在低峰期跑，一次拉取几千个订单不会对接口造成压力。但要注意，电商平台的订单接口有访问频率限制，我们封装了一层带令牌桶的拉取客户端，每秒钟最多发出30个请求，防止触发限流被封。

对账不能发现的问题，只能靠用户侧反馈。所以我们客服系统里专门接了一个"返利查询"接口，用户反馈"订单没返利"时，客服输入订单号，系统自动触发一次对该订单的强制同步。这也是最终一致性里很重要的"人工兜底"。

3.2 幂等写入的两种实战做法

分布式环境下，消息重复是常态，不是异常。消费者可能处理完消息后还没来得及提交offset，进程就崩溃了；也可能是MQ本身做了重试投递。无论哪种，下游都必须要做幂等处理，否则一条订单被同步两次，用户就被返两次利。

我们在返利流水表上建了一个唯一索引：订单号+商品ID+用户ID。这是最粗暴也最有效的防线。任何重复的消息，执行INSERT时直接因为唯一键冲突失败，程序捕获冲突后判断"流水已存在"，就不再做任何操作。

但唯一索引只能挡住"完全重复"的请求，挡不住"同一订单但不同动作"的请求。比如订单先同步成"已支付"，用户退款后又同步成"已退款"。这两条消息的订单号一样，但业务动作不同。我们的处理方式是引入版本号字段，每条订单同步消息里带一个sync_version，消费者执行更新时，使用乐观锁机制：

sql复制UPDATE order_return SET
  status = #{newStatus},
  sync_version = #{newVersion}
WHERE order_no = #{orderNo}
  AND sync_version < #{newVersion}

只有新版本的同步消息才能更新成功，旧版本即使晚到也不会覆盖新状态。这就像给每条订单的状态变更排了队，谁版本号大听谁的。

3.3 自愈机制：返利金额自动重算

订单在确认收货之后，可能发生售后退款，这时候返利金额要跟着变。但我们的返利流水在确认阶段已经生成了，不能简单删除，也不能粗暴更新，因为用户余额可能已经变了。

自愈流程是这样的：

1. 退款消息到达后，先查返利流水状态。
2. 如果返利流水处于CONFIRMED状态（已生成但未入账），直接更新金额或标记取消。
3. 如果已经PAID（已入账），则需要生成一条负数返利流水，冲抵用户余额。
4. 上述操作全部记为一次"返利调整流水"，方便财务审核。

这一步看似简单，实际最容易出问题的地方是：负数和正数的操作顺序。如果先加正数再加负数，用户余额会出现瞬时虚高；如果先减负数再加正数，用户余额会出现瞬时虚低。我们对"入账"统一要求：先冲抵后入账，即负数流水优先。这样即使用户在调整期间发起提现，也不会多提走一分钱。

4. 数据可靠性：MySQL主从、延迟与容灾设计

聊完分布式事务和最终一致性，再说数据可靠性的底座。我们核心数据全部在MySQL，订单表、返利流水表、消息表、用户余额表都在这上面。数据可靠性的第一个问题不是"会不会丢"，而是"读到的数据是不是准的"。

4.1 读写分离遇到的主从延迟问题

为了扛住大促流量，我们做了主从读写分离。订单查询、返利记录查询走从库，写入走主库。这套架构在平时没有任何问题，大促期间却暴露了一个很隐蔽的bug：

用户刚下完单，立刻刷新订单列表，结果看不到新订单。原因就是写入走了主库，读取走了从库，而主从复制有一定延迟。我们线上实测，高峰期主从延迟可以到3到5秒，用户端表现为"下了单但记录消失"。

这个问题的解决思路有三层：

• 核心链路的实时读取强制走主库。 比如订单详情的初始加载、回跳页的返利状态展示，这些场景用户对实时性要求极高，哪怕多付出一些主库压力也值得。
• 列表页允许从库延迟，但加一个"刚刚写入"的标记。 用户下单成功后，我们把订单ID写到Redis的近期写入集合里，列表查询从库结果出来后，检查结果集是否包含这些ID，缺失则重新从主库补查。这个方案避免了全量走主库的容量压力。
• 消息表这类内部任务表，允许延迟，但必须监控延迟值。 主从延迟超过30秒就告警，说明同步链路可能出问题了。

4.2 幂等键与唯一索引的底线职责

数据可靠性不能只靠业务代码自觉，数据库层面必须有兜底。我们几乎所有核心流水表都有唯一索引。除了前面说的返利流水表，提现流水表、余额变更流水表也都有biz_id唯一键，biz_id 由"业务类型+业务单号+操作序号"拼接生成。

有一次线上事故让我印象很深：一个定时任务因为网络抖动重跑了，一次性向提现流水表插入了2000条重复记录。如果没有唯一索引，用户余额会被扣2000次。当时唯一索引直接拒绝了所有重复插入，监控立刻报警，我们定位到问题后一键把误扣的余额原路退回去。可以说，唯一索引是数据可靠性的最后一道闸门，绝对不能省。

还有一个细节：唯一索引字段最好不要用自增ID做主键，而是用"业务唯一键"做主键或额外唯一键，否则等遇到重复写入时已经晚了，垃圾数据已经进去了。

4.3 容灾与数据不丢的底线

存储层的容灾，我们用了同城双活方案。主库在机房A，实时备份在机房B，通过半同步复制保证数据不丢。这里要特别说一句：全同步复制不现实，半同步复制才是性价比之选。 全同步会拖垮主库写入性能，半同步只要保证至少一个备库收到binlog就算提交成功，已经是性能和可靠性的很好平衡。

我们也做了跨区域的异步备份，用于应对机房整体不可用的极端情况。异步备份允许丢最后一小段数据，但可以保证绝不出现大面积数据丢失。

定期备份策略：每天全量备份一次，binlog实时归档保留30天。这保证即使误操作删表，也能恢复到任意时间点。

5. 大促期间的压测与故障演练：我们如何验证这套架构

架构设计得再漂亮，没有经过验证都是废纸。我们每年大促前会做两轮完整的压测和故障演练，每次都能逼出几个平时发现不了的问题。

5.1 压测发现的两个瓶颈

第一轮压测，我们只模拟正常的订单流入，结果发现消息消费者组的TPS只能跑到每秒300条，再往上延迟就开始飙升。定位后发现瓶颈不在消费逻辑，而在一个不起眼的操作：消费者处理完消息后更新消息表状态，这个UPDATE操作全部走主库，主库的瓶颈很快被打满。

解决办法是把消息表的"状态更新"和"业务处理"解耦。消费者先执行业务处理，成功后把成功记录写入Redis（带过期时间），消息表的状态更新延迟到定时任务批量处理。这样主库的UPDATE次数从每秒上千次降到了每秒几十次批量操作。

第二个瓶颈是订单同步接口的数据库连接池被打满。原因是每个订单回调都要查询一次订单表确认是否存在，这个读操作占用了大量连接。优化方式是加了一层Redis缓存，订单存在性判断直接查缓存，缓存未命中再查数据库并回填。

5.2 故障演练中暴露的细节问题

故障演练我们做过最刺激的一次：直接kill掉主库所在机房的所有MySQL进程，模拟机房失联。预期是秒级自动切换备库，实际结果花了差不多50秒才完成切换，期间部分写入直接超时。

50秒主要耗在探测和确认上，因为我们要确认主库是彻底挂了而不是网络抖动，这个确认机制太保守。后来优化了探测策略：连续三次健康检查失败就触发切换，时间缩短到15秒以内。

还有一次演练是模拟MQ集群整体不可用。当时我们发现了一个问题：本地消息表里积压的消息在MQ恢复后瞬间全部涌入消费者，导致下游数据库连接被打爆。后来加了"消费者启动后先限速运行一分钟"的策略，让消费速率从每秒100条逐步提升到每秒1000条，给下游一个预热过程。

5.3 降级方案与用户预期管理

即使做了这么多保障，极端情况下还是要给用户一个交代。我们的降级分三个等级：

• L1降级：返利延迟到账。 消息积压但数据库正常，用户端展示"返利确认中"，实际延迟最多不超过2小时。
• L2降级：订单同步暂停。 外部平台接口不稳定，暂停拉取新订单，只处理存量订单。此时新用户下单后看不到返利进度，需要文案提示。
• L3降级：只读模式。 数据库写入受限，关闭提现和返利入账功能，保留浏览和跳转功能。降级期间产生的交易先记录到本地日志，恢复后由对账任务补偿。

降级不是"系统挂了才用"，而是在容量快触及上限时主动启用。我们监控里专门有一条规则：当核心写链路TP99延迟超过500ms且持续5分钟，就自动触发L1降级通知，由值班同学决定是否开启。

6. 踩坑实录与排查链路复盘

最后分享几个我们真实踩过的坑。这些坑在文档里都查不到，只能靠一次次的事故和复盘积累。

6.1 重复返利事故：问题出在消息重复消费

有一次线上出现用户反馈"同一笔订单返了两次钱"。查到最后，问题出在消息消费者重试机制上。某个消费者处理完订单同步消息后，因为线程卡顿没有及时提交offset，MQ判定处理失败重新投递，于是同一条消息又被另一个消费者实例消费了一次。

当时返利流水表的唯一索引锁住了这单的"首次成功写入"，第二次消费理论上应该因为唯一索引冲突退出。但问题就出在：首次消费只更新了订单状态为"已确认"并生成了返利流水，第二次消费时，代码逻辑会"检查返利流水表是否已存在，不存在则创建"。由于第一次消费的事务还没完全提交时，第二次消费已经开始了，读到的结果是"流水不存在"，于是又插了一条。

这个问题的根因是唯一索引只能防并发插入，防不了先查后插的竞态窗口。修复方式很直接：把"检查流水是否存在并插入"改成纯INSERT，让唯一索引自己去判断冲突，捕获到冲突就退出，删掉所有"先查询再插入"的写法。

6.2 主从延迟导致未支付订单被误判

还有一次对账任务跑完后，一批未支付订单被标记成了"已确认返利"。原因是：对账任务从外部接口拉取了订单状态，拉取时订单还是"已支付"，但本地订单表因为主从延迟，读到的最新状态还停留在"未支付"。任务比较了两边的数据，发现"外部状态晚于本地状态"，就自动执行了状态推进，把一个未支付订单推进成了已确认。

这个问题的本质是对账任务不能盲目以外部数据为准，必须结合本地状态机约束。修复方式是对对账任务支持"只看不回"模式：先比对标记差异，再由人工或单独的任务审核确认后，才实际修改状态。状态机设计时，"外部状态更新"和"本地状态更新"之间增加了一个中间态SYNC_VERIFY，避免一步到位。

6.3 消息队列堆积导致返利延迟

有一次因为上游系统接口响应慢，订单同步消费者的处理时间从平均50ms涨到平均800ms，消费速率下降，MQ里积压了上百万条消息，用户返利延迟了将近三个小时。

这个事故让我们意识到，消息消费者的自我保护机制比下游接口更优先。现在每个消费者都配置了线程池隔离和调用超时，下游接口超过2秒直接快速失败，消息进入本地重试队列，不再占用消费线程。这样可以保证即使某个外部接口抖动，也只是局部消息慢，不会引发全链路堆积。

6.4 重启顺序引发的数据错乱

最后一个坑不是很技术，但很现实：发布时服务重启顺序也会影响数据。我们有一次先重启了返利服务，后重启订单同步服务，结果订单同步服务启动后立刻拉取了一批增量订单，但返利服务还没完全启动完成，导致一部分订单的返利流程没有触发。

现在我们的发布流程固定为先启动消费者服务（返利服务、消息服务），再启动生产者服务（订单同步服务），配合启动完成后延迟30秒再接流量的策略，基本杜绝了这个和顺序相关的低级错误。

最后再分享一点个人体会

做完整个返利架构折腾下来，我最深的体会是：高可用架构的核心不是"用了什么框架"，而是"每个环节想没想清楚失败以后怎么办"。本地消息表、状态机、对账任务、唯一索引、半同步复制，这些手段单独看都不炫酷，但组合起来就能形成一条完整的防御链。

如果后端文章里那些场景能让你有所收获，我建议你在自己的系统里至少先把"唯一索引+状态机+对账任务"这三件事落地。哪怕其他组件全部使用现成框架，这三件事也能帮你解决分布式环境下一大半的"数据错乱"。至于剩下的那一小半，等真正踩到坑了，再回头读这篇文章，你会更有感触。