celld 死节点对账与 GC过期租约如何被自动清理与修复【免费下载链接】celldself-hosted, distributed Durable Objects项目地址: https://gitcode.com/GitHub_Trending/ce/celldcelld 是一款自托管的分布式 Durable Objects 运行时多个节点通过共享的对象存储桶协同工作。当某个节点宕机或失联后它在桶中留下的节点租约记录会过期如果一直堆积就会污染集群的容量与放置决策。celld 内置了一套死节点对账与 GC 机制由被选举出的 waker 节点周期性地把这些过期租约清理掉让桶始终反映真实存活的集群。 先理解背景celld 里的租约是什么celld 的设计哲学是桶是唯一的持久事实源节点可随时替换见 README.md。为了实现这一点每个节点定期在桶的nodes/前缀下写入一份自己的租约记录nodes/节点名.json里面带有expires_ms过期时间——相当于我承诺在这个时间点之前还会续租。节点之间互相发现、做放置决策时会列出nodes/下的记录只看租约未过期的节点过滤逻辑在 crates/celld/ownership_store.rs。如果节点崩溃后没有再续租它留下的记录就会变成死记录——不删掉它集群就永远以为这台机器还活着。死节点 GC 要做的就是把这些过期租约识别出来、并安全地修复桶中的状态。核心代码在 crates/celld/dead_node_gc.rs。 谁负责清理全集群选举出的 waker 角色清理不能每个节点都做否则会互相打架。celld 的做法是每个节点在每个 tick默认 60 秒由CELLD_WAKER_TICK_MS控制都尝试去持有桶里wake/waker.json这把建议性的 waker 租约抢到的那一个才执行本轮 GC。抢租约用的是对象存储的 compare-and-swapCAS条件写天然保证同一时刻只有一个持有者实现见 crates/celld/wake.rs 中的try_hold_waker。持有者每 TTL/3 的时间续租一次续租失败就立刻取消本轮 GC避免两个清理者长时间并存。这个租约是建议性的即使某个持有者中途崩溃正确性也不会受损——最坏情况只是多花一轮 tick 由别人接手。该循环与到期唤醒扫描共用同一个定时任务入口在 crates/celld/main.rs。 对账三步走如何判定一个节点死了每一轮run_passcrates/celld/dead_node_gc.rs只做三件事判定规则刻意写得极其保守列出nodes/前缀下的全部租约记录读回每条记录校验文件名里的节点名与记录体内的节点名完全一致只有当expires_ms 当前时间时才判定为死节点纯函数判定见 crates/logic/dead_node_reconciliation.rs 的node_record_is_dead。注意两点设计不信时钟之外的任何信号判定只看租约是否到期不依赖网络探活时钟偏差也不会造成误删——因为删除前还要再过一道 CAS见下文。决策逻辑与 I/O 分离判定函数放在无 I/O 的 crates/logic/ 逻辑层方便单元测试穷举边界情况。 修复分两步先清碎片再删租约判定一个节点死亡后GC 会做两次清理顺序不能颠倒第 1 步清理node-cells/标记碎片历史上 celld 曾在node-cells/节点/代次/cell路径下写归属索引标记。节点死掉后它名下所有代次的标记都成了垃圾按前缀匹配、丢弃代次解析函数见 crates/logic/dead_node_reconciliation.rs 的parse_marker_key。GC 会列出这些标记并以 64 并发删除crates/celld/dead_node_gc.rs。第 2 步用墓碑 CAS删除租约记录对象存储不支持条件删除于是 celld 采用一个精巧的两段式retire_dead_node先以 CAS 把记录改写为一个墓碑expires_ms: 0仍然是一份死的记录CAS 成功说明租约在读取后没被别人续过再执行真正的删除如果 CAS 失败说明节点恰好复活并续租了——直接放弃什么都不删。即使进程在两步之间崩溃也没关系留下的墓碑记录读取时依然是死的下一轮 GC 会接着删掉。整个流程是崩溃安全crash-safe的。⏱️ 失败怎么办指数退避的重试如果标记删除有失败比如存储短暂不可用GC 不会立刻重扫而是按指数退避推迟重试延迟从 1 个 tick 起逐次翻倍封顶 64 个 tick纯函数retry_delay_ms见 crates/logic/dead_node_reconciliation.rs。退避状态只保存在进程内存里retries/swept重启后自动重建不落盘、不引入新的协调对象一个扫完但没删干净的节点不会重复触发全桶扫描只有条件删除剩余时才重试每次清理完成都会打出一条dead_node_reconciliation日志事件包含清理的标记数、退休数与失败数便于运维核对。 如何在生产集群中观察它用celld diagnose --bucket s3://your-bucket会列出每一条节点租约并探测存活对等节点能直接区分过期记录、地址异常、节点不可达等状态用法见 README.md 的 Operate a fleet 一节相关的所有权与防写坏fencing机制的完整论证推荐阅读官方文档 docs/fencing.md为什么epoch 前缀 条件写能保证一个 cell 同时只有一个写者环境变量的完整清单在 docs/README.md其中CELLD_WAKER_TICK_MS控制 waker 与 GC 的 tick 间隔。 小结celld 的死节点对账与 GC本质上是一套桶内自治的清理协议建议性选举决定谁来扫保守判定名字一致 租约到期决定扫谁墓碑 CAS保证删除绝对不误伤复活节点指数退避保证存储抖动时不会变成重试风暴。全程不依赖任何外部协调服务——这正是 celld 无控制面、无共识 设计哲学的又一次体现。【免费下载链接】celldself-hosted, distributed Durable Objects项目地址: https://gitcode.com/GitHub_Trending/ce/celld创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 celld 死节点对账与 GC：过期租约如何被自动清理与修复
celld 死节点对账与 GC过期租约如何被自动清理与修复【免费下载链接】celldself-hosted, distributed Durable Objects项目地址: https://gitcode.com/GitHub_Trending/ce/celldcelld 是一款自托管的分布式 Durable Objects 运行时多个节点通过共享的对象存储桶协同工作。当某个节点宕机或失联后它在桶中留下的节点租约记录会过期如果一直堆积就会污染集群的容量与放置决策。celld 内置了一套死节点对账与 GC 机制由被选举出的 waker 节点周期性地把这些过期租约清理掉让桶始终反映真实存活的集群。 先理解背景celld 里的租约是什么celld 的设计哲学是桶是唯一的持久事实源节点可随时替换见 README.md。为了实现这一点每个节点定期在桶的nodes/前缀下写入一份自己的租约记录nodes/节点名.json里面带有expires_ms过期时间——相当于我承诺在这个时间点之前还会续租。节点之间互相发现、做放置决策时会列出nodes/下的记录只看租约未过期的节点过滤逻辑在 crates/celld/ownership_store.rs。如果节点崩溃后没有再续租它留下的记录就会变成死记录——不删掉它集群就永远以为这台机器还活着。死节点 GC 要做的就是把这些过期租约识别出来、并安全地修复桶中的状态。核心代码在 crates/celld/dead_node_gc.rs。 谁负责清理全集群选举出的 waker 角色清理不能每个节点都做否则会互相打架。celld 的做法是每个节点在每个 tick默认 60 秒由CELLD_WAKER_TICK_MS控制都尝试去持有桶里wake/waker.json这把建议性的 waker 租约抢到的那一个才执行本轮 GC。抢租约用的是对象存储的 compare-and-swapCAS条件写天然保证同一时刻只有一个持有者实现见 crates/celld/wake.rs 中的try_hold_waker。持有者每 TTL/3 的时间续租一次续租失败就立刻取消本轮 GC避免两个清理者长时间并存。这个租约是建议性的即使某个持有者中途崩溃正确性也不会受损——最坏情况只是多花一轮 tick 由别人接手。该循环与到期唤醒扫描共用同一个定时任务入口在 crates/celld/main.rs。 对账三步走如何判定一个节点死了每一轮run_passcrates/celld/dead_node_gc.rs只做三件事判定规则刻意写得极其保守列出nodes/前缀下的全部租约记录读回每条记录校验文件名里的节点名与记录体内的节点名完全一致只有当expires_ms 当前时间时才判定为死节点纯函数判定见 crates/logic/dead_node_reconciliation.rs 的node_record_is_dead。注意两点设计不信时钟之外的任何信号判定只看租约是否到期不依赖网络探活时钟偏差也不会造成误删——因为删除前还要再过一道 CAS见下文。决策逻辑与 I/O 分离判定函数放在无 I/O 的 crates/logic/ 逻辑层方便单元测试穷举边界情况。 修复分两步先清碎片再删租约判定一个节点死亡后GC 会做两次清理顺序不能颠倒第 1 步清理node-cells/标记碎片历史上 celld 曾在node-cells/节点/代次/cell路径下写归属索引标记。节点死掉后它名下所有代次的标记都成了垃圾按前缀匹配、丢弃代次解析函数见 crates/logic/dead_node_reconciliation.rs 的parse_marker_key。GC 会列出这些标记并以 64 并发删除crates/celld/dead_node_gc.rs。第 2 步用墓碑 CAS删除租约记录对象存储不支持条件删除于是 celld 采用一个精巧的两段式retire_dead_node先以 CAS 把记录改写为一个墓碑expires_ms: 0仍然是一份死的记录CAS 成功说明租约在读取后没被别人续过再执行真正的删除如果 CAS 失败说明节点恰好复活并续租了——直接放弃什么都不删。即使进程在两步之间崩溃也没关系留下的墓碑记录读取时依然是死的下一轮 GC 会接着删掉。整个流程是崩溃安全crash-safe的。⏱️ 失败怎么办指数退避的重试如果标记删除有失败比如存储短暂不可用GC 不会立刻重扫而是按指数退避推迟重试延迟从 1 个 tick 起逐次翻倍封顶 64 个 tick纯函数retry_delay_ms见 crates/logic/dead_node_reconciliation.rs。退避状态只保存在进程内存里retries/swept重启后自动重建不落盘、不引入新的协调对象一个扫完但没删干净的节点不会重复触发全桶扫描只有条件删除剩余时才重试每次清理完成都会打出一条dead_node_reconciliation日志事件包含清理的标记数、退休数与失败数便于运维核对。 如何在生产集群中观察它用celld diagnose --bucket s3://your-bucket会列出每一条节点租约并探测存活对等节点能直接区分过期记录、地址异常、节点不可达等状态用法见 README.md 的 Operate a fleet 一节相关的所有权与防写坏fencing机制的完整论证推荐阅读官方文档 docs/fencing.md为什么epoch 前缀 条件写能保证一个 cell 同时只有一个写者环境变量的完整清单在 docs/README.md其中CELLD_WAKER_TICK_MS控制 waker 与 GC 的 tick 间隔。 小结celld 的死节点对账与 GC本质上是一套桶内自治的清理协议建议性选举决定谁来扫保守判定名字一致 租约到期决定扫谁墓碑 CAS保证删除绝对不误伤复活节点指数退避保证存储抖动时不会变成重试风暴。全程不依赖任何外部协调服务——这正是 celld 无控制面、无共识 设计哲学的又一次体现。【免费下载链接】celldself-hosted, distributed Durable Objects项目地址: https://gitcode.com/GitHub_Trending/ce/celld创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考