Postgres LISTEN/NOTIFY 可擴展性分析

Postgres LISTEN/NOTIFY 可擴展至每秒 60k 則訊息

Postgres LISTEN/NOTIFY 能處理多達 60,000 則訊息每秒，挑戰了該功能無法擴展的常見業界敘事。儘管常被視為低流量訊號的工具，但基準測試顯示，在適當的硬體與配置下，它可以作為高吞吐量通知系統使用，無需外部訊息代理。

高效能的 LISTEN/NOTIFY 基準測試高度依賴於底層基礎設施。要達到 60k msg/s 需要顯著的垂直擴展。一項基準測試使用了一台擁有 96 個核心和 384 GB RAM 的資料庫伺服器，說明這些結果並非普通硬體上的預設設定所能代表。

關鍵效能因素包括：

儘管其在吞吐量方面具有可擴展性，LISTEN/NOTIFY 具備固有的架構限制，可能使其不適合某些使用情況：

Payload Size Limit：通知資料有一個硬性限制為 8,000 個位元組。如果通知所需的資料超過此限制，系統必須將資料存儲在表格中，並僅透過 NOTIFY 傳送列 ID。
Disk Contention：使用 LISTEN/NOTIFY 建立自訂佇列可能導致嚴重的磁碟競爭，以及在底層表格上出現問題的 vacuum 執行，特別是在像 AWS RDS 這樣的受管理服務上。
Operational Complexity：在 Postgres 內部之上實作複雜的佇列語義可能被工程團隊視為 "scary" 或非標準，這使得維護和擁有權相比使用專用工具如 SQS 或 Redis 變得更加困難。

業界對「擴展」的觀點各有不同，有人主張擴展是一個連續體而非二元對立。對許多應用來說，LISTEN/NOTIFY 的上限已經足夠，主要優勢是避免管理額外服務所帶來的「DevOps 稅」。

"LISTEN/NOTIFY 的上限夠小，需要你注意，但對許多專案而言仍然足夠，而且與資料庫其餘部分的整合、其可用性、以及它不是你必須進行 devops 的另一項服務，這絕對不該被簡單地作為一個選項而直接否定。"

相反地，其他人則認為，對於需要極端擴展或容易發生巨大流量突發的系統，關聯式資料庫通知系統的固有限制相比於專用訊息代理來說風險過高。