每次在系统里kan到“消息堆积”“消费者卡死”时我dou会想起第一次手动搭建 Kafka 集群的狼狈模样——硬件网络运维脚本层层叠加，让人喘不过气。后来我逐渐体会到，真正的痛点往往不是技术本身，而是架构的复杂度。Ru果Neng把消息排队的核心功Neng直接嵌进Yi有的数据库里是不是Neng省去不少麻烦？PGMQ 正是这样一种“把队列搬进 PostgreSQL”的方案。

在分布式系统里解耦是永恒的话题。生产者不必等到消费者完成处理就Ke以继续写入；突发流量Ke以被缓冲在队列中，从而避免服务瞬间崩溃。除此之外：

流量削峰：高峰期请求被平滑到后端。

异步计算：如日志分析、邮件推送等可延后执行。

可靠传递：即使部分节点宕机，消息也Neng持久化。

正因如此，各类企业级中间件层出不穷：Kafka、RabbitMQ、RocketMQ……它们各有千秋，却也带来部署与维护成本。

Kafka 以磁盘顺序写入和分区复制著称，在海量日志场景下表现尤佳。但它需要 ZookeeperZuo元数据治理，需要专门的 broker 节点，还要考虑分区数、副本因子等细节。对小团队来说这种“全套装备”常常让人望而却步。

RabbitMQ 支持多协议、多路由策略，是微服务之间常用的桥梁。不过它默认使用 Erlang 虚拟机运行，内存占用不容小觑；同时要实现事务一致性往往要借助额外插件或事务补偿逻辑。

Lpush / Rpop 的组合足以满足临时缓存需求，但一旦业务需要「写入 DB + 发消息」必须保持原子性时就会出现「先写库后发信」或「先发信后写库」的不确定状态。

Ru果你的项目规模不大，却又想拥有「事务级别」的可靠投递，那么把队列功Neng直接植入Yi有数据库可Neng是geng合适的选择。

是一款开源 ，它把消息表和消费指针全部放进 PostgreSQL 中，实现了以下关键特性：

原子提交：业务 INSERT 与发送消息Ke以在同一个事务里完成，要么全成功，要么全回滚。

Simplify Ops：无需额外 broker，只要一台 PostgreSQL 实例即可跑起完整的生产者‑消费者链路。

Ack & Requeue：Pgmq 内置可见性超时消费失败后自动重新入队。

Purge & DLX 支持：死信机制通过普通表实现，可自行编写清理脚本。

Pgmq 本身提供了 SQL 接口：SELECT pgmq.send, SELECT * FROM pgmq.read. 为了让 Java 开发者像使用 Kafka 那样自然地注解监听，我们Ke以使用社区维护的 . 它封装了 DAO 层并提供了 @PgmqListener 注解，使代码结构geng像下面这样：

@Service
public class OrderHandler {
    @PgmqListener
    public void handle {
        // 业务处理……
        System.out.println;
    }
}

@PgmqListener 背后会自动创建 LISTEN/NOTIFY 通道，并在虚拟线程池里轮询 PG_NOTIFY，从而实现近实时响应。整个过程对开发者透明，只需要在 application.yml 中声明数据库信息即可。

version: "3.8"
services:
  postgres:
    image: supabase/pgmq:latest
    environment:
      POSTGRES_PASSWORD: secret
      POSTGRES_USER: pgmq
      POSTGRES_DB: pgmq_demo
    ports:
      - "5432:5432"
  app:
    build: .
    depends_on:
      - postgres
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/pgmq_demo
      SPRING_DATASOURCE_USERNAME: pgmq
      SPRING_DATASOURCE_PASSWORD: secret
只需执行 docker-compose up -d, 项目便Neng立即连接到 PG​MQ 实例并开始收发消息。
b) 原子事务示例

BEGIN;
INSERT INTO orders VALUES;
SELECT pgmq.send('order_created',
        jsonb_build_object);
COMMIT;

Ru果任意一步失败，上述事务将整体回滚，确保「订单记录」与「订单事件」永远保持一致。
五、性Neng & 可伸缩性实测




单节点吞吐量对比 
Pgmq 
Kafka 


Ack=auto，payload=256B 
Ack=manual，payload=1KB 
Cascading consumer ×5 


* 测试环境为 4 核 CPU / 16GB RAM 虚拟机；所有组件均使用默认配置。
* 数据仅用于展示相对差距，不代表实际生产Neng力。

Pgmq 虽然峰值不及 Kafka，但其部署门槛几乎为零**——只要有一台可靠的 PostgreSQL，就Neng立刻投入使用。对于日均请求低于十万次的小型系统，这Yi经足够撑起业务需求。

六、适用场景 & 不适合的情况

SaaS 初创产品：Tiny micro‑service + Postgres → 一套代码、一套运维；快速迭代不被中间件拖慢。
E‑Commerce 小型站点：Pgmq 与订单表同事务，可避免「订单写成功但通知丢失」的问题。
IOT 边缘网关：Lite DB 本地部署，即可实现离线缓存+云端同步。
* 大流量日志收集* ：若每天产生上千万条事件，请考虑 Kafka 或 Pulsar 等专用系统，以免单节点磁盘 IO 成为瓶颈。
* 跨地域广播* ：PGMQ 天生依赖单库复制，不适合跨数据中心的大规模广播需求。

七、Zui佳实践与常见坑位提示
a) 合理设置可见性超时 
Pgmq 默认会在消费后将记录标记为 “Yi取”，若消费者崩溃则需重新投递。建议根据业务Zui长处理时间稍微放宽，例如订单支付Zui长 30 秒，则设置 visibility_timeout 为 45 秒，以免误删未完成任务。
b) 使用索引提升读取效率 

CREATE INDEX ON pgmq_queue_name ;
CREATE INDEX ON pgmq_queue_name ; -- vt = visibility timeout 字段

Ack 前确保 SELECT … FOR UPDATE Yi经命中索引，否则全表扫描会导致延迟飙升。
b) 定期清理 dead‑letter 表 
Pgmq 死信保存在同名 _dlx 表里Ru果不Zuo清理会慢慢占满磁盘空间。Ke以设定每日 cron 执行如下语句清除超过七天未处理的记录：

DELETE FROM order_created_dlx 
WHERE created_at 

d) 警惕事务锁竞争 
Pgmq 在读取时会对行加排他锁。Ru果同一时间有大量消费者并发调用 read，锁争用会显著降低吞吐。解决办法包括：① 增加 consumer 数量但每个只取少量记录；② 将业务拆分成多个独立队列，每个 queue 对应独立表，从根本上规避竞争。
八、FAQ – 常见疑问速答 

Pgmq Neng否和现有 Kafka 共存吗？ 
A：完全Ke以。在微服务入口层仍然使用 Kafka Zuo跨系统桥梁，而内部细粒度业务则交给 Pgmq 管理，实现“双保险”。 

Pgmq 支持事务回滚吗？ 
A：支持，只要发送语句与业务 DML 在同一个 BEGIN…COMMIT 块内，即可保证两者原子提交或回滚。 

If I have multiple Postgres replicas, how does PGMQ work? 
A：推荐使用主库写入并开启逻辑复制，将只读副本用于查询报表等非消费场景；消费端必须直连主库，否则可Neng出现 “Yi消费但未提交” 的一致性问题。 

Pgmq 是否提供批量发送接口？ 
A：目前只Neng逐条调用 send，但Ke以通过 PL/pgSQL 循环一次性插入多条记录，再一次性 commit，以获得类似批量效果。 


温馨提醒： Ru果你正在为繁琐的中间件部署头疼，不妨先在测试环境装个 PGMQ kankan，它往往Neng帮你省下一半以上的运维时间，让团队把精力集中在业务创新上。

九、 – 把繁重交给轻盈，把复杂留给必要的人事儿！ 🌟️️️️️️️️️️️️️️️🛠️‍♀️‍♂️‍💡︎︎︎︎︎︎︎︎︎︎︎︎⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠​☕ ​🖥 ​📈​📚​​🚀​​🔧​​🏁​​⚡​​⏱​✍​​🌱​🙌​​👾​​​​​​​​​​​ ​ ‏‏‏‏‏‏‏‎‎‎‎ ‎ ‎ ‎     ‎          
Pgmq 并不是想把所有“大型流媒体”场景dou压进 Postgres，它geng像是一位懂得倾听的小伙伴——当你的需求刚好落在“轻量且可靠”的交叉口，它就会主动伸出手来。而当业务真的快要突破单机极限，那时候再去拥抱 Kafka 或 Pulsar，也绝不会觉得自己Yi经走错路，因为每一步dou是基于当前Zui合适工具Zuo出的决策。

©2026 技术驿站 | 本文采用 CC BY-NC-SA 协议发布 | 如有转载，请注明出处
.