Neon safekeeper任务

发布时间:2026/10/31 22:26:14
Neon safekeeper任务 safekeeper 的运行时与任务架构safekeeper 使用 5 个独立的 Tokio Runtime通过LazyRuntime静态变量定义每个 runtime 运行在独立的 OS 线程池上从而把 WAL 服务、HTTP 管理接口、Broker 通信、备份导出和后台维护任务彼此隔离避免某一类任务阻塞影响其他关键路径。Runtime 名称线程数用途WAL_SERVICE_RUNTIME默认CPU 核心数WAL 服务主循环接收 compute / pageserver 连接HTTP_RUNTIME默认CPU 核心数HTTP / HTTPS 管理 API 服务BROKER_RUNTIME2 个固定线程与 storage_broker 通信WAL_BACKUP_RUNTIME默认CPU 核心数WAL 备份 / 导出到远程存储BACKGROUND_RUNTIME1 个线程Hadron 后台任务磁盘监控、指标采集主任务树Tasks1. WAL Service 任务wal_service.rstask_main监听 TCP 端口accept 客户端连接后通过tokio::spawn处理每个连接。每个连接生成一个 connection handler task后台异步任务执行 Postgres 协议握手并处理命令START_WAL_PUSH/START_REPLICATION。对应handler.rs中的SafekeeperPostgresHandler。2. HTTP / HTTPS 服务任务http/mod.rstask_main_http/task_main_https通过 Hyper 提供 HTTP 管理 API。路由定义在http/routes.rs处理 timeline 创建 / 删除、metrics 等请求。3. Broker 任务broker.rstask_main协调整个 broker 通信包含三个子任务循环push_loop每秒向 broker 推送所有活跃 timeline 的状态信息。pull_loop从 broker 订阅并拉取其他 safekeeper 的状态更新。discover_loop处理 discovery 请求safekeeper 节点发现。task_stats监控 broker 连接健康超过 10s 无更新则告警。子任务失败会自动重启通过JoinHandletokio::select!轮询。4. Timeline Manager 任务timeline_manager.rs每条 timeline 一个main_taskManager由GlobalTimelines::init()加载时启动。管理该 timeline 的所有后台子任务recovery_taskpeer 恢复recovery.rs。backup_task全量 WAL 备份wal_backup.rs。partial_backup_task部分段备份上传wal_backup_partial.rs。wal_removal_taskWAL 段清理回收。每 300ms 检查一次 timeline 状态决定是否需要驱逐offload。5. 全局后台任务bin/safekeeper.rsTimeline map housekeeping每 24 小时清理已删除 timeline 的 tombstone。Global disk usage watcherHadron定期扫描磁盘使用率触发熔断。Metrics collectionHadron定期强制刷新 Prometheus 指标。工作配合流程flowchart TD Main[Main (current_thread) start_safekeeper()] -- WAL[WAL_SERVICE_RUNTIME task_main accept loop / spawn conn handler] Main -- HTTP[HTTP_RUNTIME task_main_http / task_main_https serve()] Main -- BROKER[BROKER_RUNTIME task_main push_loop / pull_loop / discover_loop / task_stats] Main -- BG[BACKGROUND_RUNTIME housekeeping / disk_watcher / metrics_collect] WAL -- TM[每条 timeline 独立 Manager recovery / backup / partial_backup / wal_removal] BROKER -- TM核心数据流Compute → WAL PushCompute 通过START_WAL_PUSH建立长连接推送 WAL 数据由receive_wal.rs处理并持久化到wal_storage.rs。Pageserver → ReplicationPageserver 通过START_REPLICATION消费已提交的 WAL由send_wal.rs发送。Broker 协调所有 safekeeper 通过 broker 交换 topology 信息实现 peer 发现和恢复。Manager 决策每条 timeline 的 manager 根据commit_lsn、remote_consistent_lsn等决定 WAL 清理、备份上传、offload 驱逐等动作。

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询