作者：林岚｜OC 技术与安全编辑

DBOS 公布了一项 PostgreSQL 通知性能实验：直接在每次写入时调用 NOTIFY，吞吐量停在每秒约 2900 次；把通知先缓存在应用内存中再批量发送后，同一服务器达到每秒约 6 万次写入，延迟约为 15 至 100 毫秒。

一句话结论：提升来自应用层绕开每次提交都争抢全局通知锁，而不是 PostgreSQL 原生 LISTEN/NOTIFY 本身突然快了 20 倍。

LISTEN/NOTIFY 很适合告诉订阅者“有新数据”，但它不是消息队列。按照 PostgreSQL 文档，通知要等事务提交后才会送达，实际数据仍应保存在表中。DBOS 的场景正是如此：表是事实来源，通知只负责唤醒等待读取的工作进程。

瓶颈出现在高并发写入。每个事务调用 NOTIFY 时，都要争抢共享通知队列相关的全局排他锁，而且锁会一直持有到提交和刷盘完成。并发连接越多，等待越严重，最终把数据库变成串行发送通知。

DBOS 的方案是在进程内合并短时间窗口内的通知，再由少量事务批量发送。这样，数十次甚至数百次写入可以共享一次锁获取和提交成本。为了处理进程在缓冲区尚未发送时崩溃的情况，消费者还会低频轮询数据表，补回可能丢失的唤醒信号。

这个取舍很明确：通知不再被当成完全耐久、有严格顺序的消息；可靠性来自数据库表和轮询兜底。实验的每秒 6 万次也只代表特定服务器、负载和实现，不是所有 PostgreSQL 部署的保证。

PostgreSQL 19 正在改进多频道监听等场景，但 DBOS 指出，相关补丁没有消除这项全局锁。因此，对需要极高事件吞吐的系统，当前更现实的办法仍是减少 NOTIFY 次数，或者使用专门消息系统。

关键事实

• 来源：DBOS、PostgreSQL 官方文档、公开基准仓库
• 核心瓶颈：每次事务通知争抢共享队列的全局排他锁
• 优化方法：内存缓冲、批量通知、数据库表作为事实来源、轮询兜底
• 关键数字：直接通知约 2900 次/秒；实验优化后约 6 万次/秒

OC 判断

这是一个“语义换性能”的工程案例。只要业务真正需要的是低延迟唤醒，而不是持久消息队列，就可以合并通知；如果业务要求每条消息严格不丢不乱，就不该用这个结果证明 LISTEN/NOTIFY 足以替代 Kafka。

为什么重要

• 对开发者：先确认通知是事实还是提示，再决定能否批量和丢失后补偿。
• 对企业：简单的 PostgreSQL 架构可以承担更大负载，但必须保留可恢复的数据源。
• 对用户：性能改善来自减少协调开销，通常能降低后台任务排队时间。

参考来源

• DBOS：Scaling Postgres LISTEN/NOTIFY
• GitHub：DBOS Postgres benchmark
• PostgreSQL：NOTIFY