Redis keyspace notifications คืออะไร?

Question

Accepted Answer

**Keyspace notifications** ช่วยให้ไคลเอนต์ subscribe (ผ่าน Pub/Sub) เพื่อรับ event เกี่ยวกับการเปลี่ยนแปลงของ key — เช่น key ถูก set, ลบ หรือ **หมดอายุ (expired)** มันช่วยให้ตอบสนองต่อการเปลี่ยนแปลงข้อมูลใน Redis โดย event การหมดอายุเป็น trigger ที่พบบ่อยและมีประโยชน์เป็นพิเศษ ## การเปิดใช้งานและการ subscribe ```bash # keyspace notifications are OFF by default — enable the event classes you want CONFIG SET notify-keyspace-events KEA # K=keyspace, E=keyevent, A=all event types # subscribe to events: e.g. all expirations across the database PSUBSCRIBE "__keyevent@0__:expired" # fires when ANY key expires (with the key name) PSUBSCRIBE "__keyspace@0__:mykey" # all events on a specific key ``` คุณเปิดใช้งาน notification (`notify-keyspace-events` โดยเลือก event ที่ต้องการ) และ subscribe ไปยังช่องพิเศษ: `__keyevent@__:` (event ของชนิดหนึ่ง เช่น `expired` พร้อม key ที่ได้รับผลกระทบ) หรือ `__keyspace@__:` (event บน key ที่ระบุ) ## event การหมดอายุ: รูปแบบที่พบบ่อย ```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 ``` ## ข้อควรระวังสำคัญ ```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. ``` ## ทำไมจึงสำคัญ การเข้าใจ keyspace notifications เป็นความรู้ที่มีประโยชน์สำหรับการ **ตอบสนองต่อการเปลี่ยนแปลงข้อมูลใน Redis** ซึ่งเป็นความสามารถที่ช่วยให้เกิดรูปแบบ event-driven บางอย่าง — แม้การเข้าใจข้อจำกัดของมันจะสำคัญพอกัน ฟีเจอร์นี้ช่วยให้ไคลเอนต์ **subscribe เพื่อรับ event เกี่ยวกับการเปลี่ยนแปลงของ key** (การ set, ลบ และโดยเฉพาะ **การหมดอายุ**) ผ่าน Pub/Sub ทำให้ Redis แจ้งแอปพลิเคชันเมื่อข้อมูลเปลี่ยนแปลง **event การหมดอายุโดยเฉพาะ** ขับเคลื่อนรูปแบบที่พบบ่อยและสง่างาม: การใช้ TTL ของ key เป็น **timer/scheduler** — set key ให้หมดอายุหลังหน่วงเวลาหนึ่ง และ notification การหมดอายุจะ trigger การกระทำ (ปล่อย inventory ที่ถือไว้หลังช่วงเวลา hold, จัดการการหมดอายุของ session, รัน delayed job) ให้พฤติกรรมแบบ scheduled-action โดยไม่ต้องมีระบบ scheduling แยกต่างหาก การเข้าใจวิธีเปิดใช้งาน notification (`notify-keyspace-events`) และ subscribe ไปยังช่อง keyevent/keyspace พิเศษเป็นกลไกที่ใช้ได้จริง ที่สำคัญ การเข้าใจ **ข้อควรระวัง** จำเป็นต่อการใช้สิ่งนี้อย่างถูกต้อง: เพราะมันสร้างบน **Pub/Sub จึงเป็นแบบ fire-and-forget** (event ที่ไม่มี subscriber เชื่อมต่ออยู่จะถูกพลาดถาวร — จึงไม่น่าเชื่อถือสำหรับ event ที่สำคัญ), **event expired ล่าช้า** กว่า TTL ที่แท้จริง (เกิดขึ้นเมื่อ key ถูกลบจริงโดยการ expiration แบบ lazy/active ดังนั้นจังหวะเวลาจึงไม่แม่นยำ) และมี overhead เมื่อปริมาณสูง — หมายความว่าสำหรับการจัดการ event ที่เชื่อถือได้ Streams หรือกลไกอื่นดีกว่า ความตระหนักนี้ป้องกันการพึ่งพา notification มากเกินไปสำหรับการส่งมอบที่รับประกันได้ เนื่องจากการตอบสนองต่อการเปลี่ยนแปลงข้อมูลใน Redis (โดยเฉพาะการหมดอายุในฐานะ timer) เป็นรูปแบบที่มีประโยชน์สำหรับการกระทำที่หน่วงเวลาและการ scheduling และเนื่องจาก keyspace notifications ให้สิ่งนี้แต่พร้อมข้อจำกัดด้านความน่าเชื่อถือและจังหวะเวลาที่สำคัญ (สืบทอดธรรมชาติ fire-and-forget ของ Pub/Sub) การเข้าใจ keyspace notifications — ว่ามันคืออะไร รูปแบบ expiration-as-timer และโดยเฉพาะข้อควรระวัง — จึงเป็นความรู้ที่มีค่าและเกี่ยวข้องในทางปฏิบัติสำหรับการใช้ฟีเจอร์นี้อย่างเหมาะสมขณะรู้ว่าเมื่อใดที่ข้อจำกัดของมันต้องการแนวทางที่เชื่อถือได้มากกว่า