什么是 LISTEN 和 NOTIFY？

Question

Accepted Answer

**`LISTEN`** 和 **`NOTIFY`** 在 PostgreSQL 中提供了一个内置的**发布/订阅**消息系统——一个会话可以在通道上发送通知，其他在该通道上监听的会话会立即收到。这是从数据库推送实时事件而无需轮询的轻量级方式。

## 基本机制

```sql
-- a session SUBSCRIBES to a channel
LISTEN order_created;

-- another session/transaction PUBLISHES a notification (with an optional payload)
NOTIFY order_created, 'order id 123';
-- → all sessions listening on 'order_created' receive the message immediately
```

LISTEN 订阅一个通道；NOTIFY 向其发布（具有可选的文本有效负载）。监听器异步获得通知——无需轮询。

## 自动触发 NOTIFY（常见模式）

```sql
-- a trigger that notifies whenever a row is inserted
CREATE FUNCTION notify_new_order() RETURNS trigger AS $$
BEGIN
  PERFORM pg_notify('order_created', NEW.id::text);   -- notify with the new id
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER order_notify AFTER INSERT ON orders
  FOR EACH ROW EXECUTE FUNCTION notify_new_order();
-- now inserting an order automatically pushes a notification to listeners
```

将 NOTIFY 与**触发器**结合，数据库可以在数据变化时（新订单、状态更新）自动推送事件——监听该通道的应用服务器实时做出反应。

## 应用程序如何使用

```text
Application code (Node, Python, etc.) opens a connection and LISTENs on a channel.
When a NOTIFY fires (e.g. from a trigger on data change), the app receives the event
and reacts — pushing to websockets, invalidating a cache, triggering a job, etc.
→ Real-time reactions to database changes WITHOUT polling the database.
```

## 需要了解的限制

```text
✗ Notifications are NOT persisted — if no one is listening, the message is LOST
  (no durability/queue guarantees like a real message broker)
✗ Payload is small (limited size); delivered only after the transaction COMMITS
→ Good for lightweight real-time signaling; for durable/reliable messaging use a
  proper broker (RabbitMQ, Kafka) or a queue table.
```

## 为什么这很重要

`LISTEN`/`NOTIFY` 是一个有用的、相对鲜为人知的 PostgreSQL 功能，提供**内置的发布/订阅消息系统**，对于在没有轮询的情况下为应用程序增加**实时反应性**很有价值。

核心价值在于使数据库能够在事情发生时（新订单、状态变化）**立即将事件推送**给监听的应用会话——通常与**触发器**结合，以便数据变化自动通知监听器，应用服务器做出反应（推送到 websockets、使缓存失效、触发后台工作）。

这很有价值，因为它提供了真正的实时事件驱动行为，避免了反复**轮询**数据库检查变化的低效率（这是一种常见且浪费的模式，LISTEN/NOTIFY 可以优雅地取代）。

理解机制（订阅的 LISTEN、发布的 NOTIFY、数据变化时自动通知的触发器）以及应用程序如何使用它（监听事件以驱动实时反应）对于构建响应式的、事件驱动的应用程序很有用。

同样重要的是了解**限制**：通知**不被持久化**（如果没有人监听则丢失——无持久性保证）、有效负载较小、且仅在提交后触发——因此适合轻量级实时信号传递，*而非*可靠消息代理（RabbitMQ、Kafka）的替代品（当可靠性和持久性重要时）。

由于实时反应性是常见需求，而 LISTEN/NOTIFY 为轻量级情况提供了内置的、无轮询的方式实现它，因此理解它——发布/订阅机制、触发器模式，以及至关重要的其限制（何时足够 vs 何时需要真实代理）——对于构建事件驱动的应用程序是有价值的、实际相关的 PostgreSQL 知识，是一个有用的、常被忽视的内置功能。