【免费下载链接】PgQuePgQue – Zero-bloat Postgres queue built on top of on battle-proven Skypes PgQ. One SQL file to install, pg_cron to tick https://pgque.dev项目地址https://gitcode.com/gh_mirrors/pg/PgQue点击查看免费下载PgQue 是一个零膨胀的 Postgres 消息队列用 1 个 SQL 文件即可安装纯 PL/pgSQL 实现、无需 C 扩展由 pg_cron 负责心跳。它把 Skype 时期久经考验的 PgQ 引擎用现代方式重构让任何托管 PostgresRDS、Cloud SQL、Neon 等都能拥有 Kafka 式的事件流而不必再引入一套分布式系统。先认识陷阱大多数 Postgres 队列为什么会膨胀市面上大多数 Postgres 队列PGMQ、River、pg-boss 等的套路是消费时用SELECT ... FOR UPDATE SKIP LOCKED抢占一行消费完就DELETE或UPDATE这一行单看没问题但每处理一个任务都会留下一具死元组dead tuple只能靠VACUUM回收。一旦某个长事务、卡住的复制或REPEATABLE READ会话把 xmin 水位线钉住VACUUM 就无法回收任何空间——队列表开始膨胀、读延迟飙升、吞吐量下滑这就是社区里著名的SKIP LOCKED 队列死亡螺旋。下面的对比图来自仓库内置的 xmin-horizon 基准测试当 xmin 被人为持有时图中红色区间SKIP LOCKED 队列的死元组直线攀升而 PgQue 全程保持在 0。这不是理论推演。实测数据Postgres 174 生产者 4 消费者800 事务/秒场景SKIP LOCKED 队列PgQue死元组xmin 被持有时91,593约 14 倍增长0出队吞吐下降约 35%基本不变完整复现脚本和原始数据都提交在 benchmark/xmin-horizon/ 目录可以照着在自己硬件上跑。PgQue 是什么1 个 SQL 文件装进任何 PostgresPgQue 源自 Skype 2006 年为数亿用户打造消息系统的PgQ 引擎运行了十余年但原版依赖 C 扩展pgq和外部守护进程pgqd——这两样在托管 Postgres 上都装不了。PgQue 的解法简单粗暴用纯 SQL PL/pgSQL 重写整个引擎安装文件只有 7 千多行。✅免 C 扩展不需要编译、不需要shared_preload_libraries、不需要重启数据库✅托管就绪RDS、Aurora、Cloud SQL、AlloyDB、Supabase、Neon 等都能直接跑✅真正的 Postgres 保证ACID 事务、WAL、备份、复制事件就在你现有数据库里✅语言无关任何能连 Postgres 的语言都能用官方还提供 Python、Go、TypeScript 客户端库零膨胀的秘密快照分批 TRUNCATE 轮换理解 PgQue 只需要两个概念1. 快照分批snapshot batching——不锁行、不抢行每次心跳tick默认每 100 ms 一次都会记录一个 Postgres 快照。一个批次 相邻两次快照的差集哪些事件是这 100 毫秒内新提交的就发给消费者。因为是否入批完全由事务可见性决定热路径上没有行锁、没有逐行删除天然支持多个消费者并行读取同一条日志。2. TRUNCATE 轮换——空间回收不靠 VACUUM每条队列由 3 个子表轮换承载事件。旧事件不是被删掉的而是整表TRUNCATE后复用——TRUNCATE 一次性释放存储不留死元组因此 xmin 水位被钉住也影响不到队列。这也是 PgQue 对死亡螺旋免疫的结构性原因。代价是端到端投递延迟约等于半个 tick 周期默认 100 ms tick实测中位约 52 ms且该延迟不随负载增长。如果你的业务要求个位数毫秒的调度PgQue 不是最佳选择如果优先追求高负载下的稳定与不膨胀它正中靶心。详见 docs/latency-and-tuning.md。三步安装单文件 SQL pg_cron 心跳要求Postgres 14以及一个能周期性调用pgque.ticker()的东西推荐 pg_cron。第 1 步获取代码git clone https://gitcode.com/gh_mirrors/pg/PgQue cd PgQue第 2 步在 psql 里单事务执行唯一的安装文件 sql/pgque.sqlbegin; \i sql/pgque.sql commit;第 3 步让队列跳动起来有 pg_cron 时一条命令注册全部维护任务select pgque.start();装完之后生产者/消费者只面对一个极简的 SQL APIselect pgque.create_queue(orders); select pgque.subscribe(orders, processor); select pgque.send(orders, {order_id: 42}::jsonb); select * from pgque.receive(orders, processor, 100); select pgque.ack(1); -- 用上一步返回的 batch_id⚠️ 一个关键操作习惯发送和 tick 必须在不同事务里——这是快照设计的硬性要求同一个事务里提交的事件对那次快照不可见。平时由 pg_cron 驱动 ticker你完全不用操心。完整的动手教程见 docs/tutorial.md安装、权限角色pgque_reader/pgque_writer/pgque_admin、升级与卸载的运维细节见 docs/installation.md。原生 Fan-out 与合作消费者加 worker 就能线性提速PgQue 的模型更接近 Kafka 的 topic 而不是任务队列一条共享事件日志每个消费者持有自己的游标各自独立地收到所有事件——数据只存一份却能让审计、通知、分析三个子系统各自消费这就是免费的 fan-out。更实用的是合作消费者subconsumers0.2 版实验特性当下游处理很慢比如每发一封邮件要调一次外部 API时一个主消费者把批次分给 N 个子消费者并行消化。下图是同一份 160 条积压、每条固定 250 ms 处理的排水比赛worker 从 1 个加到 16 个排水时间从 40.4 秒压到 2.6 秒。对应的吞吐量几乎是线性扩展的16 个 worker 时达到理想值的 96.5%这套主消费者 worker 池的模式无需第二套队列源码与基准脚本见 benchmark/subconsumer-scaling/。PgQue 与其他 Postgres 队列怎么选能力PgQuePgQPGMQRiverQuepg-boss快照分批无行锁✅✅❌❌❌❌持续负载下零膨胀✅✅❌❌❌❌纯 SQL 安装、托管可用✅❌✅✅✅✅语言无关的 SQL API✅✅✅❌❌❌共享日志 Fan-out✅✅❌❌❌⚠️内置重试 死信队列✅⚠️⚠️⚠️❌✅一句话总结River / Que / pg-boss 本质是任务队列框架还要跑一个 Go/Ruby/Node workerPgQue 是事件/消息队列——共享日志 独立游标热路径零死元组。选 PgQue 的场景事件驱动的 fan-out一个事件给多个子系统不想再引入 Kafka / RabbitMQ只想用好手里已有的 Postgres托管 Postgres 环境装不了 C 扩展、跑不了守护进程高吞吐、长稳运行不想为 VACUUM 调参焦虑选任务队列的场景需要单任务生命周期、优先级、cron 调度、唯一任务或追求个位数毫秒级调度延迟。总结PgQue 把三件事做到极致零膨胀TRUNCATE 轮换热路径零死元组对 xmin 钉住免疫、单文件安装一个 SQL 文件 pgque.start()完事、免 C 扩展纯 PL/pgSQL托管 Postgres 随处可跑。内核来自 Skype 十余年生产验证的 PgQ上层是全新的send / receive / ackAPI 和四语言客户端。想继续深入概念与术语表tick / batch / rotationdocs/concepts.md完整函数与角色参考docs/reference.md监控与健康检查docs/monitoring.md官方规范blueprints/SPECx.md赞分享【免费下载链接】PgQuePgQue – Zero-bloat Postgres queue built on top of on battle-proven Skypes PgQ. One SQL file to install, pg_cron to tick https://pgque.dev项目地址https://gitcode.com/gh_mirrors/pg/PgQue点击查看免费下载相关推荐为什么BullMQRedis是构建现代消息队列的终极选择超越传统代理的5大优势为什么BullMQRedis是构建现代消息队列的终极选择超越传统代理的5大优势 在分布式系统架构中消息队列扮演着至关重要的角色负责协调不同服务间的通信与后端消息队列任务调度为什么 PgQue 永不膨胀揭秘 TRUNCATE 轮转 快照批处理如何消灭死元组为什么 PgQue 永不膨胀揭秘 TRUNCATE 轮转 快照批处理如何消灭死元组 PgQue 是一个 零膨胀Zero bloat的 PostgresPgQue vs PGMQ vs River vs Que vs pg-boss2026 Postgres 消息队列终极横评PgQue vs PGMQ vs River vs Que vs pg boss2026 Postgres 消息队列终极横评 如果你在 2026 年为 Pos创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考