Redis keyspace notifications là gì?

Question

Accepted Answer

**Keyspace notifications** cho phép client subscribe (qua Pub/Sub) tới các sự kiện về thay đổi key — như một key được set, xóa, hoặc **hết hạn**. Chúng cho phép phản ứng với các thay đổi dữ liệu trong Redis, với sự kiện hết hạn là một trigger đặc biệt phổ biến, hữu ích. ## Bật và subscribe ```bash # keyspace notifications TẮT theo mặc định — bật các lớp sự kiện bạn muốn CONFIG SET notify-keyspace-events KEA # K=keyspace, E=keyevent, A=tất cả loại sự kiện # subscribe các sự kiện: vd tất cả expiration trên toàn database PSUBSCRIBE "__keyevent@0__:expired" # kích hoạt khi BẤT KỲ key nào hết hạn (với tên key) PSUBSCRIBE "__keyspace@0__:mykey" # tất cả sự kiện trên một key cụ thể ``` Bạn bật notification (`notify-keyspace-events`, chọn sự kiện nào) và subscribe các channel đặc biệt: `__keyevent@__:` (sự kiện của một loại, vd `expired`, với key bị ảnh hưởng) hoặc `__keyspace@__:` (sự kiện trên một key cụ thể). ## Sự kiện hết hạn: một pattern phổ biến ```text The "expired" event is widely used as a TIMER/SCHEDULER: → set a key with a TTL; when it expires, you get notified → trigger an action → e.g. "order:123:hold" expires in 15 min → notification → release the held inventory → delayed jobs, session-expiry handling, scheduled actions without a separate scheduler ``` ## Các lưu ý quan trọng ```text ⚠️ Built on PUB/SUB → fire-and-forget: if no subscriber is connected when the event fires, it's MISSED (not reliable/persistent). Don't rely on it for critical events. ⚠️ "expired" fires when the key is actually REMOVED (lazy/active expiration), which can LAG behind the exact TTL time → not precise timing. ⚠️ Has overhead at high volume; for reliable event handling, use STREAMS instead. ``` ## Tại sao điều này quan trọng Hiểu keyspace notifications là kiến thức hữu ích để **phản ứng với các thay đổi dữ liệu trong Redis**, một khả năng cho phép các pattern hướng sự kiện nhất định — dù hiểu các hạn chế của nó cũng quan trọng không kém. Tính năng này cho phép client **subscribe tới các sự kiện về thay đổi key** (set, xóa, và đặc biệt là **hết hạn**) qua Pub/Sub, cho phép Redis thông báo cho ứng dụng khi dữ liệu thay đổi. **Sự kiện hết hạn nói riêng** phục vụ một pattern phổ biến, thanh lịch: dùng TTL của một key như một **timer/scheduler** — set một key để hết hạn sau một độ trễ nào đó, và notification hết hạn kích hoạt một hành động (giải phóng inventory được giữ sau một khoảng giữ, xử lý hết hạn session, chạy job trì hoãn), cung cấp hành vi hành động theo lịch mà không cần một hệ thống lập lịch riêng. Hiểu cách bật notification (`notify-keyspace-events`) và subscribe các channel keyevent/keyspace đặc biệt là cơ chế thực hành. Quan trọng, hiểu các **lưu ý** là thiết yếu để dùng cái này đúng: vì nó được xây trên **Pub/Sub, nó là fire-and-forget** (sự kiện không có subscriber kết nối bị bỏ lỡ vĩnh viễn — nên nó không tin cậy cho các sự kiện quan trọng), sự kiện **expired bị trễ** so với TTL chính xác (kích hoạt khi key thực sự bị xóa bởi lazy/active expiration, nên timing không chính xác), và nó có overhead ở khối lượng cao — nghĩa là cho xử lý sự kiện tin cậy, Streams hoặc một cơ chế khác tốt hơn. Nhận thức này ngăn việc quá phụ thuộc vào notification cho gửi tin được đảm bảo. Vì phản ứng với các thay đổi dữ liệu Redis (đặc biệt expiration như timer) là một pattern hữu ích cho các hành động trì hoãn và lập lịch, và vì keyspace notifications cung cấp nó nhưng với các hạn chế độ tin cậy và timing quan trọng (kế thừa bản chất fire-and-forget của Pub/Sub), hiểu keyspace notifications — chúng là gì, pattern expiration-như-timer, và đặc biệt là các lưu ý — là kiến thức giá trị, có liên quan về mặt thực hành để dùng tính năng này đúng cách trong khi biết khi nào các hạn chế của nó đòi hỏi một cách tiếp cận tin cậy hơn.