Redis — cache ที่ไม่โกหก

1 · cache คืออะไร และ Redis อยู่ตรงไหน

cache ไม่ใช่เทคโนโลยี มันคือกลยุทธ์เดียวที่ถูกทำซ้ำหลายชั้น: ถ้าคำตอบนี้แพงที่จะหามาใหม่ และมันไม่ค่อยเปลี่ยน — เก็บสำเนาไว้ใกล้ ๆ คนถาม

วิธีอ่านแผนภาพข้างล่าง: ไล่จากบนลงล่างทีละชั้น — ชั้นไหนมีสำเนาอยู่แล้วก็ตอบจากชั้นนั้นเลย ไม่ลงชั้นถัดไป ยิ่งอยู่บนยิ่งเร็วแต่ยิ่งเสี่ยงเป็นของเก่า · ยิ่งลงล่างยิ่งช้าแต่ยิ่งตรงกับความจริง
คอลัมน์กลางบอกว่าสำเนาไปนั่งอยู่ที่ไหน · คอลัมน์ขวาบอกว่าข้อดี/ข้อจำกัดของชั้นนั้น

   ผู้ใช้กดปุ่ม
      │   (ไล่ลงทีละชั้น — เจอสำเนาที่ชั้นไหน ตอบกลับจากชั้นนั้นทันที)
      │
      ├─▶ browser cache      สำเนาอยู่ในเครื่องผู้ใช้      เร็วสุด · เราสั่งลบไม่ได้
      │
      ├─▶ CDN                สำเนาอยู่ใกล้ผู้ใช้ทางภูมิศาสตร์  แชร์กันทั้งประเทศ
      │
      ├─▶ in-process cache   สำเนาอยู่ใน RAM ของ service   เร็วมาก · แต่แต่ละ instance เห็นไม่เหมือนกัน
      │
      ├─▶ Redis              สำเนาอยู่ในเครื่องกลาง        ทุก instance เห็นชุดเดียวกัน
      │
      └─▶ database           แหล่งความจริง                ช้าที่สุด · ถูกต้องที่สุด

จุดขายของ Redis จึงไม่ใช่ "เร็ว" เฉย ๆ — map ใน Go ก็เร็วกว่าอีก
จุดขายคือ เร็วและ "ของกลาง": ของจริงเวลา deploy เราไม่ได้รันโปรแกรมตัวเดียว แต่รันสำเนาของโปรแกรมเดียวกันหลายตัวพร้อมกัน เพื่อรับ request ได้เยอะขึ้น (แต่ละตัวเรียกว่า instance หรือ pod) — และแต่ละตัวมี RAM ของตัวเอง ไม่เห็น map ของกัน
ถ้าเก็บ cache ไว้ใน map ของแต่ละตัว ลูกค้าคนเดียวกันกด 2 ครั้งอาจได้คนละคำตอบ เพราะไปโดนคนละ instance · ส่วน Redis เป็นเครื่องกลาง: instance ที่ 1 เขียน instance ที่ 7 อ่านเห็นทันที และ restart แอปแล้ว cache ไม่หายตามไปด้วย
นี่คือเหตุผลที่ sync.RWMutex + map จาก บทเรียน 24 ใช้แทน Redis ไม่ได้ทันทีที่คุณ deploy มากกว่าหนึ่ง instance

2 · Redis อยู่ใน RAM — อย่าใช้เป็นแหล่งความจริง

ประโยคที่ได้ยินบ่อยคือ "Redis = data store ที่เก็บใน RAM" ถูกครึ่งเดียว และครึ่งที่ขาดเป็นครึ่งที่อันตราย ผมเลยไปเปิดดู config ของจริง:

$ redis-cli CONFIG GET save
save
3600 1 300 100 60 10000

$ redis-cli CONFIG GET appendonly
appendonly
no

แปลว่า image redis:7-alpine เขียนไฟล์ลงดิสก์ให้เองอยู่แล้ว
Redis มีวิธีเก็บลงดิสก์สองแบบ: RDB = ถ่ายรูปข้อมูลทั้งก้อนเป็นครั้ง ๆ (snapshot) ตามเงื่อนไขข้างบน — เปลี่ยน 1 คีย์ใน 3600 วิ หรือ 100 คีย์ใน 300 วิ หรือ 10000 คีย์ใน 60 วิ ถึงจะถ่ายหนึ่งครั้ง
AOF (append-only file) = จดทุกคำสั่งที่เขียนลงไฟล์ทันทีทีละคำสั่ง — ละเอียดกว่ามาก แต่ค่า appendonly no ข้างบนแปลว่าปิดอยู่
สรุปคือตอนนี้มีแค่ "รูปถ่ายเป็นครั้ง ๆ" ไม่มีสมุดจดรายคำสั่ง — ทุกอย่างที่เขียนหลังรูปล่าสุดจึงไม่มีหลักฐานบนดิสก์ ผมเลยทดลองสองแบบ:

$ SET survivor "ฉันจะรอดไหม"     # เขียนไว้ก่อน แล้วสั่ง restart
OK
$ docker restart day7-redis

$ GET survivor
ฉันจะรอดไหม
$ DBSIZE            # DBSIZE = นับจำนวน key ทั้งหมดที่เหลืออยู่
5
$ LASTSAVE          # เวลาที่ save ล่าสุด (Unix timestamp = วินาทีนับจากปี 1970)
1787057770

$ SET after_save "เขียนหลัง save ล่าสุด"
$ docker kill day7-redis
$ docker start day7-redis

$ GET after_save
                  ← ว่าง
$ EXISTS after_save
0

3 · 8 command ที่ต้องคล่อง

ทั้งหมดนี้รันจริงผ่าน redis-cli บน Redis 7.4.10 — output คือของจริง ไม่ใช่ของแต่ง

$ SET user:1 "Somchai"
OK
$ GET user:1
Somchai
$ GET user:999        # key ไม่มี → ว่างเปล่า

$ EXISTS user:1
1
$ EXISTS user:999
0
$ TYPE user:1
string
$ TYPE user:999       # key ไม่มี → none ไม่ใช่ nil
none

$ LPUSH mylist a b c  # Redis ไม่ได้เก็บได้แค่ string — LPUSH สร้าง "list" ใส่ 3 ค่า
3                     # คืนจำนวนสมาชิกใน list ตอนนี้ (บทนี้ใช้ list แค่เพื่อโชว์ WRONGTYPE)
$ TYPE mylist
list
$ GET mylist          # GET ใช้กับ string เท่านั้น เอาไปอ่าน list ไม่ได้
WRONGTYPE Operation against a key holding the wrong kind of value

$ DEL user:1
1
$ DEL user:1          # ลบซ้ำ
0
$ EXISTS user:1
0

(nil)
(integer) -2
(integer) 1

4 · TTL คืน -1 กับ -2 ต่างกันยังไง

$ TTL nokey:xyz
$ SET plain "no-expire"
$ TTL plain
$ EXPIRE plain 100
$ TTL plain
$ EXPIRE nokey:xyz 100
$ PERSIST plain
$ TTL plain
$ PERSIST plain

$ TTL nokey:xyz            # key ไม่มีเลย
-2
$ SET plain "no-expire"
$ TTL plain                # มี key แต่ไม่ได้ตั้ง expire
-1
$ EXPIRE plain 100
1
$ TTL plain                # มี expire แล้ว
100

$ EXPIRE nokey:xyz 100     # ตั้ง expire ให้ key ที่ไม่มี
0
$ PERSIST plain            # ถอด expire ออก
1
$ TTL plain                # กลับเป็นอมตะ
-1
$ PERSIST plain            # ถอดซ้ำ
0

ที่ต้องเน้นคือ -2 ตอบได้แค่ "ตอนนี้ไม่มี" ไม่ได้บอกว่าทำไม — ผมทดสอบ key ที่ตั้ง EX 3 แล้วรอให้หมดอายุ ได้แบบนี้:

$ SET session:abc "logged-in" EX 3
OK
$ TTL session:abc
3
$ GET session:abc
logged-in
--- sleep 2 ---
$ TTL session:abc
1
$ GET session:abc
logged-in
--- sleep 2 (รวม 4 วิ > TTL 3) ---
$ TTL session:abc
-2
$ GET session:abc          ← ว่างเปล่า

$ EXISTS session:abc
0
$ TYPE session:abc
none

หลังหมดอายุ key มีสถานะเหมือนไม่เคยถูกสร้างทุกประการ (TTL -2 · EXISTS 0 · TYPE none)
Redis ไม่เก็บหลักฐานว่าเคยมี — เดี๋ยวหัวข้อ 7 จะเห็นว่าเรื่องนี้ทำให้ debug ยากขึ้นแค่ไหน

5 · cache-aside — pattern เดียวที่ต้องจำ

cache-aside แปลตรงตัวว่า "cache อยู่ข้าง ๆ" — ตัว cache ไม่รู้จัก database เลย โค้ดของเราเป็นคนเดินให้ทั้งสองฝั่ง:

   อ่าน:  ถาม Redis ──┬── เจอ (HIT)  ──▶ ตอบเลย
                          │
                          └── ไม่เจอ (MISS) ──▶ ถาม DB ──▶ เขียนกลับเข้า Redis พร้อม TTL ──▶ ตอบ

   เขียน: เขียน DB ──▶ ?????   ← ช่องว่างตรงนี้คือทั้งบทเรียน

ก่อนอ่านโค้ด มีเรื่องเดียวที่ต้องรู้ก่อน: go-redis รายงาน "ไม่มี key" เป็น error ไม่ใช่ค่าว่าง โดยใช้ error สำเร็จรูปชื่อ redis.Nil — เป็น sentinel error (error ที่ประกาศไว้ตัวเดียวตายตัว ให้ทุกคนเอาไปเทียบว่า “ใช่กรณีนี้ไหม”) ตัวเดียวกับที่ฝึกใน บทเรียน 12
แปลว่าเวลา Get คืน error มา เราต้องแยกให้ออกว่าเป็น "ไม่มีของใน cache" (redis.Nil = เรื่องปกติ ไปอ่าน DB ต่อ) หรือ "Redis มีปัญหา" (error ตัวอื่น = ต้องรายงานขึ้นไป) รายละเอียดว่าทำไมเขาออกแบบแบบนี้ และพลาดแล้วเกิดอะไร อยู่ในหัวข้อ 8 กับดัก 1

func getUser(ctx context.Context, rdb *redis.Client, id int) (User, string, error) {
    key := fmt.Sprintf("user:%d", id)

    val, err := rdb.Get(ctx, key).Result()
    if err == nil {                                  // ── HIT
        var u User
        if err := json.Unmarshal([]byte(val), &u); err != nil {
            return User{}, "", err
        }
        return u, "HIT", nil
    }
    if !errors.Is(err, redis.Nil) {                  // ── error จริง (เน็ตหลุด / redis ตาย)
        return User{}, "", fmt.Errorf("redis error: %w", err)
    }

    u := queryDB(id)                                // ── MISS → ไปอ่านของจริง
    b, _ := json.Marshal(u)
    if err := rdb.Set(ctx, key, b, 60*time.Second).Err(); err != nil {
        return User{}, "", err
    }
    return u, "MISS", nil
}

สามทาง ไม่ใช่สองทาง — HIT / MISS / error จริง นี่คือรูปทรงเดียวกับที่ฝึกใน บทเรียน 12: อย่าถามแค่ว่า "มี error ไหม" ให้ถามว่า "error ตัวไหน"
ทุกคำสั่งรับ ctx เป็นตัวแรก — เหตุผลเดียวกับ บทเรียน 25: ถ้าผู้ใช้ปิดหน้าเว็บไปแล้ว การรอ Redis ต่อก็ไม่มีประโยชน์

call #1  MISS  205.699084ms  name=Somchai
call #2  HIT   1.826875ms  name=Somchai
call #3  HIT   800.417µs  name=Somchai
call #4  HIT   636.333µs  name=Somchai
call #5  HIT   692.833µs  name=Somchai

MISS = 205.699084ms
HIT  = 1.826875ms
เร็วขึ้น 112.6 เท่า

MISS = 202.910542ms
HIT  = 730.666µs
เร็วขึ้น 277.7 เท่า

6 · หัวใจของบท — cache โกหกได้

กลับไปดูแผนภาพหัวข้อ 5 ตรง ?????
สมมติทีมการตลาดขึ้นราคาสินค้าผ่านหน้าแอดมิน โค้ดฝั่งนั้น UPDATE ลง database เรียบร้อย แต่ไม่รู้จัก Redis — จะเกิดอะไร

// 1) อ่านครั้งแรก — cache ยังว่าง
p, s := getProduct(ctx, rdb, 1)     // เสื้อยืด ราคา 300

// 2) ฝ่ายการตลาดขึ้นราคาใน DB เป็น 500 — ไม่แตะ Redis เลย
db[1] = Product{ID: 1, Name: "เสื้อยืด", Price: 500}

// 3) ลูกค้าอ่านผ่าน cache สามครั้ง
for i := 1; i <= 3; i++ {
    p, s := getProduct(ctx, rdb, 1)
    fmt.Printf("[%s] ลูกค้าเห็นราคา %d บาท   <-- DB บอก %d\n", s, p.Price, db[1].Price)
}

=== 1) อ่านครั้งแรก (cache miss -> โหลดเข้า cache) ===
[MISS] เสื้อยืด ราคา 300 บาท

=== 2) ฝ่ายการตลาดขึ้นราคาใน DB เป็น 500 (ไม่ invalidate cache) ===
ค่าใน DB ตอนนี้  = 500 บาท

=== 3) ลูกค้าอ่านผ่าน cache ===
[HIT] ลูกค้าเห็นราคา 300 บาท   <-- DB บอก 500
[HIT] ลูกค้าเห็นราคา 300 บาท   <-- DB บอก 500
[HIT] ลูกค้าเห็นราคา 300 บาท   <-- DB บอก 500

ค่าดิบใน Redis = {"id":1,"name":"เสื้อยืด","price":300}
TTL เหลือ      = 1m0s  (อีกเท่านี้ถึงจะเลิกโกหกเอง)

=== 4) แก้ด้วยการ invalidate: DEL key ===
DEL product:1 -> ลบไป 1 key
[MISS] ลูกค้าเห็นราคา 500 บาท   <-- ตรงกับ DB แล้ว

7 · ทำยังไงให้ cache ไม่โกหก

มีสองทางที่คุณเลือกได้ และทางที่สามที่เลือกไม่ได้

rdb.Set(ctx, key, b, 60*time.Second)

rdb.Del(ctx, "product:1")

ทางที่สาม: key หายเองโดยที่คุณไม่ได้สั่ง

ผมตั้ง maxmemory 3mb กับ policy allkeys-lru แล้วสร้าง key ที่มี TTL 3600 วินาที จากนั้นยัดข้อมูลขยะเข้าไปจนเต็ม โดยไม่แตะ key นั้นอีกเลย:

ตั้ง important:1 TTL 3600 แล้ว *ไม่แตะอีกเลย* (ให้เป็น least-recently-used)
=== ยัด junk 3 รอบ รอบละ 50k (SET junk:N ...) ===
# ตัวเลขแต่ละรอบคือผลของ EXISTS important:1 หลังยัดจบรอบนั้น
รอบ 1: 1     ← ยังอยู่
รอบ 2: 0     ← หายแล้ว ทั้งที่ TTL ยังเหลืออีก ~3600 วิ
รอบ 3: 0

$ EXISTS important:1
0
$ GET important:1

$ TTL important:1   <-- -2 ทั้งที่ยังไม่ถึงเวลาหมดอายุ
-2
evicted_keys:190824

ตั้งไว้ 1 ชั่วโมง หายไปในไม่กี่วินาที และ TTL คืน -2 เหมือนหมดอายุตามปกติเป๊ะ — นี่คือเหตุผลที่หัวข้อ 4 บอกว่า -2 ตอบได้แค่ "ตอนนี้ไม่มี": หมดอายุ · โดน evict · หรือไม่เคยมี ให้ผลเหมือนกันหมดทั้งสามกรณี

$ CONFIG GET maxmemory-policy
maxmemory-policy
noeviction

$ CONFIG GET maxmemory      # restart ล้าง maxmemory กลับเป็น 0 (= ไม่จำกัด) ด้วย
maxmemory
0
$ CONFIG SET maxmemory 3mb  # ตั้งเพดานใหม่ แต่คราวนี้ *ไม่* แตะ policy
OK
# แล้วยัด fill:1 ... fill:60000 จนชนเพดาน

$ SET newkey "เขียนได้ไหม"
OOM command not allowed when used memory > 'maxmemory'.

$ GET fill:1   <-- อ่านยังได้อยู่
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
$ DEL fill:1   <-- ลบยังได้
1

บทสรุปของหัวข้อนี้จึงไม่ใช่ "ตั้ง TTL ให้ดี" แต่คือ อย่าถือว่า TTL เป็นสัญญา — key หายได้ตลอดเวลาโดยไม่บอกล่วงหน้า
ซึ่งวนกลับไปกฎเดียวกับหัวข้อ 2: cache ต้องสร้างใหม่จากต้นทางได้เสมอ

ผลข้างเคียงที่ต้องรู้: cache stampede

ถ้า cache หายพร้อมกันหลาย key (deploy ใหม่ · Redis restart · โดน evict ยกชุด) แล้ว request วิ่งเข้ามาพร้อมกัน — ทุกตัวจะ miss พร้อมกัน แล้วแห่ไป DB พร้อมกัน ผมยิง 100 request พร้อมกันตอน cache ว่าง:

=== cache stampede: 100 request พร้อมกันตอน cache ว่าง ===
(อุดมคติคือ DB ควรโดนยิงแค่ 1 ครั้ง)

แบบไร้เดียงสา (ไม่มี lock)    request=100  DB ถูกยิง 100 ครั้ง  ใช้เวลา 269ms
แบบมี mutex + double-check    request=100  DB ถูกยิง   1 ครั้ง  ใช้เวลา 282ms

ตัวแก้คือ sync.Mutex จาก บทเรียน 24 + เช็ค cache ซ้ำอีกครั้งหลังได้ lock — เพราะระหว่างที่เรายืนรอคิว คนที่เข้าไปก่อนหน้าอาจอ่าน DB แล้วเติม cache ให้เรียบร้อยแล้ว เราจึงไม่ต้องไปยิง DB ซ้ำ:

val, err := rdb.Get(ctx, key).Result()   // เช็ครอบแรก (ไม่ต้องรอคิว)
if err == nil { return decode(val) }

mu.Lock()                                  // miss → เข้าคิว ทีละคนเท่านั้น
defer mu.Unlock()
val, err = rdb.Get(ctx, key).Result()    // ← double-check: เช็คซ้ำหลังได้คิว
if err == nil { return decode(val) }  //   คนก่อนหน้าเติมให้แล้ว จบเลย

u := queryDB(id)                          // คนแรกคนเดียวที่ได้ยิง DB
rdb.Set(ctx, key, encode(u), 60*time.Second)

— ต้นทุนแทบเป็นศูนย์: 269ms กับ 282ms

8 · สามกับดักที่คนใหม่เจอทุกคน

กับดัก 1 — redis.Nil ไม่ใช่ error จริง

cache miss คือเหตุการณ์ปกติที่สุดของ cache แต่ go-redis รายงานมันเป็น error:

val        = ""
err        = redis: nil
err != nil = true
err == redis.Nil        = true
errors.Is(err,redis.Nil)= true
redis.Nil ตัวมันเอง     = "redis: nil"  (type proto.RedisError)

val, err := rdb.Get(ctx, key).Result()
if err != nil {
    return err       // → HTTP 500
}

val, err := rdb.Get(ctx, key).Result()
switch {
case errors.Is(err, redis.Nil):
    // miss → ไปอ่าน DB ต่อ
case err != nil:
    // error จริง
default:
    // hit → ใช้ val
}

โครง switch ฝั่งขวารับมือ error อื่นได้ถูกต้องด้วย เพราะทั้ง OOM (out of memory = RAM เต็มจนเขียนเพิ่มไม่ได้) และ WRONGTYPE ไม่ใช่ redis.Nil:

Set err                  = OOM command not allowed when used memory > 'maxmemory'.
errors.Is(err, redis.Nil)= false
type                     = *proto.OOMError

Get(list) val="" err=WRONGTYPE Operation against a key holding the wrong kind of value
errors.Is(err, redis.Nil)= false

NewClient สำเร็จทันที ไม่ error เลย (lazy connect)
Ping -> "", err = dial tcp 127.0.0.1:55999: connect: connection refused
Get  -> err = dial tcp 127.0.0.1:55999: connect: connection refused
errors.Is(err, redis.Nil) = false   <-- ระวัง! connection error ไม่ใช่ cache miss

กับดัก 2 — โยน struct ลง Redis ตรง ๆ

rdb.Set รับพารามิเตอร์เป็น any → compile ผ่านสบายมาก แล้วไปพังตอน runtime:

Set(struct) err  = redis: can't marshal main.User (implement encoding.BinaryMarshaler)
Set(&struct) err = redis: can't marshal *main.User (implement encoding.BinaryMarshaler)
Set(map) err     = redis: can't marshal map[string]int (implement encoding.BinaryMarshaler)
Set(slice) err   = redis: can't marshal []int (implement encoding.BinaryMarshaler)
EXISTS ทั้ง 4 key -> 0  (ไม่มีอะไรถูกเขียนเลย)

ชนิดที่ go-redis รับได้ตรง ๆ มีเท่านี้:

  string     -> err=<nil>  stored="str"
  int        -> err=<nil>  stored="42"
  float64    -> err=<nil>  stored="3.14"
  bool       -> err=<nil>  stored="1"
  []uint8    -> err=<nil>  stored="bytes"
  time.Duration -> err=<nil>  stored="1000000000"

ทางแก้คือ marshal เองก่อน (marshal = แปลงข้อมูลในโปรแกรมให้เป็นข้อความหรือไบต์ ก่อนส่งออกไปข้างนอก) — json.Marshal จาก บทเรียน 13:

b, err := json.Marshal(u)
if err != nil { return err }
rdb.Set(ctx, key, b, ttl)     // []byte ผ่านฉลุย

กับดัก 3 — KEYS * เทียบกับ SCAN

$ MSET u:1 a u:2 b u:3 c p:1 x p:2 y

$ SCAN 0 MATCH "u:*"
...

$ SCAN 0 MATCH "u:*" COUNT 2
...

$ SCAN 0 MATCH "u:*"
0
u:1
u:2
u:3

$ SCAN 0 MATCH "u:*" COUNT 2   # COUNT เป็นแค่ hint
3
u:1

// KEYS: ดึงหมดในคำสั่งเดียว
keys, err := rdb.Keys(ctx, "*").Result()

// SCAN: ต้องวนจน cursor == 0 เท่านั้น
var cursor uint64
for {
    batch, cur, err := rdb.Scan(ctx, cursor, "*", 1000).Result()
    if err != nil { break }
    for _, k := range batch { /* ... */ }
    cursor = cur
    if cursor == 0 { break }   // ← เงื่อนไขเดียวที่ถูกต้อง
}

ตำราส่วนใหญ่บอกว่า "ใช้ SCAN เพราะ KEYS ช้า" — ผมวัดแล้วพบว่าเหตุผลนี้ผิด บน 1,000,000 key:

=== KEYS * (ดึงมาทีเดียวหมด) ===
ได้ 1000000 keys ใน 150.375625ms
heap ขณะถือผลลัพธ์ = 30.9 MB  (โต +30.5 MB)

=== SCAN (ทยอยดึงทีละ batch 1000) ===
ได้ 1000000 keys (นับซ้ำ) ใน 862.022875ms
วน 1000 รอบ, batch ใหญ่สุด 1004 keys

KEYS เร็วกว่า 5.7 เท่า เพราะ SCAN ต้องวิ่ง round-trip (ไป-กลับระหว่างโปรแกรมเรากับ Redis หนึ่งเที่ยว) ถึง 1,000 รอบ
ถ้าเราสอนว่า "SCAN เร็วกว่า" ผู้เรียนจะไป benchmark เองแล้วสรุปว่าอาจารย์ผิด แล้วกลับไปใช้ KEYS — เหตุผลที่ถูกต้องอยู่ที่อื่น:

146086      ← KEYS *   = 146 ms
KEYS
*

57          ← SCAN 0 COUNT 100 = 57 µs
SCAN
0
COUNT
100

A) baseline (ไม่มีอะไรกวน)  : min: 0, max: 2,   avg: 0.38 (447 samples)
B) ขณะมี KEYS * ยิงรัว ๆ    : min: 0, max: 274, avg: 12.47 (245 samples)
C) ขณะมี SCAN ยิงรัว ๆ      : min: 0, max: 2,   avg: 0.38 (449 samples)

9 · ปิด Day 7 — เครื่องมือสี่ตัว คำถามเดียว

ทั้งวันนี้เราเจอเครื่องมือสี่ตัวที่ดูไม่เกี่ยวกันเลย แต่ทุกตัวตอบคำถามเดียวกัน: "ระหว่างเร็วกับจริง คุณกำลังแลกอะไรกับอะไร"

สังเกตว่าคอลัมน์ "เสียอะไร" ของทั้งสี่แถวไม่มี error message เลยสักตัว — ราคาของความเร็วไม่เคยจ่ายเป็น crash มันจ่ายเป็นความไม่ตรงกับความจริง
และนั่นคือทักษะที่ Day 7 พยายามสร้าง: รู้ว่าตอนนี้กำลังมองของจริงหรือมองสำเนาอยู่ — mock คือสำเนาของ dependency · cache คือสำเนาของข้อมูล · container คือของจริงที่แพงกว่า · migration คือสิ่งที่ทำให้ "ของจริง" ของทุกคนเป็นอันเดียวกัน

ทดสอบความเข้าใจ

NewClient สำเร็จทันที ไม่ error เลย (lazy connect)
redis: 2026/08/18 19:53:47 pool.go:762: redis: connection pool: failed to dial after 5 attempts: dial tcp 127.0.0.1:55999: connect: connection refused
redis: 2026/08/18 19:53:48 pool.go:762: redis: connection pool: failed to dial after 5 attempts: dial tcp 127.0.0.1:55999: connect: connection refused
Ping -> "", err = dial tcp 127.0.0.1:55999: connect: connection refused
Get  -> err = dial tcp 127.0.0.1:55999: connect: connection refused
errors.Is(err, redis.Nil) = false

อ้างอิง

• Redis — TTL · EXPIRE — นิยามของ -1 / -2 อย่างเป็นทางการ
• Redis — SCAN — อ่านหัวข้อ guarantees: SCAN การันตีแค่ว่า key ที่อยู่ตลอดการวนจะถูกคืนอย่างน้อยหนึ่งครั้ง (ซ้ำได้)
• Redis — KEYS — เอกสารทางการเตือนเองว่าอย่าใช้ใน production
• Redis Persistence — RDB กับ AOF ต่างกันยังไง และ default คืออะไร
• pkg.go.dev — go-redis v9 · repo + ตัวอย่าง
• golang.org/x/sync/singleflight — ทางเลือกที่สะอาดกว่า mutex สำหรับ stampede (บทนี้ยังไม่ได้ทดสอบให้)
• Cheat sheet Day 7 — คำสั่งและตารางกับดักรวมทั้งวัน