（11717期）postgres-job-queue – 零依赖 PostgreSQL 任务队列引擎

零依赖 PostgreSQL 任务队列引擎 PostgreSQL 原生作业队列，零依赖实现优先级调度与进度跟踪，适合已有 PG 基础设施、追求架构简化的技术团队。 使用说明 PostgreSQL Job Queue 综合评估 核心用法 该技能提供了一套完整的基于 PostgreSQL 的生产级作业队列实现方案。核心机制利用 PostgreSQL 9.5+ 引入的 SKIP LOCKED 特性，通过 claimjobbatch 函数实现并发安全的作业批量认领，避免传统 "SELECT then UPDATE" 模式导致的竞态条件。方案支持优先级调度（默认 100，可配置 30-150）、作业状态机管理（pending/claimed/running/completed/failed）、自动重试机制（默认 3 次）以及进度跟踪（progress 字段 + current_stage）。开发者可通过 Go 的 pgx 驱动集成，利用部分索引（partial index）优化查询性能，确保在高并发场景下的 claiming 效率。 显著优点 最突出的优势是架构简化——无需引入 Redis、RabbitMQ 等外部依赖，直接复用现有 PostgreSQL 基础设施，降低运维复杂度和系统脆弱性。数据持久化由数据库事务保证，作业状态在服务端重启后依然可靠，解决了内存队列的数据丢失问题。进度跟踪机制（progress/events_count）为长时任务提供了可视性，便于监控和调试。此外，方案充分利用 SQL 的表达能力，通过 JSONB 字段存储灵活的任务数据，配合 GIN 索引可高效查询特定类型的作业。 潜在缺点与局限性 吞吐量存在明显瓶颈，文档明确指出超过 1000 jobs/s 时应考虑 Redis，超过 10000 jobs/s 必须引入 Redis 层。高频的 claiming 操作会增加数据库负载，特别是在高并发 worker 场景下，FOR UPDATE SKIP LOCKED 可能引发锁竞争。功能上缺乏延迟队列（delay queue）、死信队列（DLQ）等高级特性，需自行实现。此外，依赖 PostgreSQL 特定功能（如 genrandomuuid() 要求 13+ 版本或 pgcrypto 扩展），对旧版本数据库兼容性有限。 适合的目标群体 特别适合中小型应用和初创团队，尤其是已使用 PostgreSQL 作为主力数据库、希望控制技术栈复杂度的场景。适用于对延迟不敏感（可接受毫秒级而非亚毫秒级）、需要强一致性保证的后台任务，如邮件发送、报表生成、数据同步、定时清理等。对于微服务架构中的轻量级任务调度，或作为现有消息队列的降级方案（fallback）也很合适。不适合高频交易、实时流处理或需要复杂路由规则的企业级消息总线场景。 使用风险与注意事项 性能风险：未正确配置连接池（pgx.Pool）可能导致连接泄漏，耗尽数据库资源。idxjobsclaimable 部分索引对性能至关重要，若遗漏或维护不当，claiming 操作将随数据量增长而急剧变慢。配置风险：RecoverStaleJobs 的超时参数设置不当会导致作业被过早回收（重复执行）或过晚回收（延迟处理）。数据风险：虽然使用参数化查询防止 SQL 注入，但 data JSONB 字段存储的用户输入仍需应用层校验，避免存储过大 payload 拖垮数据库（文档明确建议仅存储引用）。版本兼容性：使用 genrandomuuid() 需确保 PostgreSQL 版本支持，否则需改用 uuid-ossp 扩展或应用层生成 ID。 原始说明 PostgreSQL-based job queue with priority scheduling, batch claiming, and progress tracking. Use when building job queues without external dependencies. Triggers on PostgreSQL job queue, background jobs, task queue, priority queue, SKIP LOCKED.