celld用 S3 替代共识协议的自托管 Durable Objects 运行时一句话定位celld 是 Deno 团队开源的 Rust 守护进程让你在自己的服务器上运行 Cloudflare Workers Durable Objects 代码用 S3 存储桶充当唯一协调者彻底绕开 Raft/Paxos 等共识协议。核心观点Durable ObjectsDO是 Cloudflare 提出的一种编程模型每个对象Object是一个具备持久状态的微型计算单元对外提供强一致性访问同时天然地把应用按实体分片。这个模型本质上非常优雅——它把分布式系统的难题封装在对象边界内让开发者只需写单线程逻辑。celld 做的事情是把这个优秀的模型从 Cloudflare 的专有平台搬到你自己的机器上同时以一种罕见的工程决策——用 S3 的原子操作替代传统共识协议——实现节点间的分布式协调。机制巧在哪里多数分布式系统要解决哪个节点拥有某份数据的写权这一问题通常需要引入 Raft、Paxos 或 etcd 这类共识层代价是运维复杂度和延迟。celld 的关键创新是将所有权记录写入 S3利用 S3 的 Compare-and-SwapCAS原子操作来保证任意时刻只有一个节点拥有某个 Cell。步骤如下每个 CellDO 实例的 SQLite 数据库持续被 LTXLitestream 的副本格式增量流写入 S3节点通过向 S3 写入一条租约记录来宣告对某 Cell 的所有权CAS 保证原子性Cell 迁移或节点重启时新节点从 S3 拉取最新的 SQLite 快照恢复执行不存在主节点或调度服务——所有节点地位对等均通过扫描同一个 S3 存储桶发现彼此和 Cell 的归属。这是一种以高可用 S3换掉复杂共识协议的工程置换。代价是引入了 ~90ms 的持久写入延迟S3 RTT以及 ~20s 的故障转移窗口等待租约过期。历史脉络与对比维度Cloudflare Durable ObjectsCloudflare Workerdcelld是否自托管否托管是单节点运行时是完整分布式系统协调层Cloudflare 内部基础设施无单机S3 CAS状态持久化平台托管无用户自有 S3调度能力有无有代码兼容性原生高高Wrangler bundle100 单元月成本~$415接近 $0但无 HA~$49Workerd 是 Cloudflare 开源的 Workers 运行时但它只是引擎没有解决 Cell 调度、迁移和故障转移这些分布式系统层面的问题。celld 填上了 Workerd 缺失的这层。这是一次真正有意义的补全而不只是换壳重包。交叉验证信源 1CSDN / 开发者分析文章作者youxijun来源独立于原项目确认了 celld 的以下技术事实并补充了关键的社区反馈Cloudflare Workers CTOkentonvKenton Varda本人出现在讨论中承认 Cloudflare 内部有类似项目但被搁置并对 celld 先行表示肯定。这是对原文Durable Objects 是强编程模型这一定性的有力背书——Cloudflare 内部人士并未反驳这种移植思路。社区对S3 本身是不是控制平面提出质疑项目方的回应是S3 比典型的分布式协调工具更易得且更可靠。这是合理的实用主义立场但也侧面承认了对 S3 可用性的依赖。关于Pull Request 关闭、改用邮件 patch这一贡献机制社区争议明显有人认为这是复古倒退但也有人理解为维护者防止 AI 生成的低质量 PR 刷屏——原文 README 的原话是Coding agents make it too easy to send a large, low-context change可见这是刻意的工程文化选择。信源 2celld.dev 官方文档独立于 GitHub README 的信息提供了量化数据作为补充验证无状态请求 p50 延迟0.2ms吞吐量94k req/s每工作线程唤醒休眠 Cell~4msRPO0已确认写入零丢失100 个驻留单元月成本约$49对应 Cloudflare DO 的 $415明确了定位是单区域内运行大量 worker不是全球分布式的 Cloudflare 网络替代品。这两个信源共同支持了原文的核心主张但也澄清了一个容易被误读的边界celld 不是 Cloudflare 全球边缘网络的自托管替代而是其编程模型在单区域私有基础设施上的移植。边界与局限——不能唱赞歌的地方对 S3 的单点依赖S3 桶既是数据存储层也是协调层。一旦桶不可用整个 fleet 停止协调虽然存量 Cell 可以继续服务但无法迁移或恢复。这把分布式系统的最终真相集中到了一个外部服务上看似简洁实则将可用性风险转移到了 S3 SLA。故障转移窗口达 20s这对需要亚秒级 HA 的系统是硬伤。Cloudflare 自己的 DO 故障转移比这快得多。单区域定位限制了场景Cloudflare DO 的一个核心价值是就近执行celld 明确不提供这个能力。如果你的用户全球分布celld 无法替代 Cloudflare。小规模时不划算官方数据显示100 个活跃 Cell 时自托管基础设施成本高于直接使用 Cloudflare DO。这是一个明确的规模门槛。运行时兼容性仍在演进README 明确写了runtime and compatibility surface are still evolving意味着并非所有 Workers API 都已支持现有代码迁移前需要验证兼容性。Peer HTTP 不终止 TLS节点间通信依赖部署者自行搭建 WireGuard/Tailscale 等加密网络对运维要求不低。个人启发对开发者如果你正在用 Cloudflare DO 且月账单已超过 $200这是一个值得认真评估的迁移路径。迁移成本主要在运维你需要能管理 Docker S3 的人代码本身理论上无需改动。但迁前务必跑一遍兼容性测试因为运行时仍在演进。对架构师用 S3 CAS 替代共识协议这个设计思路本身值得借鉴。S3 已经是大多数工程团队的基础设施它的原子性通常被低估。在不需要毫秒级协调的场景比如 Cell 所有权这类秒级变更的事件用 S3 做协调层是一种极简而务实的选择。对决策者celld 目前是 v0.x 阶段README 明确建议阅读 limitations 和 security 文档再上生产。这不是一个明天就能替换 Cloudflare的方案而是一个可以跟踪的方向——Cloudflare CTO 的背书意味着这条路在技术上是被验证过的只是工程成熟度需要时间积累。延伸思考S3 作为协调层的边界在哪里S3 的 CAS 语义在高频写入场景如每秒数千次所有权变更下会不会成为瓶颈celld 的适用场景是Cell 移动频率较低的情况但如果工作负载导致 Cell 频繁迁移这个架构的性能上限在哪里目前文档尚无压测数据。Deno 为何做这件事celld 是 Deno Land Inc. 的开源项目但这并不是 Deno 运行时本身的延伸celld 用 V8 执行代码而非 Deno 引擎。这背后是否有商业意图——比如提供 celld 的托管版本与 Cloudflare 形成竞争Ryan Dahl 的邮件地址直接出现在贡献者协议里这个项目的商业走向值得持续观察。无 PR、改用邮件 patch这种贡献模式能持续多久这在 Linux 内核开发中运行良好但前提是有足够规模的邮件列表社区。对于一个新兴项目这种门槛可能会显著降低外部贡献的数量和速度——而 celld 的运行时兼容性还有大量工作要做。如果贡献者流失它能否持续追上 Cloudflare Workers 的 API 演进 参考来源GitHub - denoland/celld: self-hosted, distributed Durable Objects · GitHub