返回项目列表
Project Overview

nautilus-media-cloud

一个基于 PostgreSQL SKIP LOCKED 的 Pull 型异步任务调度项目,包含 Spring Boot 控制面、Python Worker 和轻量控制台,用于验证数据库队列、任务认领和状态流转链路。

01

把 PostgreSQL 当作任务调度核心,用 SKIP LOCKED 完成 Pull 型任务认领,重点展示并发认领、状态流转和任务重试机制。

02

采用 Spring Boot 控制面 + Python Worker 的跨语言协作方式,让调度、执行和前台展示职责更清晰。

03

补充超时回收、失败重试、SSE 状态推送和 JSONB 元信息存储,项目更适合讨论工程取舍,而不是只做任务列表页面。

Verified Outcomes

可验证结果

这里不写虚高的性能数字,只收束当前仓库和页面里可以直接验证的工程结果。

1 套

数据库认领机制

基于 PostgreSQL 与 SKIP LOCKED 实现 Pull 型任务认领,说明核心调度逻辑不是停留在概念层。

4 类

稳定性环节

认领、重试、超时回收、状态推送都已进入同一条执行链路,项目具备基本调度闭环。

3 层

协作职责拆分

控制面、Python Worker、轻量控制台分工清晰,适合解释跨语言协作与边界划分。

Context

项目背景 / 目标

  • 验证在不引入 MQ 的前提下,数据库队列是否能支撑一个结构清晰的异步任务调度原型。
  • 沉淀一个能体现任务系统、并发控制、跨语言协作和工程边界判断的项目案例。
Ownership

我的职责

  • 负责任务模型设计、调度流程实现、控制面接口、Worker 通信方式和控制台页面组织。
  • 负责 PostgreSQL 任务表结构、认领逻辑、失败重试、超时回收、状态推送和项目文档整理。
  • 负责仓库公开整理、启动脚本、截图、架构说明和边界描述。
Evidence

关键页面与交付证据

这里保留的是最能说明调度控制面价值的界面,不再把截图当作单纯的页面陈列。

Interview Notes

面试可继续展开

这部分不重复上面的总览结论,只保留适合继续追问的判断、取舍和后续迭代方向。

为什么这个项目值得看

这个项目适合展示后端工程取舍,而不是单纯展示功能数量。它围绕“任务如何入库、如何认领、如何防止并发冲突、如何失败重试、如何把状态推给控制台”这条链路组织实现,比起普通 CRUD 项目,更能说明我对系统边界和调度机制的理解。

面试里适合继续追问的点

  • 为什么这里选择 PostgreSQL SKIP LOCKED,而不是先引入 MQ
  • 任务认领为什么必须放在同一事务里完成
  • 超时回收、失败重试和状态流转如何避免出现脏状态
  • 为什么 Worker 不直接连接数据库,以及跨语言协作怎么划清边界

如果继续迭代

  • 增加任务流转时序图和数据表结构图
  • 补充调度压力测试与更细的失败注入验证
  • 收口更完整的权限和文件依赖管理能力
Boundary

项目边界说明

  • 当前项目以本地启动和仓库展示为主,暂不提供公网 Demo。
  • 项目强调数据库队列方案的工程取舍,不等同于通用生产级调度平台。
  • 鉴权、下载路径、本机文件依赖和小规模统计聚合等限制,已在仓库文档中显式说明。