มีกลยุทธ์และรูปแบบการ caching อะไรบ้างกับ Redis?

Question

Accepted Answer

นอกเหนือจาก cache-aside พื้นฐาน ยังมี **กลยุทธ์การ caching** หลายแบบ — cache-aside, write-through, write-behind, read-through — แต่ละแบบมีการแลกเปลี่ยนด้านความสอดคล้องและประสิทธิภาพต่างกัน การเข้าใจมัน (และ eviction policy) ช่วยให้คุณออกแบบการ caching ที่มีประสิทธิภาพ

## cache-aside (lazy loading — พบบ่อยที่สุด)

```text
App checks cache → miss → load from DB → populate cache → return.
  ✓ Only requested data is cached (efficient); resilient (works if cache is down)
  ✗ First request is a miss (slower); cache can be stale until TTL/invalidation
→ The default, most common strategy.
```

## write-through และ write-behind

```text
WRITE-THROUGH → write to cache AND DB together (synchronously) on every write
  ✓ Cache always fresh/consistent  ✗ Writes are slower (two writes); caches unread data

WRITE-BEHIND (write-back) → write to cache immediately, write to DB ASYNC later
  ✓ Fast writes  ✗ Risk of data loss if cache fails before the DB write; more complex
```

## read-through

```text
READ-THROUGH → the cache layer itself loads from the DB on a miss (abstracted)
  → app just reads from the cache; the cache handles DB loading transparently
  (similar to cache-aside but the loading logic lives in the cache layer/library)
```

## eviction policy (เมื่อหน่วยความจำเต็ม)

```text
When Redis hits its memory limit (maxmemory), it EVICTS keys per a policy:
  LRU (Least Recently Used)  → evict least-recently-accessed (good general default)
  LFU (Least Frequently Used)→ evict least-frequently-accessed
  TTL-based (volatile-ttl)   → evict keys closest to expiry
  random / noeviction        → random, or reject writes when full
→ allkeys-lru is a common choice for a pure cache. Set maxmemory + a policy.
```

## การหลีกเลี่ยงปัญหา cache

```text
✓ Cache STAMPEDE (many misses at once hammering the DB) → locking, staggered TTLs
✓ Stale data → appropriate TTLs + invalidation on writes
✓ Cache PENETRATION (querying non-existent keys) → cache negative results briefly
```

## ทำไมจึงสำคัญ

การเข้าใจกลยุทธ์การ caching มีคุณค่าต่อ **การออกแบบระบบ caching ที่มีประสิทธิภาพ** โดยต่อยอดจาก cache-aside พื้นฐาน ดังนั้นจึงเป็นความรู้ที่มีประโยชน์สำหรับงานที่เน้นประสิทธิภาพ

แม้ว่า cache-aside (lazy loading — ตรวจสอบ cache โหลดจาก DB เมื่อ miss แล้วใส่ลง cache) จะเป็นค่าเริ่มต้นที่พบบ่อย แต่การเข้าใจ **ขอบเขตของกลยุทธ์** ทำให้คุณเลือกแบบที่เหมาะกับสถานการณ์ได้: **write-through** (เขียนลง cache และ DB พร้อมกันเพื่อให้ cache สดเสมอ โดยแลกกับการเขียนที่ช้ากว่า), **write-behind** (เขียนลง cache ทันทีและเขียนลง DB แบบ async เพื่อการเขียนที่รวดเร็วแต่มีความเสี่ยงสูญเสียข้อมูล) และ **read-through** (cache layer โหลดจาก DB อย่างโปร่งใส) — แต่ละแบบมีการแลกเปลี่ยนด้านความสอดคล้อง/ประสิทธิภาพที่ชัดเจนซึ่งสำคัญสำหรับความต้องการด้านความสอดคล้องและรูปแบบการเขียนที่ต่างกัน

การเข้าใจ **eviction policy** (LRU, LFU, TTL-based ฯลฯ — วิธีที่ Redis ตัดสินใจว่าจะลบ key ใดเมื่อหน่วยความจำเต็ม) สำคัญต่อการตั้งค่า Redis เป็น cache อย่างถูกต้อง (ตั้ง `maxmemory` และ policy ที่เหมาะสมเช่น `allkeys-lru` สำหรับ cache ล้วน) เพื่อให้มันทำงานได้ดีภายใต้แรงกดดันด้านหน่วยความจำ

การรู้วิธี **หลีกเลี่ยงปัญหา cache ที่พบบ่อย** — cache **stampede** (การ miss พร้อมกันจำนวนมากกระหน่ำ database บรรเทาด้วย locking หรือ staggered TTL), **stale data** (จัดการด้วย TTL และ invalidation) และ cache **penetration** (การ query ซ้ำสำหรับ key ที่ไม่มีอยู่ บรรเทาด้วยการ cache ผลลัพธ์เชิงลบ) — สะท้อนถึงการออกแบบ cache ที่เป็นผู้ใหญ่ซึ่งหลีกเลี่ยงปัญหา production จริง

เนื่องจากการ caching ที่มีประสิทธิภาพส่งผลต่อประสิทธิภาพอย่างมีนัยสำคัญ และกลยุทธ์/การตั้งค่าที่ถูกต้องขึ้นอยู่กับ use case และเนื่องจากการเข้าใจกลยุทธ์ eviction policy และกับดักที่พบบ่อยทำให้ออกแบบ caching ที่แข็งแกร่งได้ การเข้าใจกลยุทธ์และรูปแบบการ caching จึงเป็นความรู้ที่มีคุณค่าและเกี่ยวข้องเชิงปฏิบัติสำหรับวิศวกรรมประสิทธิภาพด้วย Redis ยกระดับการ caching จากรูปแบบพื้นฐานไปสู่ระบบที่ออกแบบมาอย่างดีซึ่งจัดการความสอดคล้อง หน่วยความจำ และโหมดความล้มเหลวได้อย่างถูกต้อง