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 驱逐等动作。