很多团队做业务系统做久了，都会走到一个很相似的死局：订单、库存、资金、优惠券、积分各自维护一套流水，单独看都像模像样，合在一起月底对账就成了全组最怕的事。我在重构某个零售模拟项目的时候，把业务数据从“流水叠加”的模式，切换到了REA（Resource-Event-Agent，资源—事件—主体）建模。这里不是简单引入一个概念，而是从实体拆分、事件流转、幂等并发、对账排查全部换了一套做法。这篇文章就把整段落地的过程、模型设计、踩坑记录和边界聊清楚，适合被订单、资金、库存一致性折磨的后端、数据产品、架构师拿来参考。
1. 旧系统里为什么会有“对不上”：三种典型账目事故
1.1 库存和资金各算各的账，月底全靠开发救火
我接手那个项目时，系统其实已经跑了两三年。库存模块有库存流水，订单模块有订单流水，支付模块有资金流水，看上去各司其职。但一到月底对账，问题就全冒出来了。最典型的一种：库存系统按“订单创建扣减、退款回补”来记账，资金系统却按“支付成功金额、退款成功金额”来记账。两个系统对同一笔交易的时间口径不一样，跨天对账永远会差出几个数。
比如一笔订单在晚上 23:58 支付，支付系统把它记在当天；但库存扣减动作因为异步任务延迟，落到了第二天。月底核对时，当天的资金流入和库存流出就对不齐。对不上之后怎么办？很多团队会写补丁脚本，按订单号把两边拉平。补丁越写越多，系统里积累了一堆“调整”“冲正”“手工修正”的痕迹，真正的业务事实反而被埋掉了。
1.2 优惠券、积分被当成状态字段直接改
第二个让我下决心重构的事故发生在优惠券模块。业务方在后台看到一个用户有两张满减券，但用户在 App 上只看到一张。开发去查数据库，发现券记录的状态字段被直接 update 成了“已核销”，而核销的动作没有任何独立记录。也就是说，系统只保存了“券当前是什么状态”，没有保存“是什么行为让状态变成了这样”。
这就带来一个很现实的问题：运营想追溯某张券是哪一笔订单核销的、核销时满减金额是多少、是用户自己操作还是系统自动触发，只能靠日志、缓存、外部分析系统来回拼。更麻烦的是，积分模块也有类似问题。积分余额字段被各处服务直接累加或扣减，一旦某条链路重复执行，积分就悄悄多发或漏发，用户客服投诉时连一条有说服力的变更记录都拿不出来。
1.3 从“流水叠加”到 REA：换一个视角看业务
REA 模型的核心并不复杂，它把业务系统里的重要事实分成三个维度：
- Resource（资源）：企业里具有价值、可以被交换或消耗的对象，比如现金、库存商品、积分、优惠券、应收款。
- Event（事件）：改变资源状态的行为事实，比如支付到账、商品出库、优惠券核销、退款退回。
- Agent（主体）：参与事件的内部或外部角色，比如客户、运营人员、仓库操作员、自动任务。
我把这三种典型事故放回 REA 里重新审视，发现所有“对不上”都有一个共同根源：系统里存了很多结果，却没有存完整的原因。事件和状态混在一张表里，主体信息也被丢掉了。后来我们把每一条关键业务行为变成一个独立事件，让所有资源状态都由事件推导，很多旧问题就不再是问题，而是变成了可复算的逻辑。
2. 实体拆分的硬功夫：Resource / Event / Agent 的边界划分
刚到 REA 建模时，最容易犯的错就是把“余额”“库存数”这种东西当成 Resource 存下来。这个误区很隐蔽，因为从业务语言上看，“库存余额”听起来就是一个资源，但它实际上是从入库事件和出库事件推导出来的结果。真正应该落库的 Resource，是那些稳定存在、可以被描述和追踪的资产对象本身。
2.1 Resource：存“资产对象”而不是“余额”
以某个 SKU 的库存为例。在旧表里通常会有sku_id, warehouse_id, quantity, updated_at这样的结构，quantity 就是库存余额。问题在于，余额是多个系统并发写入同一个字段的结果，任何一条链路出错，余额就脏了，而且没有任何办法判断是谁让它脏的。
在 REA 模型里，Resource 层只保存资产对象的基本档案。比如商品资源表会记录resource_id, resource_type, name, spec, unit，说明“这是一个商品库存资源，单位是件、库位是 A-01”，但不直接保存“当前剩余多少件”。“剩余多少件”由 Resource 关联的事件来计算。现金也是一样，账面现金余额不是 Resource，银行存款账户才是；余额是用“流入事件合计减流出事件合计”算出来的。
让我用一个具体例子说明为什么这个区分重要。曾经有同事问：可以把“优惠券剩余库存”也建成 Resource 吗？我的回答是，可以，但你要建的是“优惠券批次”这个资产对象，而不是“剩余张数”。批次有面值、有效期、适用范围，这些是描述性的属性；而“剩余张数”是发放事件和核销事件累计的结果。把结果当对象存，早晚有一天会因为某个链路的遗漏或重复，让余额表和事件明细对不上。
2.2 Event：只有不可变事实才能进事件表
REA 里的 Event 不是“操作日志”，也不是“接口调用记录”。它必须是在真实世界里已经发生的、不可撤销的业务事实。比如“订单创建”本身不是一个好的经济事件，因为它还没有引起任何资源的变化；真正的事件应该是“库存承诺生效”“支付到账”“商品出库”“商品退回”“现金退款”。
事件表的核心字段通常长这样：
CREATE TABLE rea_event ( event_id BIGINT PRIMARY KEY AUTO_INCREMENT, event_type VARCHAR(64) NOT NULL, biz_type VARCHAR(32) NOT NULL, biz_no VARCHAR(64) NOT NULL, line_no INT NOT NULL DEFAULT 0, occurred_at DATETIME NOT NULL, created_at DATETIME NOT NULL, agent_id VARCHAR(64) NOT NULL, resource_id VARCHAR(64) NOT NULL, direction VARCHAR(8) NOT NULL, quantity DECIMAL(20,4) NOT NULL, link_event_id BIGINT NULL, payload JSON NULL, UNIQUE KEY uk_biz (biz_type, biz_no, line_no) );关键点在于：event_type决定了业务语义，direction表示对资源是流入还是流出，link_event_id用来连接一对相互交换的事件。事件表禁止 update 和 delete，只能 insert，这是底线。如果某笔业务后来发现错了，正确做法是新增一个方向相反的事件来冲销，而不是去修改旧事件。
这种“不可变”设计的好处，用信用卡账单来类比就很清楚。账单上的每一笔消费记录如果可以被随意覆盖修改，最终余额就没有任何可信度；只有保留每笔原始交易，再累加计算，到账金额才能被核对。
2.3 Agent：让人和系统对得上号的第二维度
Agent 是 REA 里容易被忽略但实际价值极高的一环。很多系统在设计流水表时，只记“用户ID”或“操作人ID”，却没有区分用户、运营、仓库、自动任务这些不同主体类型。结果出了问题，连“是人工改的还是系统自动改的”都分不清。
我们落地时把 Agent 单独建模，拆分成了内部 Agent 和外部 Agent。外部 Agent 包括客户、供应商、渠道平台；内部 Agent 包括运营人员、仓库操作员、客服人员，以及各类自动化任务。每个 Agent 都对应一个全局编号，事件表里的agent_id指向这个编号。这样做之后，对账就不只按资源和时间维度拆，还能按主体维度拆，很多诡异的数据差异一下子就有了方向。
我记得最深刻的一次：运营在某天手动发了一批补偿券，因为后台页面的提交按钮被连点两次，同一批券发放事件被插入了两条。旧版系统里这就是两笔真实记录，用户也确实领到了两张券，业务上反而说不清用户是否被多发。REA 模型下，我们在 Agent 字段里记录了运营人员和发放任务标识，再配合幂等键定位到同一来源，很快发现是页面重复提交导致的重复事件，比之前靠导出 Excel 人工数快太多了。
3. 从订单创建到对账：一组完整的事件流与业务语义走查
模型讲再多，不如把一个订单从下单到对账完整走一遍。我用的例子是一个实物商品的线上销售流程，包含库存、支付、发货、收货、退款五个环节。
3.1 一个订单从下单到收款的完整事件走查
在 REA 模型里，下单本身不是经济事件，它是一组承诺的开始。真正改变资源状态的事件发生在后边。下面这张表是我们项目里使用的核心事件清单：
| 业务阶段 | 事件类型 | 资源方向 | 涉及资源 | 涉及主体 | 说明 |
|---|---|---|---|---|---|
| 提交订单 | 库存承诺生效 | 流出（预占） | 商品库存 | 用户 | 库存还没实际减少，但已被占用 |
| 支付回调 | 支付到账 | 流入 | 资金账户 | 用户/支付渠道 | 资金增加，可看作对交付商品的交换 |
| 仓库发货 | 商品出库 | 流出 | 商品库存 | 仓库操作员 | 库存从可用变为已出库 |
| 用户签收 | 物流签收 | 流入 | 商品库存（客户视角） | 用户 | 客户资源增加，公司应收义务解除 |
| 申请退款 | 退款支付 | 流出 | 资金账户 | 客服/系统 | 资金减少，商品如退回则触发逆向入库 |
有一部分团队会把“订单创建”直接放进事件表，理由是“所有业务变更都要留痕”。我不反对记录订单头状态变化，但会明确地区分开“业务单据操作记录”和“经济事件”。订单头、订单项这些是业务过程的载体，适合放在普通业务表里；而 REA 事件表专注于描述资源变化。这两个池子如果混在一起，事件表的语义就糊了，后期做对账聚合时非常痛苦。
3.2 事件对偶性：为什么退款不会产生“蝴蝶效应”
REA 模型里有个很有意思的规则：一笔完整的经济交换，一定会产生两个方向相反、相互印证的事件。比如卖一个商品换一笔钱，对应的事件是“商品出库”和“资金到账”；用户退货退款时，对应的是“商品回库”和“资金流出”。这两个事件之间通过link_event_id关联起来。
这条规则帮我解决了一个长期困扰团队的问题：退款为什么总把账面搞乱。旧系统里退款只更新退款状态和资金流水，库存回补是另一条异步消息；如果异步消息丢了，库存永远少了那几件库存，线上库存数据不错才怪。REA 建模后，退款被拆成两个必须同生共死的事件：资金流出事件和商品流入事件。我们要求这两个事件在同一个事务里写下去，或者至少保证最终一致且具备对账可发现性。
如果发现只写了“资金流出”却没有“商品回库”，对账系统立刻会在事件对偶校验中报出来。是问题就可以被早发现，而不是等到月末复盘才发现库存账面又差了几十件。
3.3 库存、应收、资金余额：全部由事件推导
当所有资源变化都变成事件之后，余额、库存、应收这些指标就不再需要独立维护。对账时直接查询事件表即可计算：
SELECT resource_id, SUM(CASE WHEN direction = 'IN' THEN quantity ELSE 0 END) AS total_in, SUM(CASE WHEN direction = 'OUT' THEN quantity ELSE 0 END) AS total_out, SUM(CASE WHEN direction = 'IN' THEN quantity ELSE -quantity END) AS balance FROM rea_event WHERE resource_id = :resourceId GROUP BY resource_id;当然，生产环境很少直接全量扫描事件表算余额，那样性能扛不住。常见的做法是“事件表 + 物化快照表”并存。事件表负责还原事实，快照表负责把某一时刻的累计结果先算好。查询时用快照加增量事件来得出最新余额，既保证正确性，又保证查询速度。
这一点是 REA 落地中最容易变成过度理想主义的地方。很多文章说“状态全部来自事件回放”，但现实里一个库存资源的每日事件可能有上百万条，每次全部回放一遍根本不现实。折中的办法是每 5 分钟或者每个自然日生成一次快照，并记录快照对应的最大事件 ID。查询余额时，只用“快照余额 + 快照之后的新事件”来推导。这样事件保留审计能力，快照保证查询性能，两边都顾到。
4. 落地工程里最值得较真的三个细节：幂等、并发、事务边界
4.1 幂等键：重复回调不可怕，可怕的是重复入账
支付回调、消息重试、用户重复点击，这些在分布式系统里几乎是必然发生的事。REA 事件表如果没有幂等键，同一个业务事件被插入两次，资源就会被错误地加两次或减两次，对账差异就这么来了。
我们的实现方案是在rea_event表上增加一个由业务类型、业务单号和行号组成的唯一键：
def handle_event(event_payload): biz_no = event_payload["biz_no"] existing = event_repo.find_by_biz(biz_no) if existing: return existing.event_id with db_transaction(): event_id = event_repo.insert(event_payload) snapshot.apply_increment(event_payload) return event_id代码的逻辑很简单：先查重，再在事务里同时写事件和更新快照。查重的目的不是剩一次查询，而是让重复提交的请求可以拿到同一个结果，不会报错，也不会入两次账。这个设计做完后，支付渠道方哪怕因为超时反复回调同一个支付单，也不会产生脏账，线上账单瞬间安静了下来。
4.2 并发扣库存：事件插入和资源锁得住吗
有人问过我：REA 强调事件只追加，那并发扣库存怎么防超卖？这个问题问得很好。事件表只追加确实让我们无法靠“事件表行锁”来串行化并发，但库存资源本身有一个物化快照行，我们可以锁住它。
具体做法是，在扣减库存时，先对资源维度对应的快照行加行锁，然后检查当前余额是否足够，如果足够才插入“商品出库”事件并更新快照。行锁保证了同一时间只有一个事务能够修改该资源的快照，超卖在源头就被挡住了。锁的粒度要按真实业务需求来设计：库存资源可以细到“SKU + 仓库”维度，现金资源可以细到“账户 + 币种”维度。
这个方案让我意识到，REA 不是拒绝状态，而是把状态放到受控的位置。事件负责证据，状态负责性能与并发，两者分工，缺一不可。
4.3 事务边界与跨服务消息可靠性
事件写入和快照更新必须在同一个事务里，这个容易理解。更麻烦的是跨服务场景。订单服务支付成功后，需要通知库存服务发货，还要通知积分服务加分。如果只用普通消息队列，消息可能丢失，也可能重复消费。REA 落地后，我们把跨服务的业务事实先作为事件落到本地事件表，再由一个可靠的发布管道把事件推送出去。消费者收到事件后，按幂等键去重再入库。这样整个链路不再是命令式的“你去扣库存”，而是事件式的“支付已发生”，每个服务各自消费事实、更新自己的资源状态。
这个过程中最痛的教训是：一开始我们试图让所有服务共享同一个 REA 事件库，结果耦合太深，任何一个服务发布新事件类型都得通知所有人评估影响面，非常拖沓。后来调整为每个服务维护自己域内的事件表，跨域通过事件消息同步，主键统一采用全局业务单号。这个收敛速度快了很多。
5. 线上账目排查案例：把“凭感觉对账”变成“按事件复算”
5.1 一次优惠券差四张的排查全记录
项目上线一段时间后，业务方反馈电商平台里“某渠道核销的满减券数量”和优惠券系统的统计数据差了 4 张。换作以前，这种问题大概率要拉一堆 Excel 出来比对，然后靠猜。这次我们按 REA 的思路走了一遍完全不同的排查流程。
第一步，按资源、事件类型、主体维度拆开差异。我们用对账 SQL 查出该券批次在 REA 事件表里的核销事件合计，再去优惠券系统查核销记录合计，发现差的 4 张全部集中在某个渠道入口，而且时间段在同一天。
第二步，拉出这 4 张券对应的事件明细和原始业务单号。结果发现，这 4 条记录的biz_no在 REA 事件表里其实已经存在，只是因为旧接口没有把biz_no传到事件幂等键中，导致补偿逻辑又插入了一次重复事件。
第三步，修复旧接口的幂等键生成规则，并写了一个一次性修正脚本来冲销重复事件。因为底层事件表设计成了不可修改，我们新增了 4 条反向事件，让重复计入的数量归零。整个过程没有手工改动任何原始数据，所有修正行为都可以在事件表里查到。
这个案例给我的最大感受是，REA 把“排查对账差异”从一门手艺活变成了一个标准流程。差异出现后，我先能确认“什么是事实”，再去找“哪个环节违背了事实”，而不是在几套互相覆盖的流水里猜谁才是真的。
5.2 REA 不做什么：模型的边界在哪里
REA 很好用，但它不是锤子，也不是所有钉子都要用。它真正擅长的是资源稀缺、交换行为频繁、资金与库存一致性要求高的场景。对一个内部知识库系统来说，文档的创建和编辑就不是典型的经济事件，硬要套 REA 反而会把系统搞复杂。
另外，REA 对团队的业务理解要求也比普通 CRUD 要高。设计事件表和资源表时，必须和业务方确认“什么才是不可变事实”。如果业务方自己都说不清一笔调整是“冲正”还是“新交易”，那事件类型设计就会陷入反复。我后来习惯在建模前先写一份事件字典，明确每个事件的发生时机、资源影响方向、对偶事件是什么。这份字典比任何代码评审都更能暴露理解不一致的问题。
6. 项目结束后我才积累的几条实操习惯
6.1 把事件字典当作公共 API 来维护
REA 的事件表一旦长起来，最怕的就是同一个语义叫了不同的名字，或者同一个event_type在不同服务里行为不一致。项目后期，我们建立了每周评审事件字典的机制，新增事件必须说明资源范围、主体范围、对偶关系和对账口径。这个机制帮我们挡住了至少两次把“支付成功”和“支付回调接收”混为一谈的设计事故。事件字典不只是一份文档，它是一种团队契约。
6.2 给事件留两个时间字段
每个事件至少要有两个时间：occurred_at（业务发生时间）和created_at（系统写入时间）。对账一律以业务发生时间为准。后补数据时必须显式指定业务发生时间，否则补录的事件会全部落在当天，把当天的对账数据搞乱。这个细节最开始没做好，后来补了很多麻烦。
6.3 补偿必须走反向事件，不允许裸改数据库
运营和客服手里常常握着“调整”权限。我们严格规定，任何补偿、退券、退库存都必须走系统里的反向事件入口。开发人员更不能在运维台上直接 update 事件或冲正快照。所有修正都留下痕迹。这一点需要管理层和一线执行者同时接受，但对账质量提升的速度会远超预期。
每次回看过这个从“流水叠加”到 REA 建模的重构，我最真实的体会是，模型本身并不难理解，难的是用一套严格的规则约束团队里的每一个人和每一个系统。只要事件写的干净，资源就能算得清，账目自然对得平。如果你也有团队正被对账折磨，不妨从一个小模块开始试做 REA 事件化改造，先把“事实”和“状态”分离，再看后续的变化。
