如果你写过 Postgres 的 LISTEN/NOTIFY，大概率听过一句忠告：这东西不能 生产环境慎用。

这个标签不是凭空来的。你看到过流行的 benchmark 显示它撑死了每秒 .9K 写入——对大部分后端场景确实不够看。

但 DBOS 团队用一套调整把这个数字推到了 60K 写入/秒延迟 -100ms。更值钱的是 Hacker News 上 多分的讨论，从多个角度挖出了幕后真相。

问题来了：60K/s 代表着 LISTEN/NOTIFY 真的「 了」吗？还是说藏着什么条件，

一、LISTEN/NOTIFY 的常见应用

-- 订阅端
LISTEN channel_name;-- 发布端
NOTIFY channel_name,'payload';

NOTIFY 不是在调用时立即发送，而是在 事务提交之后 才发出。事务回滚→通知不发，保证了事务一致性。典型用途的观点是，

二、全局锁：.9K/s 的罪魁祸首

-- naive 实现：每行 insert 都 NOTIFY
CREATE FUNCTION notify_stream_chunk
RETURNS trigger AS $$
BEGIN
PERFORM pg_notify;RETURN NEW，END;$$ LANGUAGE plpgsql;

DBOS 最初就是这样做的，接下来发现无论你怎么调参数。吞吐始终卡在 .9K/s但 CPU、内存、IOPS 全部没有负载。

根因这方面，NOTIFY 的事务提交需要拿全局排它锁。持有到 fsync 完成才释放。

为什么要有这个锁？ 因为 PG 需要保证通知按事务提交顺序发送。但「提交顺序」在提交完成后才能确定。话说回来，PG 的解法是用锁串行化所有含 NOTIFY 的提交。其实，结果就是 group commit 不工作了每个 fsync 都变成了一场串行等待。：Postgres 新 patch 不解决这个问题——它调整的是多 channel 情况下 listener 唤醒效率，全局锁依然存在。

{ "naive throughput": ".9K writes/second","bottleneck": "LWLock:NotifyQueueLock ","consequence": "group commit disabled,each commit serializes fsync"。"PG patch": "only improves multi-channel scenarios,global lock remains"}

再看主要洞察点，NOTIFY 是信号而不是实际数据。在缓存失效场景中客户端会根据通知去查询最新数据 - 虽然可能会漏掉一个通知但在下一次轮询时仍能获取更新。

可以采取以下改进：

第一步先的观点是。内存缓冲区 不要直接NOTIFY而是将通知暂存在内存队列中

说到接下来，批量刷新 由后台线程每50ms将缓冲区内容一次性flush出来。怎么说呢，这样全局锁只需要在刷新期间获取一次。

:降级轮询 除了监听，读者还需要每秒进行一次轮询以防止由于进程崩溃导致通知丢失。

python

notify_buffer =

def flushnotifybuffer: if not notifybuffer: return ids = notifybuffer notify_buffer.clear db.execute"。)

还有其他关键考虑因素:

进程崩溃导致通知丢失: 每秒轮询降级策略对于某些业务场景来说无法接受li慢读者会阻塞所有channel: 全局队列共享代表着一个低效使用者会影响整个程序liPayload大小限制: 不适合传输较大消息li复杂度增加: buffer + timer + polling fallback需要维护约百行代码量相当于引入Redis组件ul

HN上有人表示：「我曾经在生产环境使用过该功能高负载情况下确实发生过消息丢失。」另一人补充道：「看到这些调整代码第一反应就是这怎么调试?，"