在分布式数据库领域，万亿级事务处理并非单纯考验吞吐量数字，而是对系统生存能力的终极检验。TigerBeetle 作为专为金融交易设计的分布式 OLTP 数据库，通过严格串行化、对角线扩展与 LSM 树存储引擎的协同组合，成功验证了万亿级事务场景下的可恢复性与性能边界。本文将从一致性模型、存储引擎、共识协议与 IO 路径四个维度，解析其架构设计决策，并给出可落地的工程参数。
一、为什么万亿级事务的核心挑战是生存而非性能
当单库数据量逼近 128 TiB 时，许多云数据库标榜的「无限扩展」承诺便显露出物理极限。以 100 Gbps 网卡、完美传输为前提，重建一台 128 TiB 的故障机器需要约 2.9 小时；若叠加索引重构开销，平均故障恢复时间（MTTR）可攀升至 6 小时。一旦 MTTR 超过平均故障间隔时间（MTBF），系统便陷入死亡螺旋：恢复速度跟不上故障速度，集群规模越大反而越脆弱。
TigerBeetle 对此的回应是重新定义扩展性 —— 扩展的本质不是能跑多快，而是能否在极端条件下存活。为此，团队将可恢复性作为架构设计的核心约束，而非事后考虑的容灾方案。这一理念直接体现在其对角线扩展模型中：热数据垂直扩展以获得微秒级延迟，冷数据水平扩展以实现无限容量，二者的分界点通过有界状态的复制状态机严格控制。
二、严格串行化：不做一致性权衡的代价与收益
TigerBeetle 明确选择了严格串行化（Strict Serializability）作为事务隔离级别，这一决策背后是对金融级正确性的坚守。在严格串行化下，事务的执行结果等同于某种全序串行执行的结果 —— 不仅满足可串行化，还保证了时间顺序与实际提交顺序的一致性。这意味着任何跨账户的转账操作都能被精确排序，不存在因果颠倒的风险。
业界存在一种常见做法：通过放宽隔离级别换取性能提升。但 TigerBeetle 团队引用了一句广为流传的说法：「那些为了一点安全性而牺牲性能的人，既不配拥有安全性，也不配拥有性能。」在金融交易场景中，正确性是底线而非可调参数。一旦出现余额错误或双花问题，修复成本远超性能优化的收益。
实现严格串行化的代价是所有写事务必须经过全局排序。TigerBeetle 通过 Viewstamped Replication（VSR）共识协议解决这一问题，该协议由 MIT 于 1988 年提出，比 Paxos 早一年，却同样提供了无 durability 丢失的故障切换能力。VSR 能在毫秒级完成主节点切换，且切换期间不丧失一致性 —— 这对于需要 24/7 运行的高频交易系统至关重要。
三、对角线扩展：垂直热数据与水平冷数据的分层策略
对角线扩展（Diagonal Scaling）是 TigerBeetle 万亿级架构的核心创新。其核心思想是将计算扩展与存储扩展解耦：对热数据采用垂直扩展（更大、更快的机器），对冷数据采用水平扩展（无限容量的对象存储）。
具体实现上，TigerBeetle 将复制状态机（RSM）的有界状态限制在 16 TiB 以内。这个数字并非随意设定，而是经过 MTTR 推导得出的安全阈值：16 TiB 在 100 Gbps 网络下约需 21 分钟完成重建，加上索引构建与校验，开销仍控制在可接受范围内。一旦 RSM 超过这一规模，系统会主动将冷数据下沉至对象存储（兼容 S3 协议的任何存储后端），上层只保留热数据的 working set。
这一策略与传统的分片形成鲜明对比。传统分片将数据打散到多台机器，表面上实现了水平扩展，却破坏了 OLTP workloads 最为依赖的缓存局部性。TigerBeetle 团队曾进行过一次昂贵的实验：构建一个水平扩展的集群，年成本高达百万美元（约等于一辆 McLaren 超级跑车的价格），结果发现只要存在 10% 甚至 1% 的键竞争，吞吐量反而不如单节点开源 PostgreSQL。这验证了 Amdahl 定律在事务处理领域的残酷有效性 —— 串行化部分永远是瓶颈，分片无法绕过这一物理约束。
对角线扩展的另一个关键优势在于恢复时间的解耦。传统架构下，总存储量直接决定了恢复时间；而在 TigerBeetle 中，恢复时间只取决于 RSM 的大小（16 TiB），与历史数据总量（可轻松突破 PB 级）无关。LSM 树的多级结构天然适配这一分层：L0/L1 保留在内存或 NVMe 中提供低延迟访问，L2 及以下层级可以卸载到对象存储，按需回填。
四、LSM 树存储引擎与 IO 路径优化
TigerBeetle 的存储引擎采用 LSM 树（Log-Structured Merge-tree）森林结构，显著区别于传统 OLTP 数据库的 B-tree 变体。LSM 树的写入放大（write amplification）特性虽然存在，但对于写密集型的金融交易场景（Debit/Credit 操作占主导），其顺序写入优势远大于随机写入的劣势。更重要的是，LSM 树的多级结构天然支持分层存储：热点账户数据驻留在内存和 NVMe 层，冷历史数据下沉至对象存储，检索时通过后台回填机制按需加载。
在 IO 路径上，TigerBeetle 采用了批量提交（batch commit）策略。单个事务的网络往返和共识开销极高，但将数千个转账操作打包为一个批次提交，能将每事务的固定开销分摊到极致。根据公开的测试数据，TigerBeetle 在典型配置下可达到数十万至近百万事务每秒的吞吐量，且延迟稳定在低毫秒级（per-batch）。这种高吞吐 + 可预测延迟的组合，正是高频支付场景的刚需。
批处理还带来了另一个工程收益：服务端可更高效地利用 CPU 缓存和 SIMD 指令集。TigerBeetle 用 Zig 语言编写，代码层面高度针对现代 CPU 特性优化，避免了 GC 带来的尾延迟抖动。对于延迟敏感型工作负载，这一取舍远比通用的 PostgreSQL/MySQL 更有优势。
五、工程落地：关键参数与监控指标
基于上述架构设计，以下是生产环境部署时建议关注的关键参数与监控维度：
复制状态机容量上限：通过配置将 RSM 有界状态控制在 16 TiB 以内，具体数值需根据单机 NVMe 容量与故障恢复 SLA 倒推。建议开启自动下沉策略，当使用量超过阈值时触发向对象存储的旧数据迁移。
批次大小（Batch Size）：默认建议 1024 至 4096 事务 / 批次，具体数值需通过负载测试确定。过小的批次会浪费网络 RTT 过半开销，过大的批次则增加单次提交延迟并可能触发超时。
对象存储连接池：确保与 S3 兼容存储之间的连接复用，避免频繁建连带来的延迟抖动。建议配置至少 32 个并发连接，带宽匹配本地 NVMe 吞吐量（通常为 10-40 Gbps 级别）。
监控指标：
- p99 提交延迟：批次粒度，不超过 10 毫秒（本地 NVMe 场景）
- 复制状态机使用率：超过 80% 时触发告警，准备数据下沉
- 故障恢复进度：记录每次主从切换的实际恢复时长，与 MTTR 目标对比
- 对象存储回填队列深度：过深意味着冷数据访问延迟上升，需扩容或优化回填策略
容量规划：每个账户对象约 128 字节，一万亿账户约 128 TiB 原始存储。考虑 LSM 树放大系数（通常 1.5-2x）和三副本复制，总物理存储需求约 500-700 TiB。通过对角线扩展，热数据层（RSM）仅需保留最近 16 TiB，冷数据层通过对象存储无限扩展。
六、总结
TigerBeetle 的万亿级事务架构提供了一份教科书级别的工程示范：在严格串行化的安全前提下，通过 VSR 共识协议保证一致性，通过对角线扩展解耦计算与存储的扩展路径，通过有界状态的复制状态机将 MTTR 控制在可接受范围内，最终实现了「可恢复的扩展」。对于需要处理海量金融交易、同时对正确性和可用性有严苛要求的团队，TigerBeetle 的设计理念值得深入借鉴 —— 尤其是将对角线扩展思路引入现有存储架构时，关键在于明确热数据的边界并建立自动下沉机制。
参考资料
- TigerBeetle 官方博客：A Trillion Transactions（2026 年 3 月）
- TigerBeetle GitHub：ARCHITECTURE.md