ScyllaDB Task Manager REST API 完全指南任务监控、中止与 TTL 管理实战【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb导读Task Manager 是 ScyllaDB 内置的后台任务管理框架统一追踪 repair、compaction、node operations 等长时间运行操作的创建、执行与完成状态。本文以 docs/reference/api/task-manager.rst 所嵌入的 Swagger 规范 api/api-doc/task_manager.json 为骨架结合 api/task_manager.cc 与 tasks/ 模块源码完整讲解 Task Manager REST API 的全部 9 组端点、任务状态机、数据模型与 TTL 配置机制。读完本文你将能够通过 curl 或编程方式列出任务、查询单个任务及子孙任务的详细状态、等待任务完成、中止不可控任务并动态调整已完成任务的保留时长。Task Manager 的设计背景与核心概念在 ScyllaDB 中很多运维操作如 repair、scrub、cleanup、拓扑变更、tablets 迁移等都是耗时较长的后台任务且往往可以分解为分布在多个 shard 甚至多个节点上的子任务。为了统一管理这些操作ScyllaDB 在tasks::task_manager中实现了一套可观测、可中止、带父子层级关系的任务框架核心实现在 tasks/task_manager.hh并通过 REST API 对外暴露。理解这套 API 前需要掌握几个关键概念Module模块任务的分类容器例如 repair、compaction、node ops 等。task_manager::make_module注册模块API 的list_modules端点可以枚举当前节点注册的所有模块名。Task任务一次具体操作拥有唯一的task_idUUID、状态state、类型type、作用域scope等属性。Kind类型任务分node节点级与cluster集群级两种。node任务运行在单个节点的某个 shard 上cluster任务则是跨节点协作的虚拟任务由其子任务聚合进度。父子层级父任务可以派生子任务甚至分布到其他 shard/节点API 支持按 BFS 顺序递归获取整棵任务树的状态。TTL 保留机制任务结束后并不会立刻从内存中消失而是按配置保留一段时间供查询之后才被回收。REST API 端点总览Task Manager 的所有端点均挂在/task_manager路径下生产环境默认通过 Scylla 的 REST API 端口--api-port默认 10000对外提供返回application/json。以下是完整端点清单方法与路径说明GET /task_manager/list_modules获取所有模块名称GET /task_manager/list_module_tasks/{module}获取某模块的任务统计列表支持internal、keyspace、table过滤GET /task_manager/task_status/{task_id}获取单个任务的状态POST /task_manager/abort_task/{task_id}中止运行中的任务及其子孙任务GET /task_manager/wait_task/{task_id}?timeout等待任务完成超时返回 408GET /task_manager/task_status_recursive/{task_id}获取任务及其所有子孙任务的状态BFS 顺序GET/POST /task_manager/ttl?ttl读取/设置内部任务 TTL秒GET/POST /task_manager/user_ttl?user_ttl读取/设置用户任务 TTL秒POST /task_manager/drain/{module}排空清理某模块已完成的本地任务以上端点与task_stats、task_status、task_identity三个数据模型均定义在 api/api-doc/task_manager.json 中并由 api/task_manager.cc 的set_task_manager()逐一绑定到 Seastar HTTP 路由。在 api/api.cc 中可以看到它在服务启动时被注册并在关闭时通过unset_task_manager()反注册。枚举模块与任务列表列出所有模块curl -X GET http://node-ip:10000/task_manager/list_modules该端点无参数返回字符串数组例如[repair, compaction, node_ops]从源码看它直接读取task_manager::get_modules()的键集合见 api/task_manager.cc。不同版本、不同启动配置下模块集合会有所不同。列出模块下的任务curl -X GET http://node-ip:10000/task_manager/list_module_tasks/{module}路径参数参数位置必填类型说明modulepath是string要查询的模块名internalquery否boolean是否显示内部任务默认falsekeyspacequery否string按 keyspace 过滤tablequery否string按表名过滤返回task_stats数组。例如查询 repair 模块的任务curl -X GET http://node-ip:10000/task_manager/list_module_tasks/repair从实现看api/task_manager.cc该端点会在所有 shard上对目标模块调用module-get_stats(internal, filter)随后将各 shard 结果流式拼装成 JSON 数组返回keyspace/table过滤条件以闭包方式传入只有同时满足两个过滤条件的任务才会被包含在结果中。internal参数对应tasks::is_internal标记用于区分内部任务与用户发起的任务。若模块名不存在会抛出bad_param_exceptionHTTP 400。查询任务状态获取单个任务状态curl -X GET http://node-ip:10000/task_manager/task_status/{task_id}其中task_id为任务的 UUID。返回task_status对象。若任务不存在返回 400源码中捕获task_not_found异常并转为bad_param_exception见 api/task_manager.cc。递归获取任务树状态curl -X GET http://node-ip:10000/task_manager/task_status_recursive/{task_id}返回task_status数组包含任务自身及所有子孙任务的状态按 BFS广度优先顺序排列。实现位于 tasks/task_handler.cc先获取根任务状态再通过children_ids逐层入队展开对于运行中的子任务跨 shard 提交查询对已完成的子任务则直接使用父任务缓存的task_essentials快照。需要注意当host_id与本地不一致的远程子任务会被跳过源码中标注了 add non-local version 的 TODO即当前版本主要返回本节点可达的任务树。等待任务完成curl -X GET http://node-ip:10000/task_manager/wait_task/{task_id}?timeout60查询参数timeoutlong可选等待的最长秒数。任务完成后返回其最终task_status若超时返回 HTTP 408源码中捕获timed_out_error并映射为request_timeout见 api/task_manager.cc。底层通过task-done()等待任务完成后再取状态tasks/task_handler.cc并支持db::timeout_clock限时。测试客户端 test/cluster/tasks/task_manager_client.py 中提供了与这些端点一一对应的封装方法get_task_status、get_task_status_recursively、wait_for_task等可作为集成调用参考。中止任务curl -X POST http://node-ip:10000/task_manager/abort_task/{task_id}路径参数task_id要中止的任务 UUID。该操作会中止运行中的任务及其子孙任务返回空响应void。需要注意的语义细节若任务不可中止is_abortable为 false返回 HTTP 403。源码中在 api/task_manager.cc 捕获task_not_abortable异常并映射为forbidden。若任务不存在返回 400。中止是协作式的task::abort()会触发任务内部的abort_source置位任务在各检查点响应中止请求见 tasks/task_manager.hh 中task::impl的abort()与_as字段。数据模型详解task_stats任务统计列表场景task_stats用于任务列表场景字段如下字段类型说明task_idstring任务 UUIDstatestring任务状态枚举created、running、done、failed、suspendedtypestring任务类型描述kindstringnode或clusterscopestring任务作用域keyspacestring任务操作的 keyspace如适用tablestring任务操作的表如适用entitystring任务特有的实体描述sequence_numberlong任务的运行序号shardlong任务所在的 shardstart_timedatetime开始时间state created时等于 epochend_timedatetime结束时间未完成时等于 epoch状态枚举在 tasks/task_manager.hh 中定义与 Swagger 规范一致。task_status任务状态详情场景task_status是比task_stats更丰富的状态对象用于单任务查询与递归查询字段类型说明idstring任务 UUIDtypestring任务类型描述kindstringnode或clusterscopestring任务作用域statestring任务状态同上枚举is_abortableboolean任务是否可中止start_timedatetime开始时间end_timedatetime结束时间未完成时不指定errorstring任务失败时的错误信息parent_idstring父任务 UUID无父任务时为nonesequence_numberlong运行序号shardlong任务所在 shard 号keyspacestring操作的 keyspace如适用tablestring操作的表如适用entitystring任务特有实体描述progress_unitsstring进度单位的文字描述如 rangesprogress_totaldouble完成任务所需的总单位数progress_completeddouble已完成单位数children_idsarraytask_identity子任务标识列表其中progress_total/progress_completed由任务的progress结构completed/total映射而来见 tasks/task_manager.hh 与 api/task_manager.cc。task_identity任务标识children_ids数组中的元素类型字段类型说明task_idstring子任务 UUIDnodestring创建该任务的服务器地址实现中通过gossiper的地址映射将子任务所在节点的host_id解析为inet_address填入node字段api/task_manager.cc。TTL控制已完成任务的保留时长任务完成后其元数据并不会立即删除而是按 TTL 在内存中保留一段时间以便上层应用轮询最终状态。Task Manager 提供两套独立的 TTL内部任务 TTL/task_manager/ttl内部任务指系统内部发起、非用户直接触发的任务。# 读取当前值 curl -X GET http://node-ip:10000/task_manager/ttl # 设置新值秒返回旧值 curl -X POST http://node-ip:10000/task_manager/ttl?ttl600POST的查询参数ttllong必填内部任务结束后在内存中保留的秒数。响应为 long 类型返回上一次的值即设置前的旧值。源码实现直接读写配置项task_ttl_in_secondsapi/task_manager.cc并通过set_value_on_all_shards同步到所有 shard。用户任务 TTL/task_manager/user_ttl# 读取当前值 curl -X GET http://node-ip:10000/task_manager/user_ttl # 设置新值秒返回旧值 curl -X POST http://node-ip:10000/task_manager/user_ttl?user_ttl3600POST的查询参数user_ttllong必填用户发起的任务完成后在内存中保留的秒数同样返回旧值。实现对应配置项user_task_ttl_in_secondsapi/task_manager.cc。配置默认值与热更新两个 TTL 都有对应的持久化配置项定义在 db/config.cctask_ttl_in_seconds内部任务保留秒数默认0即内部任务结束后立即回收不保留。user_task_ttl_in_seconds用户任务保留秒数默认36001 小时。两者均为liveness::LiveUpdate即支持运行时热更新——除了通过 REST API 修改也可以直接在 scylla.yaml 中配置后通过set_value_on_all_shards机制动态生效无需重启节点。也可以在启动时通过命令行--task-ttl-in-seconds、--user-task-ttl-in-seconds指定初始值。排空已完成任务curl -X POST http://node-ip:10000/task_manager/drain/{module}路径参数module要清理的模块名。该端点会在所有 shard上遍历该模块的本地任务将已完成的is_complete()任务从注册表中注销unregister_task以释放内存对仍在运行的任务不做处理。返回空响应。实现见 api/task_manager.cc测试客户端中对应的drain_module_tasks方法test/cluster/tasks/task_manager_client.py会在排空前先wait_task确保任务完成。从源码理解 API 的内部调用链把上述端点映射到内部实现可以形成一条清晰的调用链路由层api::set_task_manager()api/task_manager.cc把每个 Swagger 操作绑定到 Seastarroutes闭包捕获shardedtasks::task_manager、db::config与gossiper。定位层task_handlertasks/task_handler.hh通过task_manager::invoke_on_task在所有 shard 上按task_id查找任务tasks/task_manager.hh若本地找不到再回落到 shard 0 查询虚拟任务virtual task。状态聚合层get_status()/wait_for_task()/get_status_recursively()分别实现单任务状态、等待完成与 BFS 递归展开跨 shard 子任务通过foreign_task_ptr提交到所属 shard 执行查询tasks/task_handler.cc。展示层make_status()/make_stats()将内部结构转换为 JSON 模型children_ids中的host_id经 gossiper 地址映射为节点地址。此外tasks::task_manager::module提供make_and_start_task等工厂方法tasks/task_manager.hh实际业务模块如 repair 的task_manager_module见 repair/task_manager_module.hh通过继承module注册自己的任务类型从而自动获得这套 API 的统一可观测性。实战用 curl 编排一次任务生命周期假设节点 REST API 端口为 10000可以按以下顺序完整走一遍# 1. 查看有哪些任务模块 curl -s http://127.0.0.1:10000/task_manager/list_modules # 2. 查看 repair 模块当前任务含 keyspace 过滤 curl -s http://127.0.0.1:10000/task_manager/list_module_tasks/repair?keyspacemykeyspace # 3. 取出某个任务的 task_id 后查询详情 curl -s http://127.0.0.1:10000/task_manager/task_status/task_id # 4. 等待该任务完成最多等 120 秒 curl -s http://127.0.0.1:10000/task_manager/wait_task/task_id?timeout120 # 5. 递归查看该任务及其子任务的状态 curl -s http://127.0.0.1:10000/task_manager/task_status_recursive/task_id # 6. 如果任务卡死且可中止则中止它不可中止时返回 403 curl -s -X POST http://127.0.0.1:10000/task_manager/abort_task/task_id # 7. 调整用户任务 TTL 为 2 小时返回修改前的旧值 curl -s -X POST http://127.0.0.1:10000/task_manager/user_ttl?user_ttl7200 # 8. 清理 repair 模块已完成任务 curl -s -X POST http://127.0.0.1:10000/task_manager/drain/repair关于abort_task的 403 行为、wait_task的 408 超时行为、task_status对不存在任务返回 400 等语义均已在上文对应小节依据 api/task_manager.cc 源码说明可在自动化脚本中作为预期分支处理。集群级集成测试可参考 test/cluster/tasks/test_node_ops_tasks.py 与 test/cluster/tasks/test_tablet_tasks.py 中对task_manager_client的使用方式。小结ScyllaDB Task Manager REST API 提供了一整套面向后台任务的运维接口通过list_modules/list_module_tasks枚举任务通过task_status/task_status_recursive/wait_task观测任务树与最终状态通过abort_task干预失控任务通过ttl/user_ttl控制历史任务的保留窗口通过drain主动回收内存。其数据模型与语义完整定义于 api/api-doc/task_manager.json实现与配置分别落在 api/task_manager.cc、tasks/task_handler.cc 与 db/config.cc开发者既可以直接使用 HTTP API 构建运维面板也可以参照tasks::task_manager::module的扩展点将自定义长任务纳入统一的任务管理框架。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
ScyllaDB Task Manager REST API 完全指南：任务监控、中止与 TTL 管理实战
ScyllaDB Task Manager REST API 完全指南任务监控、中止与 TTL 管理实战【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb导读Task Manager 是 ScyllaDB 内置的后台任务管理框架统一追踪 repair、compaction、node operations 等长时间运行操作的创建、执行与完成状态。本文以 docs/reference/api/task-manager.rst 所嵌入的 Swagger 规范 api/api-doc/task_manager.json 为骨架结合 api/task_manager.cc 与 tasks/ 模块源码完整讲解 Task Manager REST API 的全部 9 组端点、任务状态机、数据模型与 TTL 配置机制。读完本文你将能够通过 curl 或编程方式列出任务、查询单个任务及子孙任务的详细状态、等待任务完成、中止不可控任务并动态调整已完成任务的保留时长。Task Manager 的设计背景与核心概念在 ScyllaDB 中很多运维操作如 repair、scrub、cleanup、拓扑变更、tablets 迁移等都是耗时较长的后台任务且往往可以分解为分布在多个 shard 甚至多个节点上的子任务。为了统一管理这些操作ScyllaDB 在tasks::task_manager中实现了一套可观测、可中止、带父子层级关系的任务框架核心实现在 tasks/task_manager.hh并通过 REST API 对外暴露。理解这套 API 前需要掌握几个关键概念Module模块任务的分类容器例如 repair、compaction、node ops 等。task_manager::make_module注册模块API 的list_modules端点可以枚举当前节点注册的所有模块名。Task任务一次具体操作拥有唯一的task_idUUID、状态state、类型type、作用域scope等属性。Kind类型任务分node节点级与cluster集群级两种。node任务运行在单个节点的某个 shard 上cluster任务则是跨节点协作的虚拟任务由其子任务聚合进度。父子层级父任务可以派生子任务甚至分布到其他 shard/节点API 支持按 BFS 顺序递归获取整棵任务树的状态。TTL 保留机制任务结束后并不会立刻从内存中消失而是按配置保留一段时间供查询之后才被回收。REST API 端点总览Task Manager 的所有端点均挂在/task_manager路径下生产环境默认通过 Scylla 的 REST API 端口--api-port默认 10000对外提供返回application/json。以下是完整端点清单方法与路径说明GET /task_manager/list_modules获取所有模块名称GET /task_manager/list_module_tasks/{module}获取某模块的任务统计列表支持internal、keyspace、table过滤GET /task_manager/task_status/{task_id}获取单个任务的状态POST /task_manager/abort_task/{task_id}中止运行中的任务及其子孙任务GET /task_manager/wait_task/{task_id}?timeout等待任务完成超时返回 408GET /task_manager/task_status_recursive/{task_id}获取任务及其所有子孙任务的状态BFS 顺序GET/POST /task_manager/ttl?ttl读取/设置内部任务 TTL秒GET/POST /task_manager/user_ttl?user_ttl读取/设置用户任务 TTL秒POST /task_manager/drain/{module}排空清理某模块已完成的本地任务以上端点与task_stats、task_status、task_identity三个数据模型均定义在 api/api-doc/task_manager.json 中并由 api/task_manager.cc 的set_task_manager()逐一绑定到 Seastar HTTP 路由。在 api/api.cc 中可以看到它在服务启动时被注册并在关闭时通过unset_task_manager()反注册。枚举模块与任务列表列出所有模块curl -X GET http://node-ip:10000/task_manager/list_modules该端点无参数返回字符串数组例如[repair, compaction, node_ops]从源码看它直接读取task_manager::get_modules()的键集合见 api/task_manager.cc。不同版本、不同启动配置下模块集合会有所不同。列出模块下的任务curl -X GET http://node-ip:10000/task_manager/list_module_tasks/{module}路径参数参数位置必填类型说明modulepath是string要查询的模块名internalquery否boolean是否显示内部任务默认falsekeyspacequery否string按 keyspace 过滤tablequery否string按表名过滤返回task_stats数组。例如查询 repair 模块的任务curl -X GET http://node-ip:10000/task_manager/list_module_tasks/repair从实现看api/task_manager.cc该端点会在所有 shard上对目标模块调用module-get_stats(internal, filter)随后将各 shard 结果流式拼装成 JSON 数组返回keyspace/table过滤条件以闭包方式传入只有同时满足两个过滤条件的任务才会被包含在结果中。internal参数对应tasks::is_internal标记用于区分内部任务与用户发起的任务。若模块名不存在会抛出bad_param_exceptionHTTP 400。查询任务状态获取单个任务状态curl -X GET http://node-ip:10000/task_manager/task_status/{task_id}其中task_id为任务的 UUID。返回task_status对象。若任务不存在返回 400源码中捕获task_not_found异常并转为bad_param_exception见 api/task_manager.cc。递归获取任务树状态curl -X GET http://node-ip:10000/task_manager/task_status_recursive/{task_id}返回task_status数组包含任务自身及所有子孙任务的状态按 BFS广度优先顺序排列。实现位于 tasks/task_handler.cc先获取根任务状态再通过children_ids逐层入队展开对于运行中的子任务跨 shard 提交查询对已完成的子任务则直接使用父任务缓存的task_essentials快照。需要注意当host_id与本地不一致的远程子任务会被跳过源码中标注了 add non-local version 的 TODO即当前版本主要返回本节点可达的任务树。等待任务完成curl -X GET http://node-ip:10000/task_manager/wait_task/{task_id}?timeout60查询参数timeoutlong可选等待的最长秒数。任务完成后返回其最终task_status若超时返回 HTTP 408源码中捕获timed_out_error并映射为request_timeout见 api/task_manager.cc。底层通过task-done()等待任务完成后再取状态tasks/task_handler.cc并支持db::timeout_clock限时。测试客户端 test/cluster/tasks/task_manager_client.py 中提供了与这些端点一一对应的封装方法get_task_status、get_task_status_recursively、wait_for_task等可作为集成调用参考。中止任务curl -X POST http://node-ip:10000/task_manager/abort_task/{task_id}路径参数task_id要中止的任务 UUID。该操作会中止运行中的任务及其子孙任务返回空响应void。需要注意的语义细节若任务不可中止is_abortable为 false返回 HTTP 403。源码中在 api/task_manager.cc 捕获task_not_abortable异常并映射为forbidden。若任务不存在返回 400。中止是协作式的task::abort()会触发任务内部的abort_source置位任务在各检查点响应中止请求见 tasks/task_manager.hh 中task::impl的abort()与_as字段。数据模型详解task_stats任务统计列表场景task_stats用于任务列表场景字段如下字段类型说明task_idstring任务 UUIDstatestring任务状态枚举created、running、done、failed、suspendedtypestring任务类型描述kindstringnode或clusterscopestring任务作用域keyspacestring任务操作的 keyspace如适用tablestring任务操作的表如适用entitystring任务特有的实体描述sequence_numberlong任务的运行序号shardlong任务所在的 shardstart_timedatetime开始时间state created时等于 epochend_timedatetime结束时间未完成时等于 epoch状态枚举在 tasks/task_manager.hh 中定义与 Swagger 规范一致。task_status任务状态详情场景task_status是比task_stats更丰富的状态对象用于单任务查询与递归查询字段类型说明idstring任务 UUIDtypestring任务类型描述kindstringnode或clusterscopestring任务作用域statestring任务状态同上枚举is_abortableboolean任务是否可中止start_timedatetime开始时间end_timedatetime结束时间未完成时不指定errorstring任务失败时的错误信息parent_idstring父任务 UUID无父任务时为nonesequence_numberlong运行序号shardlong任务所在 shard 号keyspacestring操作的 keyspace如适用tablestring操作的表如适用entitystring任务特有实体描述progress_unitsstring进度单位的文字描述如 rangesprogress_totaldouble完成任务所需的总单位数progress_completeddouble已完成单位数children_idsarraytask_identity子任务标识列表其中progress_total/progress_completed由任务的progress结构completed/total映射而来见 tasks/task_manager.hh 与 api/task_manager.cc。task_identity任务标识children_ids数组中的元素类型字段类型说明task_idstring子任务 UUIDnodestring创建该任务的服务器地址实现中通过gossiper的地址映射将子任务所在节点的host_id解析为inet_address填入node字段api/task_manager.cc。TTL控制已完成任务的保留时长任务完成后其元数据并不会立即删除而是按 TTL 在内存中保留一段时间以便上层应用轮询最终状态。Task Manager 提供两套独立的 TTL内部任务 TTL/task_manager/ttl内部任务指系统内部发起、非用户直接触发的任务。# 读取当前值 curl -X GET http://node-ip:10000/task_manager/ttl # 设置新值秒返回旧值 curl -X POST http://node-ip:10000/task_manager/ttl?ttl600POST的查询参数ttllong必填内部任务结束后在内存中保留的秒数。响应为 long 类型返回上一次的值即设置前的旧值。源码实现直接读写配置项task_ttl_in_secondsapi/task_manager.cc并通过set_value_on_all_shards同步到所有 shard。用户任务 TTL/task_manager/user_ttl# 读取当前值 curl -X GET http://node-ip:10000/task_manager/user_ttl # 设置新值秒返回旧值 curl -X POST http://node-ip:10000/task_manager/user_ttl?user_ttl3600POST的查询参数user_ttllong必填用户发起的任务完成后在内存中保留的秒数同样返回旧值。实现对应配置项user_task_ttl_in_secondsapi/task_manager.cc。配置默认值与热更新两个 TTL 都有对应的持久化配置项定义在 db/config.cctask_ttl_in_seconds内部任务保留秒数默认0即内部任务结束后立即回收不保留。user_task_ttl_in_seconds用户任务保留秒数默认36001 小时。两者均为liveness::LiveUpdate即支持运行时热更新——除了通过 REST API 修改也可以直接在 scylla.yaml 中配置后通过set_value_on_all_shards机制动态生效无需重启节点。也可以在启动时通过命令行--task-ttl-in-seconds、--user-task-ttl-in-seconds指定初始值。排空已完成任务curl -X POST http://node-ip:10000/task_manager/drain/{module}路径参数module要清理的模块名。该端点会在所有 shard上遍历该模块的本地任务将已完成的is_complete()任务从注册表中注销unregister_task以释放内存对仍在运行的任务不做处理。返回空响应。实现见 api/task_manager.cc测试客户端中对应的drain_module_tasks方法test/cluster/tasks/task_manager_client.py会在排空前先wait_task确保任务完成。从源码理解 API 的内部调用链把上述端点映射到内部实现可以形成一条清晰的调用链路由层api::set_task_manager()api/task_manager.cc把每个 Swagger 操作绑定到 Seastarroutes闭包捕获shardedtasks::task_manager、db::config与gossiper。定位层task_handlertasks/task_handler.hh通过task_manager::invoke_on_task在所有 shard 上按task_id查找任务tasks/task_manager.hh若本地找不到再回落到 shard 0 查询虚拟任务virtual task。状态聚合层get_status()/wait_for_task()/get_status_recursively()分别实现单任务状态、等待完成与 BFS 递归展开跨 shard 子任务通过foreign_task_ptr提交到所属 shard 执行查询tasks/task_handler.cc。展示层make_status()/make_stats()将内部结构转换为 JSON 模型children_ids中的host_id经 gossiper 地址映射为节点地址。此外tasks::task_manager::module提供make_and_start_task等工厂方法tasks/task_manager.hh实际业务模块如 repair 的task_manager_module见 repair/task_manager_module.hh通过继承module注册自己的任务类型从而自动获得这套 API 的统一可观测性。实战用 curl 编排一次任务生命周期假设节点 REST API 端口为 10000可以按以下顺序完整走一遍# 1. 查看有哪些任务模块 curl -s http://127.0.0.1:10000/task_manager/list_modules # 2. 查看 repair 模块当前任务含 keyspace 过滤 curl -s http://127.0.0.1:10000/task_manager/list_module_tasks/repair?keyspacemykeyspace # 3. 取出某个任务的 task_id 后查询详情 curl -s http://127.0.0.1:10000/task_manager/task_status/task_id # 4. 等待该任务完成最多等 120 秒 curl -s http://127.0.0.1:10000/task_manager/wait_task/task_id?timeout120 # 5. 递归查看该任务及其子任务的状态 curl -s http://127.0.0.1:10000/task_manager/task_status_recursive/task_id # 6. 如果任务卡死且可中止则中止它不可中止时返回 403 curl -s -X POST http://127.0.0.1:10000/task_manager/abort_task/task_id # 7. 调整用户任务 TTL 为 2 小时返回修改前的旧值 curl -s -X POST http://127.0.0.1:10000/task_manager/user_ttl?user_ttl7200 # 8. 清理 repair 模块已完成任务 curl -s -X POST http://127.0.0.1:10000/task_manager/drain/repair关于abort_task的 403 行为、wait_task的 408 超时行为、task_status对不存在任务返回 400 等语义均已在上文对应小节依据 api/task_manager.cc 源码说明可在自动化脚本中作为预期分支处理。集群级集成测试可参考 test/cluster/tasks/test_node_ops_tasks.py 与 test/cluster/tasks/test_tablet_tasks.py 中对task_manager_client的使用方式。小结ScyllaDB Task Manager REST API 提供了一整套面向后台任务的运维接口通过list_modules/list_module_tasks枚举任务通过task_status/task_status_recursive/wait_task观测任务树与最终状态通过abort_task干预失控任务通过ttl/user_ttl控制历史任务的保留窗口通过drain主动回收内存。其数据模型与语义完整定义于 api/api-doc/task_manager.json实现与配置分别落在 api/task_manager.cc、tasks/task_handler.cc 与 db/config.cc开发者既可以直接使用 HTTP API 构建运维面板也可以参照tasks::task_manager::module的扩展点将自定义长任务纳入统一的任务管理框架。【免费下载链接】scylladbNoSQL data store using the Seastar framework, compatible with Apache Cassandra and Amazon DynamoDB项目地址: https://gitcode.com/GitHub_Trending/sc/scylladb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考