【免费下载链接】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 消息队列一份 SQL 安装、pg_cron驱动 tick、纯 SQL PL/pgSQL 跑在任何 Postgres 14 上。它的名字背后是一个关键取舍——用等待下一个 tick的小延迟换来负载下不膨胀、延迟不漂移的稳定行为。这篇PgQue 延迟调优指南会讲清它端到端投递延迟的本质并手把手带你调小 tick 周期把 Postgres 消息队列的投递从默认约 100ms 级压到8ms。先看结论PgQue 的端到端延迟由tick 周期决定而不是由send/receive单次调用决定。默认 10 ticks/sec100ms时中位投递约 52ms一条set_tick_period_ms(10)就能把中位投递压到约 8ms。一、先分清三种延迟哪种才决定端到端投递队列延迟其实是三个数字混为一谈会把调优方向带偏。PgQue 中它们分别是#名称是什么量级瓶颈1生产者延迟send→ 落盘亚毫秒WAL 落盘、触发器2订阅者延迟对已建好的 batch 调next_batch亚毫秒如何定位下一批工作3端到端投递send→ 消费者可见≈ tick 周期ticker 的节奏可调真正决定你的应用体感SLA、重试时机、消息新鲜度的是#3 端到端投递。这里有个坑#3 的下限是 #1 #2但 #1、#2 再快也救不了 #3——决定 #3 的是 tick 节奏不是单次读写速度。你能把发送和读取都压到微秒级却仍可能因为ticker 还没触发而让用户等到上百毫秒。反过来不可能消息不可能比写完 读到更快地被消费者看见。完整拆解见 docs/latency-and-tuning.md。二、为什么端到端投递延迟 ≈ tick 周期PgQue 是tick 驱动的。消费者只有在一个 tick 创建了一个包含该事件的批次边界后才能看见它。每个 tick 存一份pg_snapshot一个批次 当前 tick 快照里可见、而上一份里不可见的事件集合。于是一条事件刚在一个 tick之后发出 → 要等几乎一个完整周期刚在下一个 tick之前发出 → 几乎不用等。按到达时间平均平均等待约是半个周期最坏约一个周期。这正是基准里看到的数字见 benchmark/tick-rate/默认 100ms tick 下中位投递 ~52ms≈周期/2最大约一个周期~105–145ms。三、一步压到 8ms调小 tick 周期PgQue 默认每秒 tick 10 次每 100ms。在运行时就能调改的是下一次调度槽≤1s生效无需重新start()select pgque.set_tick_period_ms(50); -- 20 ticks/sec select pgque.set_tick_period_ms(10); -- 100 ticks/sec → 中位 ~8ms select * from pgque.status(); -- 查看当前 tick 速率合法取值是 1000 的精确因子1..1000ms1, 2, 4, 5, 8, 10, 20, 25, 40, 50, 100, 125, 200, 250, 500, 1000。下面是已提交的 benchmark/tick-rate/bench.py 实测单台笔记本、Postgres 16、100 ev/s、每格 30stick_period_ms有效频率p50 端到端p95最大10001 tick/s~503ms~954ms~1004ms100默认10 ticks/s~52ms~99ms~105–145ms10100 ticks/s~8ms~264ms~1013ms11000 ticks/s~3ms~162ms~548ms怎么读这张表想把 100ms 级压到 8ms把周期设到10ms即可中位投递从 ~52ms 降到 ~8ms。别追求无脑设到 1ms中位确实更短但尾部会向 1 秒pg_cron 槽长膨胀——极短周期下内层循环未必能在一个 1 秒槽内跑完所有迭代偶尔会跳过 tick 窗口。短于 10ms 的周期属于特化场景请先在自己的硬件上压测再定。原始数据在 benchmark/tick-rate/results-baseline.json。四、调高 tick 率不是免费的四个隐藏代价更高 tick 率 用单位时间更多的工作换更低延迟。上生产前请对以下四项做自测更多 WAL每个实化的 tick 都会写 PgQue 元数据持续实化 tick 的队列WAL 按倍增长。空闲队列会退避不受影响。更多元数据 churnpgque.tick与pgque.subscription每次 tick 都被 UPDATE产生死元组。PgQue 靠轮转这些表控制峰值周期低于 50ms 时要同步调小轮转周期用pg_stat_user_tables盯着这两张表。更多 NOTIFY每次 tick 每个被 tick 的队列发一条pg_notify。NOTIFY 队列是全局 SLRU8GiB 上限慢的 LISTEN 消费者在极高 tick 率下可能追不上。每个槽占用一个 cron worker亚秒循环会占住一个pg_cron后台 worker 约 1 秒。单库无所谓当很多库共享一个集群的 cron worker 池时才需要留意。五、这个交换为什么值负载下延迟依旧稳定上面这些代价换到的是稳定性。对照 UPDATE/DELETESKIP LOCKED型队列它们的端到端延迟约等于消费者轮询间隔消费者在活跃轮询时亚毫秒返回看起来更快——但代价是每次 claim/ack 都产生死元组一旦遇到长事务、idle-in-transaction、落后的逻辑复制槽或开启hot_standby_feedback的备库autovacuum 收不了死元组队列表就膨胀并越跑越慢形成死亡螺旋。PgQue 走的是另一条路没有逐行的 claim / delete只有快照 diff 和基于 TRUNCATE 的表轮转热路径天然零膨胀、延迟不随运行时间漂移。所以——如果你要的是亚毫秒分发PgQue 可能不是最合适的工具但如果你要的是无膨胀压力下的稳定延迟tick 周期这点延迟正是它的价格。更多取舍见 docs/concepts.md。六、别漏掉消费者这一端轮询间隔与完成时间端到端 tick 等待消费者轮询间隔。上面的基准里消费者以 1ms 间隔紧循环轮询、不用 LISTEN/NOTIFY 唤醒所以数字反映的是纯 tick 路径。你的应用里消费者轮询越勤可感知投递就越贴近 tick 中位值反过来慢消费者会让可感知延迟再叠加自己的轮询周期。还有一个常被忽略的维度当下游处理才是瓶颈时每条消息要调一次邮件 API、发短信、发 webhook单消费者的吞吐会被这条每消息固定耗时卡死。PgQue 的协作式子消费者cooperative subconsumers0.2 中为实验特性能让吞吐与完成时间随并行度近似线性下降同一份 160 条积压1 个 worker 约 40s 完成第 160 条4 个约 10s16 个约 2.6s。tick 调优管消息多快被看见子消费者管看见后多快处理完两者叠加才是用户真正感知的总延迟。七、快速上手PgQue 延迟调优清单定位瓶颈先确认你优化的是 #3 端到端投递而不是单条send/receive它们本就亚毫秒。用select * from pgque.status();看当前 tick 速率。把默认 100ms 调到 10msselect pgque.set_tick_period_ms(10);中位投递从 ~52ms 降到 ~8ms≤1s 生效。别轻易低于 10ms短于 10ms 的尾部会膨胀先压测再定。按队列微调触发阈值仅当需要更激进的触发select pgque.set_queue_config(orders, ticker_max_lag, 1 second);若周期 50ms同步调小元数据轮转周期并用pg_stat_user_tables监控pgque.tick/pgque.subscription。测自己的硬件tick 率与 WAL/churn 的代价是定性的务必在真实负载上量pg_current_wal_lsn()差值。空闲队列不用管没事件时 ticker 基本返回空PgQue 会向ticker_idle_period默认 1 分钟退避静默队列很便宜。相关文件延迟与 tick 调优详解docs/latency-and-tuning.mdtick 率基准与复现脚本benchmark/tick-rate/、benchmark/tick-rate/bench.py安装仓库根目录\i sql/pgque.sqlsql/pgque.sql快照/轮转/膨胀机制docs/concepts.md生产环境读 tick lag 与 consumer lagdocs/monitoring.md函数参考set_tick_period_ms、set_queue_configdocs/reference.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点击查看免费下载相关推荐彻底掌握Rufus从硬件限制绕过到多系统启动盘制作的全能指南彻底掌握Rufus从硬件限制绕过到多系统启动盘制作的全能指南 在数字时代制作可启动USB驱动器已成为系统管理员、开发者和普通用户的必备技能。然而面对微软日桌面应用开发工具QMQ架构深度解析如何实现10ms端到端延迟的高性能消息队列QMQ架构深度解析如何实现10ms端到端延迟的高性能消息队列 QMQ是去哪儿网内部广泛使用的消息中间件自2012年诞生以来在所有业务场景中广泛应用包括跟交终极指南如何实现Aeron消息轨迹的端到端延迟监控终极指南如何实现Aeron消息轨迹的端到端延迟监控 在当今高性能计算领域 Aeron消息轨迹 的端到端延迟监控已成为确保系统可靠性的关键环节。Aeron作为消息队列后端通信创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考