上个月做了一次代码走查对象是一个跑了两年的订单履约系统。最让我坐不住的不是某个算法写得有多绕而是orders表里那十几个状态字段PENDING、PAID、SHIPPED、DELIVERED、CANCELED、REFUNDING、REFUNDED……每排查一个线上问题都要先猜“这个状态是什么时候变的、是被哪个调用方改的、当时的库存扣掉了没有”。有几个晚上我翻着操作日志去拼一条订单的完整履历那种感觉就像从垃圾桶里把撕碎的票据捡回来拼剧情。走查结束后我把这个系统的数据模型推倒重来核心思路换成了 REAResource-Event-Agent模型。这篇文章不会堆学术定义我会把 REA 拆成可以直接落地的三件事Resource、Event、Agent 这三类实体到底怎么建模事件表怎么写、状态怎么还原以及我在真实订单系统上踩过的坑和取舍标准。适合正在设计业务系统数据层的开发者、架构师也适合被“状态字段地狱”折磨过的产品和技术同学。1. 状态字段模型的死穴你记住了“现在”却丢了“过程”1.1 状态机本质上是一份“结论”不保存“证据”任何一个带状态字段的业务表本质上都是一个状态机用status表示事情走到哪一步。但在生产环境里真正有价值的往往不是“当前状态”而是“从哪个状态怎么过来的”。举个例子一笔退款如果refund_status PARTIAL你只知道退到一半但不知道已经退了哪几笔、是谁发起的、每一笔对应哪张原始支付单。状态字段一旦被覆盖更新中间证据就永久消失了。我接手过的一个库存系统就是这个问题的典型样本库存表只有available_qty和updated_at每天凌晨跑批扣减扣错了就直接 UPDATE。后来要回查某天的真实扣减原因只能去找应用日志而应用日志只保留三十天。三十天之前的所有变动彻底变成黑盒。这就是状态机模型的代价——你为了“读起来方便”把“过程可回溯”牺牲掉了。1.2 审计和重放需求把状态字段模型逼到墙角有对账、审计、合规需求的系统几乎都会遇到同一个问题财务同学要求提供“截止到某个时点的库存或余额”。状态字段只能反映“现在”想看历史上任意一天的快照就必须有某种回放机制。很多团队的做法是每天定时把整张表导一份快照存档一张千万行级的表每天导全量存储和任务成本都非常高。而且快照之间发生多次变动的订单你只能看到头和尾中间过程照样是断的。REA 模型的回答很简单不要记录“现在的状态”记录“发生过的每一个原子事件”。状态永远从事件流里推导出来要哪天的快照就把事件流重新归集到那一天。这个思路其实和事件溯源异曲同工但 REA 给出了更严格的领域术语和建模边界尤其适合经济交换类业务。1.3 REA 的三个关键词一句话说清REA 起源于会计信息系统领域核心观点是一笔经济业务比如卖货、付钱可以用三类概念完整描述——Resource资源被交换或消耗的可计量资产比如商品、库存、现金、服务工时。Event事件资源发生数量增减的瞬间比如“卖出两件商品”“收到一百元付款”“消耗三小时工时”。Agent参与者/代理促使事件发生的内部或外部主体比如客户、供应商、仓库操作员、客服人员。在我重构订单系统时这三类概念正好对应到三个边界清晰的建模方向资源对应商品和账户事件对应订单流水和资金流水参与者对应用户和运营人员。剩下的工作重心不再是调状态而是设计好每个事件从哪来、改变什么资源、由谁触发。2. Resource、Event、Agent 的边界三个例子帮你少走弯路2.1 Resource 不是“数据表”而是“可计量的账本视角”很多人会把 Resource 直接理解为业务表比如“商品表就是 Resource”。这个理解不准确。商品表的属性里有名称、图片、类目这些是描述属性不是账本意义上可增减的资源。在 REA 里Resource 必须同时具备两个特征可以被计数或计量并且会因事件而发生增减。所以“商品定义”本身不是 Resource“库存商品”才是“用户”本身不是 Resource“用户账户余额”才是“订单”也不是 Resource“订单里已承诺交付的商品数量”才是。建模时我习惯先把系统的“账本对象”列出来而不是先列表结构。自测方法很简单遇到一个实体就问它会不会被某个事件加一或减一。会才考虑作为 Resource。2.2 Event 的粒度必须原子到“一次增减”级别事件是 REA 模型的引擎。最核心的建模规则是一次事件必须对应一个资源的单一方向增减。卖一单两件商品是“出库两件”这样一个事件而不是“订单生成”这样一个大状态。至于订单的整体流程——下单、付款、发货、收货——每一环在 REA 里都是独立事件分别改变库存和账户余额。Event 的粒度直接决定后续能不能算清楚账。如果你把“下单并支付”合并成一个事件就会出现一个问题这个事件同时改变了库存和账户余额两者增减的时点不同你要拆分的时候就只能临时造数据。保持单一方向、单一资源的原子事件才是后面做查询和统计的基础。2.3 Agent 与角色的分离同一主体要能在不同事件里扮演不同身份Agent 相对好理解但有个常见的建模错误是把“角色”直接塞进 Agent 表。之前我在一个客服退款流程里看到这样的设计agent_id字段既能填客户也能填客服靠一个agent_type去区分。表面上看很灵活实际查询时却麻烦——退款事件里的 Agent 到底是“发起退款的客户”还是“审核退款的客服”一个业务动作往往有两个 Agent 视角谁执行、对谁执行混在一列会让审计语义完全丢光。正确做法是把角色剥离出来。事件表里用两个外键分别表达“操作方”和“交易对手方”本质上都是指向 Agent 实体的外键但它们在语义上是不同角色。比如payment事件里一个是付款方 Agent一个是收款方 Agent。数据库层面可以冗余两个外键列应用层再去校验这两个 Agent 不能为同一人的业务规则。2.4 一张表理清典型业务对象在 REA 里的映射业务对象REA 分类说明商品档案描述数据不是 Resource只是资源的元数据库存数量Resource可增减、可计量出库动作Event库存资源的减量事件客户档案Agent业务主体的描述数据客户预存款余额Resource会被收款/扣款事件改变付款动作Event账户资源的增量/减量事件订单头表流程聚合可用作事件溯源边界但本身不是资源对账单派生视图完全可由事件流推导不需要单独建库这张表我现在每次动手设计前都会先画一遍不是为了赶时髦而是为了逼自己把所有“会变化的东西”找出来而不是只列一张静态业务表。3. REA 与双分录记账的差异以及我在一个订单系统上的改造实录3.1 双分录记账已经解决了什么又差点什么做财务系统的同学对借贷记账法一定很熟悉每笔业务至少记两笔分录资产等于负债加所有者权益。双分录的本质也是“记录过程”而且通过复式记账保证整体平衡。REA 其实就是从会计领域抽象出来的通用版本它比双分录更通用的地方在于不预设“借贷”和“会计科目”而是用“资源增减 相关事件”直接描述业务语义。但市面上大多数业务系统没有完整的会计能力。订单系统、库存系统、CRM都只是借用了“余额流水”的局部思想真正落地时每张表各写各的余额与流水之间没有强约束。REA 补上的正是这一环任何余额变化都必须由一个事件驱动事件之间再有资源流入和流出的对应关系。数据模型本身就把“对账平不平”变成了查询问题而不是事后比对两张表。3.2 某订单系统的改造实录从 15 张业务表收敛到 6 张核心表我改造的那个订单履约系统原设计里有订单主表、订单明细表、支付单表、退款单表、发货单表、售后单表、库存流水表一共 15 张业务表。表面看职责分得很清晰实际维护成本极高一次退款要同步更新支付单状态、订单状态、售后单状态、库存流水任何一个状态漏更整条链路就对不上账。引入 REA 之后表结构收敛成 6 张核心表agent所有内部外部参与者resource商品档案、库存、账户等账本对象event所有原子增减事件统一结构event_resource_link事件与资源的数量关联event_agent_link事件与参与者的角色关联aggregate_root流程聚合根承载订单这种业务主流程。原来分散在支付单、退款单、发货单里的状态字段全部下沉为事件表的属性字段。查询某个订单的当前状态只需要把该聚合根下所有事件按时间顺序播放一遍查询截止某天的库存也只需要过滤出该时点之前的事件做归集。改造上线后最直观的变化是月底对账从三天缩到了半小时而且任何一条有争议的订单都能给出完整事件链。3.3 改造时最重要的判断哪些表可以拆掉这里有一个关键经验拆表之前先问自己这张表里的字段是不是都可以由事件推导得出。支付单的paid_amount可以由付款事件推导拆退款单的refund_status可以由退款事件推导拆但订单主表里的customer_note、shipping_address_snapshot这种非账本信息不该拆它们是流程描述数据不是资源增减事件。很多团队在事件溯源实践里翻车是因为把描述数据也强行事件化最后事件表变成一个大杂烩查询写不下去。我的经验是只有“会影响账本数字”的变动才进事件流其他业务属性变更可以留在聚合根表里照样用于展示。这个判断直接决定了事件表的干净程度和后续性能。4. 落地 REA 的关键实现事件表设计、状态还原与幂等控制4.1 事件表的基本 Schema下面是我在订单系统里实际使用的一张简化版事件表核心就一个原则一张表装下所有原子事件用event_type区分语义。CREATE TABLE event_log ( id BIGSERIAL PRIMARY KEY, event_id UUID NOT NULL UNIQUE, -- 业务事件ID用于幂等 event_type VARCHAR(64) NOT NULL, -- 如 STOCK_OUT / PAYMENT_RECEIVED aggregate_type VARCHAR(32) NOT NULL, -- 订单 / 库存 / 账户 aggregate_id VARCHAR(64) NOT NULL, -- 聚合根ID occurred_at TIMESTAMPTZ NOT NULL, -- 业务发生时间不是入库时间 actor_agent_id BIGINT NOT NULL, -- 操作方 counterparty_agent_id BIGINT, -- 交易对手方可空 payload JSONB, -- 事件详情如数量、单价、备注 version BIGINT NOT NULL -- 聚合根版本号乐观锁用 ); CREATE INDEX idx_event_agg ON event_log (aggregate_type, aggregate_id, version); CREATE INDEX idx_event_time ON event_log (occurred_at);注意occurred_at和入库时间要分开我见过不少系统把created_at当成事件时间结果回放时因为入库延迟把事件顺序完全搞乱。业务发生时间应当由上游系统生成并随事件一起传入数据库只负责落库。4.2 状态还原先写清楚查询再设计事件结构REA 的常见质疑是“每次查当前状态都要回放全部事件性能怎么办”。我的回答是先把查询写对再谈优化。下面这段逻辑本质上是按聚合根聚合最后一次变更得到当前状态。def replay(aggregate_id, as_ofNone): events fetch_events(aggregate_id, occurred_at as_of) if as_of else fetch_events(aggregate_id) state default_state(aggregate_id) for event in events: if event[event_type] STOCK_OUT: state[stock] - event[payload][qty] elif event[event_type] STOCK_IN: state[stock] event[payload][qty] elif event[event_type] PAYMENT_RECEIVED: state[balance] event[payload][amount] return state如果每天回放产生大量请求标准解法是定期生成快照比如每小时把聚合根状态和最大事件版本号存在快照表里。下次查询先取最近快照再只回放快照版本之后的事件。我用下来这个方案在每天百万级事件的规模下也能稳定响应没必要一开始就上重量级框架。4.3 幂等与补偿事件模型最容易在这里翻车事件模型一旦把“改状态”变成“追加一条记录”幂等性就变成了头号敌人。数据库里我可以对event_id加唯一索引防止重复插入但业务层面的重复触发比想象中多得多——消息队列重投、上游接口重试、人为补单都会带来重复事件。我的做法分三层。第一层event_id唯一索引兜底重复插入直接忽略。第二层在聚合根表里维护last_version字段每个事件写入时用UPDATE ... WHERE version last_version 1做乐观锁失败就说明有并发事件冲突交给重试或人工处理。第三层对于确实需要撤销的错误事件不要 DELETE而是写一个反向的补偿事件比如STOCK_IN对应STOCK_OUT_REVERSAL这样历史事件链是完整不可篡改的对账也能看出纠正痕迹。5. 我踩过的四个 REA 落地坑以及对应的止血方案5.1 把“改状态”当成事件写事件流被污染改版初期我们团队里有同事习惯性地写了类似ORDER_STATUS_CHANGED这样的事件。这种事件没有对应的资源增减只会让回放逻辑充斥无效分支。后来我立了一条规则事件表里只允许出现有账本意义的事件状态变化可以由这些账本事件推导出来不需要单独记录。PAYMENT_RECEIVED推得出PAIDSTOCK_OUT推得出SHIPPED状态天然存在。凡是推不出来的状态基本都是伪状态应该质疑业务定义本身。5.2 事件没有版本号并发场景下快照直接错乱第一次上线时我们没有在聚合根上做版本控制结果遇到两个服务并发写同一订单事件先后落库但快照回放时把先写入的后播放了余额差了整整一笔。排查过程非常痛苦。加乐观锁之后情况明显好转冲突根本不是靠“独享锁”消除的而是靠“版本校验 失败重试”解决的。生产环境里重试三次成功率能到 99.9% 以上偶尔剩下来的人工处理成本完全可以接受。5.3 聚合根范围没控好一个事务锁了全仓库REA 模型容易让人把范围越划越大我见过一个需求里把“整张库存表”当成一个聚合根来设计所有库存事件串行落库。结果仓库所有商品的出入库都争同一把锁吞吐量直接崩掉。我的调整原则是单个商品或单 SKU作为一个聚合根事件只在该 SKU 范围内保证顺序跨 SKU 的事务需求通过补偿事件和异步对账来解决而不是让数据库一把大锁锁住一切。这个取舍几乎适用于所有高并发业务系统。5.4 权限模型没跟上 Agent 维度审计链路出现缺口最后一个是权限层面的坑。事件表里记录了操作 Agent但应用层常常只在写入时校验一次权限查询和回放时不做细粒度验证。结果低权限的内部账号可以直接调用回放接口看全量流水。虽然这是业务权限设计问题不是 REA 本身的问题但事件溯源把“细节数据”集中到了一张表暴露风险被放大了。后来我们给事件查询接口统一加了基于 Agent 角色的过滤条件并且对关键事件退款、库存调整增加操作者职责分离校验要求发起人和审批人不能是同一 Agent。6. REA 不是银弹哪些系统真的不适合以及我的选择标准6.1 REA 适合的场景其实都有同一个特征结合这次改造经历我认为适合上 REA 的系统都有同一个特征业务过程需要被审计、重放或重新解释。典型场景包括订单履约、库存管理、支付结算、会员积分、供应链协同。这些系统的共同点是金额或数量一变很多人要追责、要复盘、要对账。REA 天然为这类需求而生。6.2 三种我绝不会硬上 REA 的情况第一种是纯内容管理或配置管理比如后台的文章表、菜单表它们只有“最新状态”有价值历史版本偶尔需要但用普通版本字段就够了不需要演算账本。第二种是快速原型或短期运营工具事件模型初期开发成本比状态模型高不少如果产品生命周期就几个月性价比很低。第三种是核心报表完全依托复杂多维分析的系统比如给管理层做各类汇总报表事件流归集在分析型查询上并不高效更适合直接落库成汇总表和明细仓REA 可以作为上游数据源而不是查询层的承载者。6.3 我的个人选择判断现在我做技术选型会按这个顺序问自己这个数据会不会被要求“回看过往任意时点的准确状态”这个状态的每一次变化是否需要追溯操作方和原因业务方向上是否存在频繁的“纠错、补偿、反向操作”如果三个问题里至少有两个是肯定回答我就会认真考虑 REA如果只有一个肯定就退一步用普通状态机加审计日志如果都是否定那就直接上常规 CRUD别给自己加戏。经过这一轮改造我再次意识到 REA 的价值不在于时髦而在于逼着设计者回答一个朴素的问题你建模的是一个对象的“快照”还是一家企业的“账本”如果你的系统本质上在记账那就老老实实按记账的方式来建。我现在接手任何带钱、带库存、带积分的项目第一件事就是把 REA 映射先画出来哪怕最后因为团队熟练度没全量采用画图的过程也已经帮我把业务里的账本对象和事件边界梳理得明明白白。这个习惯比任何框架都值钱。
上个月做了一次代码走查对象是一个跑了两年的订单履约系统。最让我坐不住的不是某个算法写得有多绕而是orders表里那十几个状态字段PENDING、PAID、SHIPPED、DELIVERED、CANCELED、REFUNDING、REFUNDED……每排查一个线上问题都要先猜“这个状态是什么时候变的、是被哪个调用方改的、当时的库存扣掉了没有”。有几个晚上我翻着操作日志去拼一条订单的完整履历那种感觉就像从垃圾桶里把撕碎的票据捡回来拼剧情。走查结束后我把这个系统的数据模型推倒重来核心思路换成了 REAResource-Event-Agent模型。这篇文章不会堆学术定义我会把 REA 拆成可以直接落地的三件事Resource、Event、Agent 这三类实体到底怎么建模事件表怎么写、状态怎么还原以及我在真实订单系统上踩过的坑和取舍标准。适合正在设计业务系统数据层的开发者、架构师也适合被“状态字段地狱”折磨过的产品和技术同学。1. 状态字段模型的死穴你记住了“现在”却丢了“过程”1.1 状态机本质上是一份“结论”不保存“证据”任何一个带状态字段的业务表本质上都是一个状态机用status表示事情走到哪一步。但在生产环境里真正有价值的往往不是“当前状态”而是“从哪个状态怎么过来的”。举个例子一笔退款如果refund_status PARTIAL你只知道退到一半但不知道已经退了哪几笔、是谁发起的、每一笔对应哪张原始支付单。状态字段一旦被覆盖更新中间证据就永久消失了。我接手过的一个库存系统就是这个问题的典型样本库存表只有available_qty和updated_at每天凌晨跑批扣减扣错了就直接 UPDATE。后来要回查某天的真实扣减原因只能去找应用日志而应用日志只保留三十天。三十天之前的所有变动彻底变成黑盒。这就是状态机模型的代价——你为了“读起来方便”把“过程可回溯”牺牲掉了。1.2 审计和重放需求把状态字段模型逼到墙角有对账、审计、合规需求的系统几乎都会遇到同一个问题财务同学要求提供“截止到某个时点的库存或余额”。状态字段只能反映“现在”想看历史上任意一天的快照就必须有某种回放机制。很多团队的做法是每天定时把整张表导一份快照存档一张千万行级的表每天导全量存储和任务成本都非常高。而且快照之间发生多次变动的订单你只能看到头和尾中间过程照样是断的。REA 模型的回答很简单不要记录“现在的状态”记录“发生过的每一个原子事件”。状态永远从事件流里推导出来要哪天的快照就把事件流重新归集到那一天。这个思路其实和事件溯源异曲同工但 REA 给出了更严格的领域术语和建模边界尤其适合经济交换类业务。1.3 REA 的三个关键词一句话说清REA 起源于会计信息系统领域核心观点是一笔经济业务比如卖货、付钱可以用三类概念完整描述——Resource资源被交换或消耗的可计量资产比如商品、库存、现金、服务工时。Event事件资源发生数量增减的瞬间比如“卖出两件商品”“收到一百元付款”“消耗三小时工时”。Agent参与者/代理促使事件发生的内部或外部主体比如客户、供应商、仓库操作员、客服人员。在我重构订单系统时这三类概念正好对应到三个边界清晰的建模方向资源对应商品和账户事件对应订单流水和资金流水参与者对应用户和运营人员。剩下的工作重心不再是调状态而是设计好每个事件从哪来、改变什么资源、由谁触发。2. Resource、Event、Agent 的边界三个例子帮你少走弯路2.1 Resource 不是“数据表”而是“可计量的账本视角”很多人会把 Resource 直接理解为业务表比如“商品表就是 Resource”。这个理解不准确。商品表的属性里有名称、图片、类目这些是描述属性不是账本意义上可增减的资源。在 REA 里Resource 必须同时具备两个特征可以被计数或计量并且会因事件而发生增减。所以“商品定义”本身不是 Resource“库存商品”才是“用户”本身不是 Resource“用户账户余额”才是“订单”也不是 Resource“订单里已承诺交付的商品数量”才是。建模时我习惯先把系统的“账本对象”列出来而不是先列表结构。自测方法很简单遇到一个实体就问它会不会被某个事件加一或减一。会才考虑作为 Resource。2.2 Event 的粒度必须原子到“一次增减”级别事件是 REA 模型的引擎。最核心的建模规则是一次事件必须对应一个资源的单一方向增减。卖一单两件商品是“出库两件”这样一个事件而不是“订单生成”这样一个大状态。至于订单的整体流程——下单、付款、发货、收货——每一环在 REA 里都是独立事件分别改变库存和账户余额。Event 的粒度直接决定后续能不能算清楚账。如果你把“下单并支付”合并成一个事件就会出现一个问题这个事件同时改变了库存和账户余额两者增减的时点不同你要拆分的时候就只能临时造数据。保持单一方向、单一资源的原子事件才是后面做查询和统计的基础。2.3 Agent 与角色的分离同一主体要能在不同事件里扮演不同身份Agent 相对好理解但有个常见的建模错误是把“角色”直接塞进 Agent 表。之前我在一个客服退款流程里看到这样的设计agent_id字段既能填客户也能填客服靠一个agent_type去区分。表面上看很灵活实际查询时却麻烦——退款事件里的 Agent 到底是“发起退款的客户”还是“审核退款的客服”一个业务动作往往有两个 Agent 视角谁执行、对谁执行混在一列会让审计语义完全丢光。正确做法是把角色剥离出来。事件表里用两个外键分别表达“操作方”和“交易对手方”本质上都是指向 Agent 实体的外键但它们在语义上是不同角色。比如payment事件里一个是付款方 Agent一个是收款方 Agent。数据库层面可以冗余两个外键列应用层再去校验这两个 Agent 不能为同一人的业务规则。2.4 一张表理清典型业务对象在 REA 里的映射业务对象REA 分类说明商品档案描述数据不是 Resource只是资源的元数据库存数量Resource可增减、可计量出库动作Event库存资源的减量事件客户档案Agent业务主体的描述数据客户预存款余额Resource会被收款/扣款事件改变付款动作Event账户资源的增量/减量事件订单头表流程聚合可用作事件溯源边界但本身不是资源对账单派生视图完全可由事件流推导不需要单独建库这张表我现在每次动手设计前都会先画一遍不是为了赶时髦而是为了逼自己把所有“会变化的东西”找出来而不是只列一张静态业务表。3. REA 与双分录记账的差异以及我在一个订单系统上的改造实录3.1 双分录记账已经解决了什么又差点什么做财务系统的同学对借贷记账法一定很熟悉每笔业务至少记两笔分录资产等于负债加所有者权益。双分录的本质也是“记录过程”而且通过复式记账保证整体平衡。REA 其实就是从会计领域抽象出来的通用版本它比双分录更通用的地方在于不预设“借贷”和“会计科目”而是用“资源增减 相关事件”直接描述业务语义。但市面上大多数业务系统没有完整的会计能力。订单系统、库存系统、CRM都只是借用了“余额流水”的局部思想真正落地时每张表各写各的余额与流水之间没有强约束。REA 补上的正是这一环任何余额变化都必须由一个事件驱动事件之间再有资源流入和流出的对应关系。数据模型本身就把“对账平不平”变成了查询问题而不是事后比对两张表。3.2 某订单系统的改造实录从 15 张业务表收敛到 6 张核心表我改造的那个订单履约系统原设计里有订单主表、订单明细表、支付单表、退款单表、发货单表、售后单表、库存流水表一共 15 张业务表。表面看职责分得很清晰实际维护成本极高一次退款要同步更新支付单状态、订单状态、售后单状态、库存流水任何一个状态漏更整条链路就对不上账。引入 REA 之后表结构收敛成 6 张核心表agent所有内部外部参与者resource商品档案、库存、账户等账本对象event所有原子增减事件统一结构event_resource_link事件与资源的数量关联event_agent_link事件与参与者的角色关联aggregate_root流程聚合根承载订单这种业务主流程。原来分散在支付单、退款单、发货单里的状态字段全部下沉为事件表的属性字段。查询某个订单的当前状态只需要把该聚合根下所有事件按时间顺序播放一遍查询截止某天的库存也只需要过滤出该时点之前的事件做归集。改造上线后最直观的变化是月底对账从三天缩到了半小时而且任何一条有争议的订单都能给出完整事件链。3.3 改造时最重要的判断哪些表可以拆掉这里有一个关键经验拆表之前先问自己这张表里的字段是不是都可以由事件推导得出。支付单的paid_amount可以由付款事件推导拆退款单的refund_status可以由退款事件推导拆但订单主表里的customer_note、shipping_address_snapshot这种非账本信息不该拆它们是流程描述数据不是资源增减事件。很多团队在事件溯源实践里翻车是因为把描述数据也强行事件化最后事件表变成一个大杂烩查询写不下去。我的经验是只有“会影响账本数字”的变动才进事件流其他业务属性变更可以留在聚合根表里照样用于展示。这个判断直接决定了事件表的干净程度和后续性能。4. 落地 REA 的关键实现事件表设计、状态还原与幂等控制4.1 事件表的基本 Schema下面是我在订单系统里实际使用的一张简化版事件表核心就一个原则一张表装下所有原子事件用event_type区分语义。CREATE TABLE event_log ( id BIGSERIAL PRIMARY KEY, event_id UUID NOT NULL UNIQUE, -- 业务事件ID用于幂等 event_type VARCHAR(64) NOT NULL, -- 如 STOCK_OUT / PAYMENT_RECEIVED aggregate_type VARCHAR(32) NOT NULL, -- 订单 / 库存 / 账户 aggregate_id VARCHAR(64) NOT NULL, -- 聚合根ID occurred_at TIMESTAMPTZ NOT NULL, -- 业务发生时间不是入库时间 actor_agent_id BIGINT NOT NULL, -- 操作方 counterparty_agent_id BIGINT, -- 交易对手方可空 payload JSONB, -- 事件详情如数量、单价、备注 version BIGINT NOT NULL -- 聚合根版本号乐观锁用 ); CREATE INDEX idx_event_agg ON event_log (aggregate_type, aggregate_id, version); CREATE INDEX idx_event_time ON event_log (occurred_at);注意occurred_at和入库时间要分开我见过不少系统把created_at当成事件时间结果回放时因为入库延迟把事件顺序完全搞乱。业务发生时间应当由上游系统生成并随事件一起传入数据库只负责落库。4.2 状态还原先写清楚查询再设计事件结构REA 的常见质疑是“每次查当前状态都要回放全部事件性能怎么办”。我的回答是先把查询写对再谈优化。下面这段逻辑本质上是按聚合根聚合最后一次变更得到当前状态。def replay(aggregate_id, as_ofNone): events fetch_events(aggregate_id, occurred_at as_of) if as_of else fetch_events(aggregate_id) state default_state(aggregate_id) for event in events: if event[event_type] STOCK_OUT: state[stock] - event[payload][qty] elif event[event_type] STOCK_IN: state[stock] event[payload][qty] elif event[event_type] PAYMENT_RECEIVED: state[balance] event[payload][amount] return state如果每天回放产生大量请求标准解法是定期生成快照比如每小时把聚合根状态和最大事件版本号存在快照表里。下次查询先取最近快照再只回放快照版本之后的事件。我用下来这个方案在每天百万级事件的规模下也能稳定响应没必要一开始就上重量级框架。4.3 幂等与补偿事件模型最容易在这里翻车事件模型一旦把“改状态”变成“追加一条记录”幂等性就变成了头号敌人。数据库里我可以对event_id加唯一索引防止重复插入但业务层面的重复触发比想象中多得多——消息队列重投、上游接口重试、人为补单都会带来重复事件。我的做法分三层。第一层event_id唯一索引兜底重复插入直接忽略。第二层在聚合根表里维护last_version字段每个事件写入时用UPDATE ... WHERE version last_version 1做乐观锁失败就说明有并发事件冲突交给重试或人工处理。第三层对于确实需要撤销的错误事件不要 DELETE而是写一个反向的补偿事件比如STOCK_IN对应STOCK_OUT_REVERSAL这样历史事件链是完整不可篡改的对账也能看出纠正痕迹。5. 我踩过的四个 REA 落地坑以及对应的止血方案5.1 把“改状态”当成事件写事件流被污染改版初期我们团队里有同事习惯性地写了类似ORDER_STATUS_CHANGED这样的事件。这种事件没有对应的资源增减只会让回放逻辑充斥无效分支。后来我立了一条规则事件表里只允许出现有账本意义的事件状态变化可以由这些账本事件推导出来不需要单独记录。PAYMENT_RECEIVED推得出PAIDSTOCK_OUT推得出SHIPPED状态天然存在。凡是推不出来的状态基本都是伪状态应该质疑业务定义本身。5.2 事件没有版本号并发场景下快照直接错乱第一次上线时我们没有在聚合根上做版本控制结果遇到两个服务并发写同一订单事件先后落库但快照回放时把先写入的后播放了余额差了整整一笔。排查过程非常痛苦。加乐观锁之后情况明显好转冲突根本不是靠“独享锁”消除的而是靠“版本校验 失败重试”解决的。生产环境里重试三次成功率能到 99.9% 以上偶尔剩下来的人工处理成本完全可以接受。5.3 聚合根范围没控好一个事务锁了全仓库REA 模型容易让人把范围越划越大我见过一个需求里把“整张库存表”当成一个聚合根来设计所有库存事件串行落库。结果仓库所有商品的出入库都争同一把锁吞吐量直接崩掉。我的调整原则是单个商品或单 SKU作为一个聚合根事件只在该 SKU 范围内保证顺序跨 SKU 的事务需求通过补偿事件和异步对账来解决而不是让数据库一把大锁锁住一切。这个取舍几乎适用于所有高并发业务系统。5.4 权限模型没跟上 Agent 维度审计链路出现缺口最后一个是权限层面的坑。事件表里记录了操作 Agent但应用层常常只在写入时校验一次权限查询和回放时不做细粒度验证。结果低权限的内部账号可以直接调用回放接口看全量流水。虽然这是业务权限设计问题不是 REA 本身的问题但事件溯源把“细节数据”集中到了一张表暴露风险被放大了。后来我们给事件查询接口统一加了基于 Agent 角色的过滤条件并且对关键事件退款、库存调整增加操作者职责分离校验要求发起人和审批人不能是同一 Agent。6. REA 不是银弹哪些系统真的不适合以及我的选择标准6.1 REA 适合的场景其实都有同一个特征结合这次改造经历我认为适合上 REA 的系统都有同一个特征业务过程需要被审计、重放或重新解释。典型场景包括订单履约、库存管理、支付结算、会员积分、供应链协同。这些系统的共同点是金额或数量一变很多人要追责、要复盘、要对账。REA 天然为这类需求而生。6.2 三种我绝不会硬上 REA 的情况第一种是纯内容管理或配置管理比如后台的文章表、菜单表它们只有“最新状态”有价值历史版本偶尔需要但用普通版本字段就够了不需要演算账本。第二种是快速原型或短期运营工具事件模型初期开发成本比状态模型高不少如果产品生命周期就几个月性价比很低。第三种是核心报表完全依托复杂多维分析的系统比如给管理层做各类汇总报表事件流归集在分析型查询上并不高效更适合直接落库成汇总表和明细仓REA 可以作为上游数据源而不是查询层的承载者。6.3 我的个人选择判断现在我做技术选型会按这个顺序问自己这个数据会不会被要求“回看过往任意时点的准确状态”这个状态的每一次变化是否需要追溯操作方和原因业务方向上是否存在频繁的“纠错、补偿、反向操作”如果三个问题里至少有两个是肯定回答我就会认真考虑 REA如果只有一个肯定就退一步用普通状态机加审计日志如果都是否定那就直接上常规 CRUD别给自己加戏。经过这一轮改造我再次意识到 REA 的价值不在于时髦而在于逼着设计者回答一个朴素的问题你建模的是一个对象的“快照”还是一家企业的“账本”如果你的系统本质上在记账那就老老实实按记账的方式来建。我现在接手任何带钱、带库存、带积分的项目第一件事就是把 REA 映射先画出来哪怕最后因为团队熟练度没全量采用画图的过程也已经帮我把业务里的账本对象和事件边界梳理得明明白白。这个习惯比任何框架都值钱。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
