LISTEN và NOTIFY là gì?

Question

Accepted Answer

**`LISTEN`** và **`NOTIFY`** cung cấp một hệ thống nhắn tin **publish/subscribe** tích hợp sẵn trong PostgreSQL — một session có thể gửi một notification trên một channel, và các session khác đang listen trên channel đó nhận được nó ngay lập tức. Đây là một cách nhẹ nhàng để đẩy các sự kiện thời gian thực từ cơ sở dữ liệu mà không cần polling.

## Cơ chế cơ bản

```sql
-- một session SUBSCRIBE vào một channel
LISTEN order_created;

-- một session/transaction khác PUBLISH một notification (với payload tùy chọn)
NOTIFY order_created, 'order id 123';
-- → tất cả các session đang listen trên 'order_created' nhận được message ngay lập tức
```

LISTEN subscribe vào một channel; NOTIFY publish lên nó (với một payload text tùy chọn). Các listener được thông báo bất đồng bộ — không cần polling.

## Tự động kích hoạt NOTIFY (một pattern phổ biến)

```sql
-- một trigger thông báo mỗi khi một dòng được insert
CREATE FUNCTION notify_new_order() RETURNS trigger AS $$
BEGIN
  PERFORM pg_notify('order_created', NEW.id::text);   -- thông báo kèm id mới
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER order_notify AFTER INSERT ON orders
  FOR EACH ROW EXECUTE FUNCTION notify_new_order();
-- giờ đây việc insert một order tự động đẩy một notification đến các listener
```

Kết hợp NOTIFY với một **trigger** cho phép cơ sở dữ liệu tự động đẩy sự kiện khi dữ liệu thay đổi (order mới, cập nhật trạng thái) — các application server đang listen trên channel phản ứng theo thời gian thực.

## Cách các ứng dụng sử dụng nó

```text
Mã ứng dụng (Node, Python, v.v.) mở một kết nối và LISTEN trên một channel.
Khi một NOTIFY kích hoạt (ví dụ từ một trigger khi dữ liệu thay đổi), app nhận được sự kiện
và phản ứng — đẩy đến websockets, vô hiệu hóa cache, kích hoạt một job, v.v.
→ Phản ứng thời gian thực với các thay đổi cơ sở dữ liệu KHÔNG cần polling cơ sở dữ liệu.
```

## Các hạn chế cần biết

```text
✗ Notification KHÔNG được lưu trữ bền — nếu không ai đang listen, message bị MẤT
  (không có đảm bảo độ bền/queue như một message broker thực thụ)
✗ Payload nhỏ (kích thước giới hạn); chỉ được gửi sau khi transaction COMMIT
→ Tốt cho tín hiệu thời gian thực nhẹ; với nhắn tin bền/đáng tin cậy hãy dùng một
  broker đúng nghĩa (RabbitMQ, Kafka) hoặc một bảng queue.
```

## Tại sao điều này quan trọng

`LISTEN`/`NOTIFY` là một tính năng PostgreSQL hữu ích, có phần ít được biết đến, cung cấp **nhắn tin pub/sub tích hợp sẵn**, có giá trị để thêm **tính phản ứng thời gian thực** cho các ứng dụng mà không cần polling.

Giá trị cốt lõi là cho phép cơ sở dữ liệu **đẩy sự kiện** đến các session ứng dụng đang listen ngay lập tức khi có điều gì đó xảy ra (một order mới, một thay đổi trạng thái) — thường được kết hợp với **trigger** để các thay đổi dữ liệu tự động thông báo cho các listener, mà các application server phản ứng theo (đẩy đến websockets, vô hiệu hóa cache, kích hoạt công việc nền).

Điều này có giá trị vì nó mang lại hành vi hướng sự kiện theo thời gian thực mà không có sự kém hiệu quả của việc **polling** cơ sở dữ liệu lặp đi lặp lại để kiểm tra thay đổi (một pattern phổ biến, lãng phí mà LISTEN/NOTIFY thay thế một cách thanh lịch).

Hiểu cơ chế (LISTEN để subscribe, NOTIFY để publish, với trigger để tự động thông báo khi dữ liệu thay đổi) và cách các ứng dụng sử dụng nó (listen sự kiện để dẫn dắt phản ứng thời gian thực) là hữu ích cho việc xây dựng các ứng dụng phản hồi nhanh, hướng sự kiện chỉ với PostgreSQL.

Cũng quan trọng không kém là biết các **hạn chế**: notification **không được lưu trữ bền** (mất nếu không ai đang listen — không có đảm bảo độ bền), có payload nhỏ, và chỉ kích hoạt sau khi commit — nên nó phù hợp với tín hiệu thời gian thực nhẹ, *không phải* sự thay thế cho một message broker bền (RabbitMQ, Kafka) khi độ tin cậy và độ bền quan trọng.

Vì tính phản ứng thời gian thực là một nhu cầu phổ biến và LISTEN/NOTIFY mang lại một cách tích hợp sẵn, không cần polling để đạt được nó cho các trường hợp nhẹ, nên hiểu nó — cơ chế pub/sub, pattern trigger, và quan trọng nhất là các hạn chế của nó (khi nào đủ dùng so với khi nào cần một broker thực thụ) — là kiến thức PostgreSQL có giá trị, liên quan thực tiễn cho việc xây dựng các ứng dụng hướng sự kiện, một tính năng tích hợp sẵn hữu ích thường bị bỏ qua.