Postgres LISTEN/NOTIFY 可扩展性分析
Postgres LISTEN/NOTIFY 可扩展性分析
Postgres LISTEN/NOTIFY 可扩展至每秒 60,000 条消息
Postgres LISTEN/NOTIFY 可以处理每秒多达 60,000 条消息，这挑战了该功能不可扩展的常见行业叙述。虽然常被视为低容量信号的工具被忽视，但基准测试表明，在适当的硬件和配置下，它可以作为高吞吐量通知系统，而无需外部消息代理。
硬件和配置依赖
高性能基准测试对于 LISTEN/NOTIFY 在很大程度上依赖于底层基础设施。要实现每秒 60,000 条消息，需要显著的垂直扩展。一个基准测试使用了具有 96 核心和 384 GB 内存的数据库服务器，说明这些结果并不代表普通硬件上的默认设置。
关键性能因素包括：
- 垂直扩展：高核心数量和高内存是达到峰值吞吐量所必需的。
- 连接管理：发起请求的连接的位置和数量对整体延迟有显著影响。
- 批处理：当客户端批量处理命令以摊薄每请求成本时，吞吐量会得到提升。
技术约束和限制
尽管在吞吐量方面具有可扩展性，LISTEN/NOTIFY 具有一些固有的架构限制，可能使其不适用于某些用例：
- 有效载荷大小限制：通知数据的硬性限制为 8,000 字节。如果通知需要的数据超过此限制，则系统必须将数据存储在表中，并仅通过
NOTIFY发送行 ID。 - 磁盘竞争：使用
LISTEN/NOTIFY构建自定义队列可能导致底层表出现严重的磁盘竞争和问题真空运行，尤其是在像 AWS RDS 这样的托管服务上。 - 运营复杂性：在 Postgres 内部之上实现复杂的队列语义可能被工程团队视为“可怕”或非标准，相比使用专用工具如 SQS 或 Redis，维护和所有权会更加困难。
关于扩展的比较视角
行业对“扩展”的看法各不相同，有人认为扩展是一个连续体而非二元选择。对于许多应用程序，LISTEN/NOTIFY 的上限已经足够，主要优势在于避免管理额外服务所带来的“DevOps税”。
"
LISTEN/NOTIFY的上限足够小，需要你关注，但对于许多项目来说仍然足够充足，并且与数据库其余部分的集成、其可用性以及它不是你必须运维的另一个服务这一点，它绝对不应该被简单地作为一种选择而直接否定。"
相反，其他人认为，对于需要极端可扩展性或容易发生巨大流量突发的系统来说，关系型数据库通知系统的固有限制相比专用消息代理来说风险太高。
权衡摘要
| 特性 | LISTEN/NOTIFY | Dedicated Message Broker (SQS/Redis) |
|---|---|---|
| 基础设施 | 集成在 Postgres 中 | 独立服务 |
| 一致性 | 与 DB 数据强一致 | 最终一致性（通常） |
| 复杂性 | 初始设置低，自定义队列复杂度高 | 初始设置较高，队列的运营复杂度较低 |
| 有效载荷限制 | 8,000 bytes | 显著更大 |
| 扩展路径 | 垂直（更大的服务器） | 水平（集群/分布式） |
SUMMARY: 对 Postgres LISTEN/NOTIFY 可扩展性的分析，突出其处理每秒 60,000 条消息的能力，同时指出诸如有效载荷限制和硬件依赖等关键约束。
TITLE: Postgres LISTEN/NOTIFY 可扩展性分析