尧图网页设计 
TigerBeetle 复合分录实战用 Linked Transfers 与 Control Account 实现多借多贷转账【免费下载链接】tigerbeetleThe financial transactions database designed for mission critical safety and performance.项目地址: https://gitcode.com/GitHub_Trending/ti/tigerbeetleTigerBeetle 的核心转账原语Transfer只支持单借单贷——一笔转账从一个账户借记、向另一个账户贷记这是其追求极致性能与精简设计的结果。但在真实业务中拆单、税费抽取、分账结算等场景天然需要一对多多对一多对多的复合分录。本文以仓库文档 docs/coding/recipes/multi-debit-credit-transfers.md 为骨架系统讲解如何利用flags.linked链接转账与控制账户Control Account把多个单借单贷转账组合成原子化的复合分录并深入到src/state_machine.zig验证balancing_debit/balancing_credit的底层实现。读完后你将能够用链接链实现一对多/多对一转账、用平衡标志在余额未知时能转多少转多少、以及用控制账户搭建多对多转账与限量凑单方案。为什么 TigerBeetle 只有单借单贷TigerBeetle 是为追求最大性能而设计的金融数据库。为了保持精简lean数据库只支持单一借记 单一贷记的简单转账一个Transfer字段中只有一个debit_account_id和一个credit_account_id参见 docs/reference/transfer.md。复合分录不是数据库内置原语而是由应用层组合多个 Transfer 实现的。但这并不意味着你需要放弃复杂的业务模型。TigerBeetle 提供的两个核心杠杆是链接事件Linked Events——用flags.linked把多条转账焊接成一条要么全成功、要么全失败的原子链平衡转账Balancing Transfers——用flags.balancing_debit/flags.balancing_credit在不知道账户余额的情况下自动转出尽可能多的金额。下面先讲基石再逐步展开一对多、多对多方案。基石Linked Transfers 如何保证原子性所有示例都依赖flags.linked来保证一组转账同生共死。其语义详见 docs/coding/linked-events.md 与 docs/reference/transfer.md#flagslinked设置flags.linked后本事件的成败与请求中下一条事件绑定链条的最后一笔转账不能带flags.linked——它标志链的结束。若最后一条仍带该标志会返回linked_event_chain_open错误链内事件按顺序执行任一失败则整条链回滚链内其他事件统一返回linked_event_failed首个失败事件返回其真实错误码完整错误码列表见 docs/reference/requests/create_transfers.md一个请求中可以存在多条相互独立的链链本身不会被持久化保存若需要在事后查询这些转账的关联关系应把关联 ID 写入user_data_128等字段见 docs/coding/data-modeling.md#user_data。各客户端语言中该标志都有对应枚举值。以 Python 客户端为例见 src/clients/python/src/tigerbeetle/bindings.pyTransferFlags是一个IntFlag标志值NONE0LINKED1 0PENDING1 1POST_PENDING_TRANSFER1 2VOID_PENDING_TRANSFER1 3BALANCING_DEBIT1 4BALANCING_CREDIT1 5CLOSING_DEBIT1 6CLOSING_CREDIT1 7IMPORTED1 8LINKED、BALANCING_DEBIT、BALANCING_CREDIT正是本文反复使用的三个标志。一对多转账One-to-Many Transfers多个借方 单个贷方或单个借方 多个贷方是一类相对直接relatively straightforward的场景只需把多条转账放进同一条链接链即可。单借多贷一个账户同时给多个账户打款场景从源账户A借记同时向X、Y、Z三个目的账户贷记全部在USD账本上。资金流如下LedgerDebit AccountCredit AccountAmountflags.linkedUSDAX10000trueUSDAY50trueUSDAZ10false注意最后一条A → Z的flags.linked为false它闭合整条链。三笔转账要么全部提交、要么全部回滚中间任何一笔失败例如A余额不足都不会造成部分成功。多借单贷多个账户共同向一个账户打款场景从A、B、C三个源账户借记统一贷记到目的账户XLedgerDebit AccountCredit AccountAmountflags.linkedUSDAX10000trueUSDBX50trueUSDCX10false多借单贷 余额调配Balancing Debits上面的多借单贷要求应用事先知道每笔金额。但真实场景往往是目标总额已知比如100而每个借方账户的余额未知——希望每个借方按优先级顺序尽量多贡献凑满目标总额。这就是Balancing Debits方案也是最有技巧性的一个。它引入两个控制账户三个源账户A、B、C均带flags.debits_must_not_exceed_credits即只允许支出不超过其贷方余额余额为 credit balance 且不允许为负概念见 docs/coding/data-modeling.md#credit-balances控制账户LIMIT同样带debits_must_not_exceed_credits充当配额上限控制账户SETUP用于支起setupLIMIT账户的额度本身不设任何余额限制。整条链共 6 笔转账| Id | Ledger | Debit Account | Credit Account | Amount | Flags | | -: | -----: | ------------: | -------------: | -----------: | :------------- | | 1 | USD |SETUP|LIMIT| 100 |linked| | 2 | USD |A|SETUP| 100 |linked,balancing_debit,balancing_credit| | 3 | USD |B|SETUP| 100 |linked,balancing_debit,balancing_credit| | 4 | USD |C|SETUP| 100 |linked,balancing_debit,balancing_credit| | 5 | USD |SETUP|X| 100 |linked| | 6 | USD |LIMIT|SETUP|AMOUNT_MAX|balancing_credit|机制拆解第 1 笔SETUP → LIMIT 100把LIMIT的贷方余额充值到 100为整个方案定义上限配额第 24 笔A/B/C → SETUP同时带balancing_debit借方尽量转与balancing_credit贷方按接收能力收。由于SETUP已在第 1 笔付出 100其可接收额度正好也是 100因此A、B、C按转账顺序依次填满这 100 的缺口余额足的账户贡献满额余额不足的账户贡献其全部后续账户自动收到 0 金额转账0.16.0起零金额转账是合法的见 docs/reference/requests/create_transfers.md第 5 笔SETUP → X 100把集中起来的资金一次性转给最终目的账户X第 6 笔LIMIT → SETUP AMOUNT_MAX仅balancing_credit不带linked是链的终点把LIMIT中仍保留的 100 转回SETUP使两个控制账户余额归零——LIMIT的AMOUNT_MAX在balancing_credit语义下就是最多转这么多实际金额受约束裁剪。失败语义原文明确指出的关键点如果A B C的累计 credit balance 小于100整条链会失败——第 6 笔转账将返回exceeds_credits。原因如下SETUP只收到了不足 100 的资金其第 6 笔的balancing_credit上限SETUP可接收量会超过 100而LIMIT带debits_must_not_exceed_credits约束无法在只有 100 贷方余额的情况下被借记超过 100于是触发exceeds_credits整条链接链回滚X 分文未收。这正是凑不满就不交易的原子保证。顺带一提balancing_debit/balancing_credit与closing_debit/closing_credit的组合还有另一个著名用例——关户清零参见 docs/coding/recipes/close-account.md。多对多转账Many-to-Many TransfersControl Account 模式当一笔分录同时有多个借方和多个贷方时事情要稍微复杂一些多对多。此时会计学中的**控制账户Control Account**概念就派上了用场把它作为中间过渡账户。以下例子使用的账户两个源账户A、BUSD账本三个目的账户X、Y、ZUSD账本一个复合分录控制账户ControlUSD账本。LedgerDebit AccountCredit AccountAmountflags.linkedUSDAControl10000trueUSDBControl50trueUSDControlX9000trueUSDControlY1000trueUSDControlZ50false思路是先用两条转账把A、B的钱收进Control再用三条转账从Control分发给X、Y、Z。Control账户在整个方案中的净余额恒为零——它只是资金的中转站。五条转账同属一条链接链任一步失败则整体回滚不会出现收了钱却没发出去的中间态。性能取舍何时可以绕过 Control Account细心的读者可能已经发现在上面的例子中B → Control50与Control → Z50金额恰好相等完全可以直连成B → Z。这正是原文档docs/coding/recipes/multi-debit-credit-transfers.md明确指出的优化空间为了追求更极致的性能你可以考虑实现一些逻辑在可能的情况下绕过控制账户从而减少实现一条复合分录所需的转账条数。由于 TigerBeetle 的吞吐与转账条数强相关减少无谓的中转转账能带来直接的性能收益。但文档也给出了务实的建议如果你刚开始接入完全可以避免过早优化——统一用控制账户来编程所有复合分录等业务跑通后再回来榨取这部分性能也不迟。底层原理balancing 标志在状态机中如何计算实际金额balancing_debit/balancing_credit的能转多少转多少究竟是怎么实现的答案在转账状态机的核心函数create_transfer中src/state_machine.zigfn create_transfer(附近的amount_actual计算约 L3841-L3853const amount_actual amount: { var amount t.amount; if (t.flags.balancing_debit) { const dr_balance dr_account.debits_posted dr_account.debits_pending; amount min(amount, dr_account.credits_posted -| dr_balance); } if (t.flags.balancing_credit) { const cr_balance cr_account.credits_posted cr_account.credits_pending; amount min(amount, cr_account.debits_posted -| cr_balance); } break :amount amount; };结合 docs/reference/transfer.md#flagsbalancing_debit 与 docs/reference/transfer.md#flagsbalancing_credit 的文档语义可归纳为balancing_debit请求金额是上限实际转账金额被借方账户约束裁剪——保证debit_account.debits_pending debit_account.debits_posted ≤ debit_account.credits_posted即借方不会转出超过其贷方余额的资金对 credit-balance 账户即余额不为负balancing_credit同理实际金额被贷方账户约束裁剪——保证credit_account.credits_pending credit_account.credits_posted ≤ credit_account.debits_posted即贷方不会收到超过其已付出总额的资金。两个标志正交兼容可以同时设置如前面A → SETUP的转账最终金额取两方约束的较小值。记录到账本上的amount是裁剪后的实际转账金额这一点对幂等重试语义有重要影响重试一笔 balancing 转账时只有当重试请求中的最大金额不足以覆盖已实际转账的金额时才会返回exists_with_different_amount否则即使金额不同也会返回exists详见 docs/reference/requests/create_transfers.md#exists_with_different_amount。这保证了你可以在崩溃恢复后安全地重放请求而不会造成重复扣款。可运行的 Python 示例下面用官方 Python 客户端src/clients/python/src/tigerbeetle/bindings.py把单借多贷写成可运行的代码。实际生产环境建议用 TigerBeetle Time-Based Identifier 生成id并在ledger、code等字段上遵守你的账本规划见 docs/coding/data-modeling.md#ledgersfrom tigerbeetle import Client, Transfer, TransferFlags client Client(cluster_id0, replica_addresses[3000]) # 账户 A 借记X / Y / Z 贷记全部在 USD 账本 transfers [ Transfer( id1001, debit_account_idA, # 128 位无符号整数账户 ID credit_account_idX, amount10_000, # 以最小货币单位计例如“分” ledgerUSD, codeTRANSFER_CODE, flagsTransferFlags.LINKED, ), Transfer( id1002, debit_account_idA, credit_account_idY, amount50, ledgerUSD, codeTRANSFER_CODE, flagsTransferFlags.LINKED, ), Transfer( id1003, # 链的终点不再带 LINKED 标志 debit_account_idA, credit_account_idZ, amount10, ledgerUSD, codeTRANSFER_CODE, ), ] results client.create_transfers(transfers) for result in results: # 遍历结果处理失败项链内失败的转账统一返回 LINKED_EVENT_FAILED if result.result ! 0xFFFFFFFF: # CreateTransferStatus.CREATED print(ftransfer {result.index} failed: {result.result})返回结果中0xFFFFFFFF表示created见 CreateTransferStatus 中的CREATED 0xFFFFFFFF其余为错误码。链中某笔失败时其余链内转账会返回LINKED_EVENT_FAILED值为1。小结业务诉求方案关键工具一借多贷 / 多借一贷单条链接链平铺flags.linked多借一贷、余额未知、按序凑单引入SETUP/LIMIT控制账户 平衡转账flags.balancing_debitflags.balancing_creditflags.linked多借多贷Control控制账户中转收入与分发两个阶段flags.linked 控制账户极致性能能直连的转账绕过控制账户应用层撮合优化核心要点回顾原子性来自链接链链尾必须由不带flags.linked的转账闭合余额未知时用 balancing 标志让数据库替你裁剪金额实际金额以账本记录为准控制账户是实现多对多与凑单约束的通用会计手法净余额恒为零若凑单金额不足链会因LIMIT账户的debits_must_not_exceed_credits约束而整体回滚exceeds_credits。这些模式同样适用于更复杂的业务例如在 货币兑换、余额条件转账、余额上界/下界 等 recipe 中链接链与平衡标志都是反复出现的核心构件。完整的 recipe 清单见 docs/coding/recipes/README.md。【免费下载链接】tigerbeetleThe financial transactions database designed for mission critical safety and performance.项目地址: https://gitcode.com/GitHub_Trending/ti/tigerbeetle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TigerBeetle 复合分录实战：用 Linked Transfers 与 Control Account 实现多借多贷转账
TigerBeetle 复合分录实战用 Linked Transfers 与 Control Account 实现多借多贷转账【免费下载链接】tigerbeetleThe financial transactions database designed for mission critical safety and performance.项目地址: https://gitcode.com/GitHub_Trending/ti/tigerbeetleTigerBeetle 的核心转账原语Transfer只支持单借单贷——一笔转账从一个账户借记、向另一个账户贷记这是其追求极致性能与精简设计的结果。但在真实业务中拆单、税费抽取、分账结算等场景天然需要一对多多对一多对多的复合分录。本文以仓库文档 docs/coding/recipes/multi-debit-credit-transfers.md 为骨架系统讲解如何利用flags.linked链接转账与控制账户Control Account把多个单借单贷转账组合成原子化的复合分录并深入到src/state_machine.zig验证balancing_debit/balancing_credit的底层实现。读完后你将能够用链接链实现一对多/多对一转账、用平衡标志在余额未知时能转多少转多少、以及用控制账户搭建多对多转账与限量凑单方案。为什么 TigerBeetle 只有单借单贷TigerBeetle 是为追求最大性能而设计的金融数据库。为了保持精简lean数据库只支持单一借记 单一贷记的简单转账一个Transfer字段中只有一个debit_account_id和一个credit_account_id参见 docs/reference/transfer.md。复合分录不是数据库内置原语而是由应用层组合多个 Transfer 实现的。但这并不意味着你需要放弃复杂的业务模型。TigerBeetle 提供的两个核心杠杆是链接事件Linked Events——用flags.linked把多条转账焊接成一条要么全成功、要么全失败的原子链平衡转账Balancing Transfers——用flags.balancing_debit/flags.balancing_credit在不知道账户余额的情况下自动转出尽可能多的金额。下面先讲基石再逐步展开一对多、多对多方案。基石Linked Transfers 如何保证原子性所有示例都依赖flags.linked来保证一组转账同生共死。其语义详见 docs/coding/linked-events.md 与 docs/reference/transfer.md#flagslinked设置flags.linked后本事件的成败与请求中下一条事件绑定链条的最后一笔转账不能带flags.linked——它标志链的结束。若最后一条仍带该标志会返回linked_event_chain_open错误链内事件按顺序执行任一失败则整条链回滚链内其他事件统一返回linked_event_failed首个失败事件返回其真实错误码完整错误码列表见 docs/reference/requests/create_transfers.md一个请求中可以存在多条相互独立的链链本身不会被持久化保存若需要在事后查询这些转账的关联关系应把关联 ID 写入user_data_128等字段见 docs/coding/data-modeling.md#user_data。各客户端语言中该标志都有对应枚举值。以 Python 客户端为例见 src/clients/python/src/tigerbeetle/bindings.pyTransferFlags是一个IntFlag标志值NONE0LINKED1 0PENDING1 1POST_PENDING_TRANSFER1 2VOID_PENDING_TRANSFER1 3BALANCING_DEBIT1 4BALANCING_CREDIT1 5CLOSING_DEBIT1 6CLOSING_CREDIT1 7IMPORTED1 8LINKED、BALANCING_DEBIT、BALANCING_CREDIT正是本文反复使用的三个标志。一对多转账One-to-Many Transfers多个借方 单个贷方或单个借方 多个贷方是一类相对直接relatively straightforward的场景只需把多条转账放进同一条链接链即可。单借多贷一个账户同时给多个账户打款场景从源账户A借记同时向X、Y、Z三个目的账户贷记全部在USD账本上。资金流如下LedgerDebit AccountCredit AccountAmountflags.linkedUSDAX10000trueUSDAY50trueUSDAZ10false注意最后一条A → Z的flags.linked为false它闭合整条链。三笔转账要么全部提交、要么全部回滚中间任何一笔失败例如A余额不足都不会造成部分成功。多借单贷多个账户共同向一个账户打款场景从A、B、C三个源账户借记统一贷记到目的账户XLedgerDebit AccountCredit AccountAmountflags.linkedUSDAX10000trueUSDBX50trueUSDCX10false多借单贷 余额调配Balancing Debits上面的多借单贷要求应用事先知道每笔金额。但真实场景往往是目标总额已知比如100而每个借方账户的余额未知——希望每个借方按优先级顺序尽量多贡献凑满目标总额。这就是Balancing Debits方案也是最有技巧性的一个。它引入两个控制账户三个源账户A、B、C均带flags.debits_must_not_exceed_credits即只允许支出不超过其贷方余额余额为 credit balance 且不允许为负概念见 docs/coding/data-modeling.md#credit-balances控制账户LIMIT同样带debits_must_not_exceed_credits充当配额上限控制账户SETUP用于支起setupLIMIT账户的额度本身不设任何余额限制。整条链共 6 笔转账| Id | Ledger | Debit Account | Credit Account | Amount | Flags | | -: | -----: | ------------: | -------------: | -----------: | :------------- | | 1 | USD |SETUP|LIMIT| 100 |linked| | 2 | USD |A|SETUP| 100 |linked,balancing_debit,balancing_credit| | 3 | USD |B|SETUP| 100 |linked,balancing_debit,balancing_credit| | 4 | USD |C|SETUP| 100 |linked,balancing_debit,balancing_credit| | 5 | USD |SETUP|X| 100 |linked| | 6 | USD |LIMIT|SETUP|AMOUNT_MAX|balancing_credit|机制拆解第 1 笔SETUP → LIMIT 100把LIMIT的贷方余额充值到 100为整个方案定义上限配额第 24 笔A/B/C → SETUP同时带balancing_debit借方尽量转与balancing_credit贷方按接收能力收。由于SETUP已在第 1 笔付出 100其可接收额度正好也是 100因此A、B、C按转账顺序依次填满这 100 的缺口余额足的账户贡献满额余额不足的账户贡献其全部后续账户自动收到 0 金额转账0.16.0起零金额转账是合法的见 docs/reference/requests/create_transfers.md第 5 笔SETUP → X 100把集中起来的资金一次性转给最终目的账户X第 6 笔LIMIT → SETUP AMOUNT_MAX仅balancing_credit不带linked是链的终点把LIMIT中仍保留的 100 转回SETUP使两个控制账户余额归零——LIMIT的AMOUNT_MAX在balancing_credit语义下就是最多转这么多实际金额受约束裁剪。失败语义原文明确指出的关键点如果A B C的累计 credit balance 小于100整条链会失败——第 6 笔转账将返回exceeds_credits。原因如下SETUP只收到了不足 100 的资金其第 6 笔的balancing_credit上限SETUP可接收量会超过 100而LIMIT带debits_must_not_exceed_credits约束无法在只有 100 贷方余额的情况下被借记超过 100于是触发exceeds_credits整条链接链回滚X 分文未收。这正是凑不满就不交易的原子保证。顺带一提balancing_debit/balancing_credit与closing_debit/closing_credit的组合还有另一个著名用例——关户清零参见 docs/coding/recipes/close-account.md。多对多转账Many-to-Many TransfersControl Account 模式当一笔分录同时有多个借方和多个贷方时事情要稍微复杂一些多对多。此时会计学中的**控制账户Control Account**概念就派上了用场把它作为中间过渡账户。以下例子使用的账户两个源账户A、BUSD账本三个目的账户X、Y、ZUSD账本一个复合分录控制账户ControlUSD账本。LedgerDebit AccountCredit AccountAmountflags.linkedUSDAControl10000trueUSDBControl50trueUSDControlX9000trueUSDControlY1000trueUSDControlZ50false思路是先用两条转账把A、B的钱收进Control再用三条转账从Control分发给X、Y、Z。Control账户在整个方案中的净余额恒为零——它只是资金的中转站。五条转账同属一条链接链任一步失败则整体回滚不会出现收了钱却没发出去的中间态。性能取舍何时可以绕过 Control Account细心的读者可能已经发现在上面的例子中B → Control50与Control → Z50金额恰好相等完全可以直连成B → Z。这正是原文档docs/coding/recipes/multi-debit-credit-transfers.md明确指出的优化空间为了追求更极致的性能你可以考虑实现一些逻辑在可能的情况下绕过控制账户从而减少实现一条复合分录所需的转账条数。由于 TigerBeetle 的吞吐与转账条数强相关减少无谓的中转转账能带来直接的性能收益。但文档也给出了务实的建议如果你刚开始接入完全可以避免过早优化——统一用控制账户来编程所有复合分录等业务跑通后再回来榨取这部分性能也不迟。底层原理balancing 标志在状态机中如何计算实际金额balancing_debit/balancing_credit的能转多少转多少究竟是怎么实现的答案在转账状态机的核心函数create_transfer中src/state_machine.zigfn create_transfer(附近的amount_actual计算约 L3841-L3853const amount_actual amount: { var amount t.amount; if (t.flags.balancing_debit) { const dr_balance dr_account.debits_posted dr_account.debits_pending; amount min(amount, dr_account.credits_posted -| dr_balance); } if (t.flags.balancing_credit) { const cr_balance cr_account.credits_posted cr_account.credits_pending; amount min(amount, cr_account.debits_posted -| cr_balance); } break :amount amount; };结合 docs/reference/transfer.md#flagsbalancing_debit 与 docs/reference/transfer.md#flagsbalancing_credit 的文档语义可归纳为balancing_debit请求金额是上限实际转账金额被借方账户约束裁剪——保证debit_account.debits_pending debit_account.debits_posted ≤ debit_account.credits_posted即借方不会转出超过其贷方余额的资金对 credit-balance 账户即余额不为负balancing_credit同理实际金额被贷方账户约束裁剪——保证credit_account.credits_pending credit_account.credits_posted ≤ credit_account.debits_posted即贷方不会收到超过其已付出总额的资金。两个标志正交兼容可以同时设置如前面A → SETUP的转账最终金额取两方约束的较小值。记录到账本上的amount是裁剪后的实际转账金额这一点对幂等重试语义有重要影响重试一笔 balancing 转账时只有当重试请求中的最大金额不足以覆盖已实际转账的金额时才会返回exists_with_different_amount否则即使金额不同也会返回exists详见 docs/reference/requests/create_transfers.md#exists_with_different_amount。这保证了你可以在崩溃恢复后安全地重放请求而不会造成重复扣款。可运行的 Python 示例下面用官方 Python 客户端src/clients/python/src/tigerbeetle/bindings.py把单借多贷写成可运行的代码。实际生产环境建议用 TigerBeetle Time-Based Identifier 生成id并在ledger、code等字段上遵守你的账本规划见 docs/coding/data-modeling.md#ledgersfrom tigerbeetle import Client, Transfer, TransferFlags client Client(cluster_id0, replica_addresses[3000]) # 账户 A 借记X / Y / Z 贷记全部在 USD 账本 transfers [ Transfer( id1001, debit_account_idA, # 128 位无符号整数账户 ID credit_account_idX, amount10_000, # 以最小货币单位计例如“分” ledgerUSD, codeTRANSFER_CODE, flagsTransferFlags.LINKED, ), Transfer( id1002, debit_account_idA, credit_account_idY, amount50, ledgerUSD, codeTRANSFER_CODE, flagsTransferFlags.LINKED, ), Transfer( id1003, # 链的终点不再带 LINKED 标志 debit_account_idA, credit_account_idZ, amount10, ledgerUSD, codeTRANSFER_CODE, ), ] results client.create_transfers(transfers) for result in results: # 遍历结果处理失败项链内失败的转账统一返回 LINKED_EVENT_FAILED if result.result ! 0xFFFFFFFF: # CreateTransferStatus.CREATED print(ftransfer {result.index} failed: {result.result})返回结果中0xFFFFFFFF表示created见 CreateTransferStatus 中的CREATED 0xFFFFFFFF其余为错误码。链中某笔失败时其余链内转账会返回LINKED_EVENT_FAILED值为1。小结业务诉求方案关键工具一借多贷 / 多借一贷单条链接链平铺flags.linked多借一贷、余额未知、按序凑单引入SETUP/LIMIT控制账户 平衡转账flags.balancing_debitflags.balancing_creditflags.linked多借多贷Control控制账户中转收入与分发两个阶段flags.linked 控制账户极致性能能直连的转账绕过控制账户应用层撮合优化核心要点回顾原子性来自链接链链尾必须由不带flags.linked的转账闭合余额未知时用 balancing 标志让数据库替你裁剪金额实际金额以账本记录为准控制账户是实现多对多与凑单约束的通用会计手法净余额恒为零若凑单金额不足链会因LIMIT账户的debits_must_not_exceed_credits约束而整体回滚exceeds_credits。这些模式同样适用于更复杂的业务例如在 货币兑换、余额条件转账、余额上界/下界 等 recipe 中链接链与平衡标志都是反复出现的核心构件。完整的 recipe 清单见 docs/coding/recipes/README.md。【免费下载链接】tigerbeetleThe financial transactions database designed for mission critical safety and performance.项目地址: https://gitcode.com/GitHub_Trending/ti/tigerbeetle创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考