TigerBeetle 如何用链式转账把账户余额约束在上限与下限之间【免费下载链接】tigerbeetleThe financial transactions database designed for mission critical safety and performance.项目地址: https://gitcode.com/GitHub_Trending/ti/tigerbeetle在 TigerBeetle 里创建一个账户时余额天然只受一个方向的约束账户上的flags.debits_must_not_exceed_credits或flags.credits_must_not_exceed_debits标志只能保证余额不为负下限且这是数据库层保证、永不被破坏的不变量。如果你还想让余额有一个上限比如某个账户余额不能超过 Limit数据库不会替你守住它——TigerBeetle 官方文档的 Balance Bounds recipe 给出的做法是把每一笔业务转账改写成一次create_transfers请求里的5 笔 linked 转账5 笔要么全部成功、要么全部失败从而原子地检查并强制上限。这篇文章按该 recipe 讲清楚需要准备哪几个账户、5 笔转账各自的字段怎么填、链条内部如何完成检查以及响应里怎么判断成功、失败和配错。为什么上限不能只靠账户标志must_not_exceed这类标志是账户级不变量只要标志设上去了任何转账都不可能违反它。上限不同它是每笔转账都必须强制执行的检查——Balance Bounds recipe 明确指出只要某笔转账没有执行这个检查余额就完全可能超出上限。所以上限约束是应用层在每次create_transfers请求里主动构造出来的不能假设账户创建一次就一劳永逸。准备条件三个账户recipe 的 Preconditions 部分要求先建好三个账户目标账户被限制余额的账户按余额类型设置其中一个标志贷方余额credit balance账户flags.debits_must_not_exceed_credits借方余额debit balance账户flags.credits_must_not_exceed_debits两个标志互斥不能同时设置。控制账户Control Account设置与目标账户相反方向的标志目标账户是贷方余额 → 控制账户设flags.credits_must_not_exceed_debits目标账户是借方余额 → 控制账户设flags.debits_must_not_exceed_credits文档说明这个账户实际上永远不会真正持有目标账户的资金只是通过链条里一进一出的转账把上限量出来。操作账户Operator Account用于在链条中给控制账户充入 Limit 金额。执行步骤一次请求里的 5 笔 linked 转账先区分两个金额recipe 中的定义limit amountLimit你要为余额维持的上限值transfer amountTransfer本笔业务想转出的金额——只有当转账后余额仍在上下限之内时才允许成功。linked 的语义见 Linked Eventsflags.linked把本事件的结果与请求中下一个事件绑定链条上的事件要么全部成功、要么全部回滚链条的最后一笔必须不带flags.linked否则会报linked_event_chain_open。所以下面 5 笔转账必须放在同一个create_transfers请求里。目标账户是贷方余额此时被限制的是收款方Destination账户的余额5 笔转账如下转账借方账户贷方账户金额Pending IDFlags1SourceDestinationTransfer-flags.linked2ControlOperatorLimit-flags.linked3DestinationControlAMOUNT_MAX-flags.linked|flags.balancing_debit|flags.pending4---转账 3 的id*flags.linked|flags.void_pending_transfer5OperatorControlLimit-无标志链条在此结束*pending_id必须指向链条里那笔 pending 转账此处是转账 3的id。几个字段取值依据 Transfer 参考转账 3 的AMOUNT_MAX即2^128 - 1。配合flags.balancing_debit它表示最多转这么多实际转出金额由 Destination 账户的约束决定。转账 4 是 void-pending 转账amount为 0 时会自动设置为被作废 pending 转账的金额所以表里金额列留空即可debit_account_id/credit_account_id为 0 时也会自动取 pending 转账的值。flags.balancing_debit/flags.balancing_credit与flags.post_pending_transfer/flags.void_pending_transfer互斥转账 3 上不能同时出现这些组合。目标账户是借方余额方向和标志对称同样是 5 笔转账借方账户贷方账户金额Pending IDFlags1DestinationSourceTransfer-flags.linked2OperatorControlLimit-flags.linked3ControlDestinationAMOUNT_MAX-flags.balancing_credit|flags.pending|flags.linked4---转账 3 的id*flags.void_pending_transfer|flags.linked5ControlOperatorLimit-无标志链条在此结束链条内部是如何完成上限检查的recipe 的 Understanding the Mechanism 逐笔解释了作用转账 1是真正想执行的业务转账。转账 2把控制账户的余额设置到你要强加的上限值Limit。转账 3用balancing_debit贷方余额场景或balancing_credit借方余额场景把 Destination 账户的净余额量到控制账户上。如果转账 1 会让 Destination 的余额超过上限这一步会失败并连带拖垮整条链。它同时带flags.pending所以即使成功资金也只是被预留、并未真正划走。转账 4作废void第 3 笔 pending 转账撤销它留下的预留。转账 5把控制账户的净余额重置回零。净效果整条链成功时只有转账 1 产生了业务上的资金移动25 全部自相抵消一旦上限检查不通过5 笔一起失败转账 1 也不会生效。结果验证读create_transfers的响应create_transfers返回一个与每笔转账对应的结果数组状态判断依据 create_transfers 参考成功5 笔转账的结果均为created。应用崩溃后用同一组id重发时可能返回exists——文档建议多数应用把exists与created一样处理。上限被触发链条中第一个失败的转账会返回它自己的具体错误例如触碰账户不变量时的exceeds_credits/exceeds_debits链条内其余转账统一返回linked_event_failed。看到这个组合即可判定业务转账未生效是上限检查拒绝了它。配置错误的典型现象链条最后一笔误带了flags.linked→linked_event_chain_open转账 3 上混用了互斥标志 →flags_are_mutually_exclusive标志兼容矩阵见 create_transfers 参考。注意exceeds_credits/exceeds_debits属于瞬态错误该Transfer.id对应的这次尝试被记录后即使日后状态变化、重试也会返回id_already_failed。如果业务上确实要再转一次必须生成一个新的幂等id重新提交而不是原样重试。边界与限制上限不是数据库不变量。文档原话提醒必须对每一笔转账都执行这套 5 笔链条某次转账如果没走这套检查余额就超出了上限而不会报错。下限则相反由账户标志保证。Limit 不是账户上的字段它体现在每次请求里转账 2 和转账 5 的amount上。调整上限就是调整这两笔转账的金额。5 笔转账的 linked 关系只在同一个请求内成立不能把链条拆成多个请求。转账是只追加、不可修改、不可删除的链条成功与否都留痕符合审计要求。完成这套构造后你可以对照 Linked Events 理解多链在同一个请求中如何独立成败以及 Data Modeling 中借方/贷方余额与上下限 recipe 的对应关系。【免费下载链接】tigerbeetleThe financial transactions database designed for mission critical safety and performance.项目地址: https://gitcode.com/GitHub_Trending/ti/tigerbeetle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考