长期以来，PostgreSQL的LISTEN/NOTIFY机制在数据库社区中一直处于一个微妙的位置：它被设计为轻量级的异步事件通知工具，但在生产环境中，许多人认为它无法在真正的高并发、高吞吐场景下胜任。这种担忧并非空穴来风——过去不少用户抱怨在高连接数或高频通知时遭遇性能瓶颈。然而，最新的工程实践和基准测试表明，只要正确使用和调优，Postgres LISTEN/NOTIFY不仅能够扩展，而且可以成为构建实时应用、事件驱动架构和微服务通信的可靠基石。
被低估的“轻量级”机制
LISTEN/NOTIFY是PostgreSQL内置的发布-订阅实现。一个客户端通过LISTEN channel注册对某个通道的兴趣，另一个客户端通过NOTIFY channel, 'payload'发送通知。PostgreSQL的异步通知机制通过libpq的PQnotifies()或JDBC的getNotifications()轮询获取。由于它不依赖外部消息队列，仅需数据库连接即可工作，因此对团队而言极具吸引力——无需引入RabbitMQ、Redis或Kafka等额外组件，就能实现简单的事件广播。
但历史上，扩展性问题主要源于两个方面：一是每个连接都需要持续轮询通知，当并发连接数达到数千甚至上万时，连接管理的开销变得显著；二是NOTIFY操作本身会持有锁，在多会话并发发送通知时可能产生争用。此外，传统的notify-payload最多只能承载8000字节，也限制了复杂消息的传递。
打破神话：实际扩展的关键实践
最近多个社区用户和数据库工程团队重新审视了LISTEN/NOTIFY的极限。经过系统性测试，他们发现：问题不在于机制本身，而在于使用模式。
首先，连接池的合理利用是扩展的第一步。传统的思路是每个监听者持有一个独占连接，这在小型应用中可行，但在大型系统中会导致连接数暴增。现代实践推荐使用连接池（如PgBouncer）配合事务级或会话级别的监听管理：监听者在短暂连接中建立监听，然后回到池中等待。当通知到达时，连接池可以快速分配连接给对应的监听进程。这消除了“每个监听一个连接”的僵化模式。
其次，通道设计至关重要。将全局唯一的大通道拆分为多个逻辑通道，能够显著降低锁争用。例如，按业务模块（“order_created”“user_loggedin”）甚至按用户分片。并发通知分散在不同通道上，避免了全局锁的热点。
第三，批量处理和异步消费可以大幅提升吞吐。监听者端不应在收到每个通知时立即执行重量级操作，而应缓冲一段时间或积累一定数量后批量处理。结合PostgreSQL的pg_notify函数和listen_timeout参数，可以设计出高效的批处理循环。
性能数据说话
在最近的基准测试中（测试环境为PostgreSQL 16，4核CPU，16GB内存），使用了300个并发监听连接，每个监听连接通过连接池重用，并分拆为10个通道。结果在80个会话持续发送通知时，系统稳定维持了每秒约12万条通知的吞吐量，平均延迟低于2毫秒。当继续提升发送并发到200个时，吞吐量仍可达到约8万条/秒，且没有出现明显的锁冲突或连接饥饿。这远高于大多数中小型系统的需求，证明LISTEN/NOTIFY完全可以支持中等规模的实时事件总线。
更令人鼓舞的是，PostgreSQL社区在版本15和16中优化了NOTIFY相关的锁机制，减少了WaitEventSet的唤醒开销，使得高并发场景下的CPU占用率降低了约30%。
适用场景与注意事项
当然，LISTEN/NOTIFY并非万能。它不适合需要消息持久化、严格投递保证（至少一次、恰好一次）或超大消息负载的场景。对于超过8000字节的负载，推荐将消息ID存储在payload中，完整数据异步写入表中。此外，跨数据库实例的通知需要借助触发器外部代理，因为LISTEN/NOTIFY默认不跨节点。
但在以下场景中，它正变得越来越可靠： - 实时仪表盘和数据刷新：无需轮询数据库，只需监听变更表。 - 缓存失效：当数据变更时通知缓存服务清除旧条目。 - 微服务之间的简单协调：发布订单状态变更、用户操作事件。 - 分布式锁或者工作队列：利用NOTIFY唤醒等待作业的工作进程。
结语
LISTEN/NOTIFY不再是那个“只能跑跑Demo”的特性。随着PostgreSQL自身的持续优化和开发模式趋于成熟，它已经展现出令人惊喜的扩展能力。对于追求简单、降低运维成本的团队而言，这意味着可以少引入一个消息中间件，而完全依靠数据库本身的原生能力构建实时响应系统。当然，正确的设计模式是实现可扩展的关键——这恰恰是数据库系统工程中永恒的主题：工具没有好坏，只有用得对错。
当下一轮系统设计中，考虑一下Postgres的通道吧——它可能比你想象的更能打。