Deno 用 S3 和 SQLite 复刻 Durable Objects：没有共识服务也能只有一个主人吗
作者：林岚｜OC 开发者生态编辑
林岚
Deno 开源了 celld，让开发者在自己的机器上运行 Cloudflare Workers 风格的 Durable Objects。每个对象对应一个独立 SQLite 数据库，状态复制到用户控制的 S3 兼容存储桶，节点只通过这个桶协调，不需要单独的控制平面或共识服务。
一句话结论：celld 没有消除分布式一致性，而是把“谁拥有对象”的原子裁决交给对象存储的 compare-and-swap；架构因此更简单，但存储桶可用性、CAS 语义和凭据安全就成了整个系统的新可信根。
每个节点内嵌 V8，直接执行 Wrangler bundle。部署版本、SQLite 状态和少量所有权记录都保存在共享存储桶中。节点通过条件写入竞争某个 cell，设计目标是任一时刻只有一个节点持有它；节点故障后，新所有者从存储桶恢复数据库继续执行。
这种设计没有成员列表、故障检测器或 Raft 集群，扩容只需启动能访问同一桶的新节点。空闲 cell 可以休眠，受内存或 CPU 压力时，节点会先持久化并释放最久未使用的对象，后续请求再由其他节点接管。
代价是对象存储进入每一条关键路径。S3 的条件请求必须满足 celld 所依赖的原子语义；网络分区、租约过期和恢复期间的写入顺序，都要防止两个节点同时认为自己是主人。项目表示，首个正式版本推出之前会运行分布式协议的确定性故障模拟，但当前兼容面仍在变化。
安全边界也很清楚。节点之间的 HTTP 不负责 TLS，官方要求把 peer 地址放在私有网络或 WireGuard、Tailscale 中。请求使用共享 HMAC 密钥做版本、正文、时钟和重放校验；任何能访问存储桶及其凭据的人，都应被视为整个 fleet 的管理员。
celld 还做了一个维护选择：GitHub Pull Request 被关闭，因为 Agent 生成的大量低上下文改动会提高审查成本。贡献者需要理解代码后用邮件提交 git format-patch。这个细节与架构一样务实，开源入口存在，不等于维护者必须接受最低摩擦的提交方式。
关键事实
- 每个 Durable Object 对应一个 SQLite 数据库，并复制到 S3 兼容存储
- 对象存储 compare-and-swap 用于保证单个 cell 同时只有一个所有者
- 节点无中心控制平面，可休眠和在压力下释放空闲 cell
- peer HTTP 需要部署在可信私网，存储桶凭据等同于集群管理员权限
OC 判断
celld 是用强对象存储原语换掉专用共识集群，不是“无共识的魔法”。它适合大量彼此隔离、单对象写入的应用；跨对象事务、严格低延迟恢复和存储桶不可用时的行为，仍需要业务自己评估。
为什么重要
- 对开发者：可以自托管 Durable Objects 编程模型，但 Wrangler 兼容面还不是完整替代。
- 对运维团队：S3 配置、凭据和条件写入语义成为关键基础设施，必须按数据库标准管理。
- 对开源维护者：限制 AI 低质量 PR 是审查容量管理，不是关闭代码开放性。
评论
围绕这篇文章补充信息、提出问题或分享观察。