有篇讲TigerBeetle架构的科普文,把这套用Zig写的金融账本数据库夸成"数十万TPS+亚毫秒级尾延迟"。翻到官网头条,写的却是100毫秒 P100延迟,还特别注明是90%争用场景下测出来的。一个说亚毫秒,一个说100毫秒,中间差了近三个数量级——这不是笔误,是把内部工程基准和对外承诺的数字混成了一锅粥。
TigerBeetle不是通用数据库,它专门干一件事:处理debit/credit记账,直接在数据库里跑状态机,省掉应用层来回打的网络请求。它的性能故事确实有真东西,但真东西和头条数字,不是一回事。
先把数字摆平
官网公开的头条数字是100K–500K TPS,配100ms P100延迟,前提是90%争用场景。这是对外承诺,也是客户做容量规划时该拿来算账的数字。
2026年6月的内部通讯披露过另一组数字:Grid所有权机制改造后,内部基准从69.7万TPS提到71.2万TPS。这组数字比头条上限还高40%以上,但官方特意提醒——硬件配置、副本拓扑、数据集大小、批量大小、争用程度、持久化设置,任何一项不对齐,这个数字都不该拿来和头条对比。
- 提醒.712K是内部开发基准,不是可复现的生产SLA,拿它去套用户场景是刻舟求剑。
静态分配和批处理,才是真本事
TigerBeetle真正值得学的,是启动后就冻结内存分配器这个决定。进程启动时算好这辈子要用的全部内存——网络缓冲、存储缓存、事务日志、共识状态机全在里面,之后再不malloc。堆碎片这件事,从物理上被排除了。
配合这套静态内存的,是激进的批处理:每次查询能打包处理约8190笔转账。共识层复制这个批次,提交后交给单线程执行循环一次性处理完,再一次性顺序写盘。原本是成千上万次零散的小I/O,被压成一次连续写入,这才是把NVMe和网卡的物理带宽榨出来的关键。
单线程听起来像瓶颈,实际上把线程切换、锁竞争、缓存失效这些开销全部清零了。但"单线程"只是执行状态机这一层——复制、磁盘预取、网络收发、LSM压缩,这些I/O环节是并发流水线跑的。增加副本数提升的是可用性,不是写吞吐,这一点容易被读成"分布式=线性扩容"的老误会。
2026年的两次真改进,和一个被误读的词
今年有两处工程进展是实打实的:一次事件循环重构,带来约8%的吞吐提升;5月把最终LSM合并方式换成增量式按需压缩,观测到的尾延迟峰值最多降低3倍。这两项改的都是尾部,不是均值——对金融清算系统来说,尾部才是决定SLA能不能签的地方。
"零拷贝"这个词也被官方自己纠正过。原文把它当成绝对特性讲,但官方文档说得更准确:这其实是"拷贝规避+快速路径",只有当一次网络接收恰好构成一条完整消息时,才会走无拷贝通道。真实网络里分片、粘包很常见,这条快速路径的命中率有多高,官方没给数字,读者也别自己脑补一个。
内部基准是战绩,头条数字才是承诺。
刚性代价没有消失
静态分配换来了可预测性,代价是刚性:最大连接数、最大批量、最大缓存都得在启动时定死。超出这个上限,系统不会悄悄扩容,而是直接背压或拒绝请求。对追求弹性伸缩的团队,这道边界必须提前算进容量规划,不是上线后再踩坑。
- 结论.六副本灵活quorum(3个用于复制、4个用于选举)是另一种权衡——比传统3/5副本方案在故障容忍上更细,但也意味着运维要理解两套quorum数字,而不是一套。
官方还披露过一次处理一万亿笔交易的耐久性测试,验证的是长期生存能力,不是吞吐——这类测试和TPS基准是两个维度,混着引用同样会误导人。
该怎么看这类基准
一套架构讲得再漂亮,数字口径不统一,判断就会跑偏。评估这类系统时,先问三件事:这个数字是内部基准还是对外SLA,测试条件和自己的场景差多远,尾延迟数字对应的是均值还是p99.99。TigerBeetle这套静态分配加单线程的思路,在贴近硬件这件事上确实做对了方向,但方向对不代表每个数字都能直接拿来用。下一步该盯的,是这套712K基准会不会正式成为新头条,以及增量压缩的3倍尾延迟改善能不能在生产环境里稳定复现。