加载失败
讨论围绕用 TigerBeetle 构建高性能票务系统展开，原帖展示了一个以 TigerBeetle 为后端的高吞吐实现并引发对其在真实售票场景适用性的质疑。评论者从票务业务复杂性（座位保留、黄牛机器人、连续座位算法）、TigerBeetle 的批量优越性与逐笔性能下降、以及元数据与 ID 设计限制等角度讨论了能否替代 PostgreSQL 的可行性。还涉及客户端行为（是否自动批处理）、语言生态（如 Go、Ruby、Python/FastAPI）与持久性/一致性验证（如 Jepsen 报告）等工程考量。结论倾向于：看重批量传输的场景 TigerBeetle 很强，但用于实时逐笔售票前需评估业务模型与额外工程成本。
真实售票远比实验室基准复杂：大量座位不是立即购买而是被放入“篮子”（reserved）后又回流库存，很多由职业黄牛或业余转售者运行的机器人会占位并释放库存，且评论者提到 Cloudflare 等防护并不能完全阻挡这些机器人，有时机器人甚至基于 Cloudflare Workers 实现。对于有保留座位的演出，查找连续座位需要复杂的串行算法，难以并行化，这会增加额外的数据库调用和竞争。“Sold Out”标签常由主办方决定，实务上仍会长期留下零散单座，所以实验室的峰值并不能直接等同为实际成交率或最终售罄速度。
实测显示 TigerBeetle 在批量写入时能达到极高吞吐：评论中给出的测试值约为 250,000 writes/sec；但逐笔、实时单条写入则显著变慢，测试中约为 105 writes/sec。对比实验中 PostgreSQL 单行更新约 5,495 writes/sec，这说明在不做聚合的实时路径上 TigerBeetle 可能并不占优。评论建议通过 microbatching（例如每秒聚合）来保持高吞吐，但这要求在应用层实现额外的缓冲与调度逻辑，不能仅靠库默认行为。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
把 TigerBeetle 作为 PostgreSQL 的即插即用替代会遇到功能与工程上的限制：TigerBeetle 使用自定义主键而非 UUIDv7/ULID，这影响 ID 设计；单笔交易可保存的元数据有限（如 user_data_128 为 128-bit unsigned），实际应用常需在外部数据库再包装事务属性。评论中还提到客户端生态与语言支持的差异（早期 Ruby 支持薄弱），以及测试时若为每笔交易错误地新建客户端会严重拉低性能，因此迁移前需评估客户端库、语言绑定与实现微批处理的工程成本。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
多名评论者提醒基准测试容易误导：实验室里能测出高并发写入并不代表在售票高并发且伴随大量保留/释放的场景中能转化为高成交率。数据库之间的对比也受环境与调优影响：SQLite 是进程内数据库，在理想单机场景插入速度很高但并发写受限（需依赖 WAL 配置），而 Python/FastAPI 在高性能场景也被部分评论者质疑。因此需要把语言、运行时、并发模型与应用层业务规则一起纳入评估，而不是单看峰值写入数字。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
评论中有人提醒要关注一致性与故障情况下的耐久性，并附上 Jepsen（分布式系统一致性测试/分析项目）对 TigerBeetle 的报告作为参考核查点。对 LiveBatcher 之类将事务聚合到未持久化缓冲区的机制有人提出疑问：是否存在在异常停机时丢失“位置”或未提交批次的风险。发帖者补充称正常请求不会返回直到其 transfer 被标为 pending 并发送到 TigerBeetle，但总体建议是对关键账本路径做严格的容错、一致性与恢复测试，而非仅看吞吐基准。
TigerBeetle: TigerBeetle（一个面向高吞吐金融/账本交易的专用数据库），设计目标是极快的批量事务处理与账本一致性，适合批量文件或大规模对账场景。
batching / microbatching: batching / microbatching（把多个实时事务在短时间窗口内聚合为一批再写入），用于把单笔延迟问题转换为高吞吐批处理以发挥底层系统的缓冲优势，评论中提到每秒级聚合为常见做法。
WAL (Write-Ahead Logging): WAL（Write-Ahead Logging，SQLite 的写入日志模式），通过预写日志改善读写并发，但写操作仍受锁与并发限制，需要谨慎配置以平衡吞吐与并发。
Jepsen: Jepsen（一个用于评估分布式系统一致性与故障恢复的测试与分析项目），常被用来验证数据库或分布式协议在网络分区、崩溃等故障下的正确性与耐久性。
PostgreSQL: PostgreSQL（广泛使用的关系型数据库），支持丰富的事务与元数据存储，评论中被用作对比基准且在某些逐笔更新场景表现更稳定。
SQLite: SQLite（嵌入式、进程内的轻量级关系数据库），在单进程场景下插入速度非常高，但并发写入受限，需要通过 WAL 等机制才能改善并发性能。