Tigrisdata

Tigris，全球分布的 S3 兼容对象存储，零出站流量费，无限扩展，无缝跨云工作。

我们曾用一个数据库当消息队列，现在我们用 Kafka

Tigris Data 团队原本把 FoundationDB 当作消息队列使用，参照苹果 CloudKit 的 QuiCK 论文实现了持久化队列，避免双写问题，但后来为降低 FDB 读写压力、减少自研代码和维护成本，将部分异步任务（如垃圾回收）迁到 Kafka。 文章详细拆解了 QuiCK 的核心机制：以时间戳作为任务身份（vesting time + taskType + itemSpace + priority + id），worker 通过把任务 key 推到未来来"租约"任务，崩溃后任务自动回落被其他 worker 领取；他们还加了分片（按 key 哈希分 lane）来降低随机竞争、长任务 checkpoint、自调度的 cron 等改造。 痛点包括：随机抢占导致"倒霉任务"长期不被领取、大规模积压时写压力过大、需要保证 NTP/GPS 时钟同步。文风带个人吐槽（Kafka 运维痛苦），对想少维护一套队列系统或理解 FDB 当队列用的工程读者有较高信息密度和讨论价值。
评论点赞收藏3 小时前

重新设计 packfile 后，Git 可以跑在对象存储上

Tigris 团队开源了一个用对象存储承载 Git 的 Git server（objgit）。作者先试了“把 Git 当文件系统接在对象存储上”的方案，但真实规模仓库性能不行，瓶颈主要来自 Git packfile 和自研 filesystem shim 的交互。 于是作者重新设计了一套对象存储原生的 packfile 格式：借鉴 CD 的.bin +.cue 结构，把对象顺序写入 objects.bin，用固定宽度的 objects.cue 存 hash、压缩/未压缩大小、bin 偏移等元数据，从而可以直接用 HTTP Range 请求取单个对象，同时后台把整个 packfile 拉到本地临时目录降低延迟。 文中还解释了为什么 Linux 内核这类大仓库必须用 packfile（单个对象文件会爆 inode），以及 Git 原本 mmap 本地 packfile 的设计为何不适合对象存储。 整体是偏工程实现细节的一手经验，适合 Git 内部机制、分布式存储和系统设计方向的读者。
评论点赞收藏14 天前

Presigned URL 本质上是一次你亲手制造的重放攻击

Tigris 发文指出 presigned URL 本质是有意为之的重放攻击，SigV4 用时钟代替 nonce 解决重放问题，签名有效期约 15 分钟。URL 一旦泄露无法单独撤销，只能销毁整个 access key；有效期最长一周，可重复调用。 文章认为这种"会自毁的链接"是对象存储访问控制的合理权衡，而非安全漏洞。
评论点赞收藏60 天前

登录芦苇

登录后关注作者、收藏内容和参与讨论。

热门话题

人工智能12,865 人关注AI 会怎样改变日常工作？产品思考8,243 人关注怎样判断一个产品值得长期做？独立开发5,917 人关注一个人如何持续完成作品？
关于芦苇 · 联系我们 · © 2026 芦苇