Redis — những thứ cần biết

Trong một app Laravel, Redis thường gánh 5 việc cùng lúc: cache, session, lock, queue, và idempotency key. Interviewer hỏi Redis ít khi để nghe "Redis là in-memory key-value store". Họ muốn biết bạn có hiểu nó gãy ở đâu không: lệnh nào làm đứng cả server, lúc nào mất dữ liệu, vì sao lock không an toàn tuyệt đối.

Bài này gom những thứ đó, mỗi thứ có số đo thật. Phần cache (stampede, hot key, bloom filter…) nằm ở bài Cache nâng cao. Phần eviction làm mất idempotency key nằm ở bài Idempotency key ở Redis.

Thuật ngữ dùng trong bài

Môi trường kiểm chứng. Mọi output chạy thật trên Redis 8.8.0 (container tạm tmp-redis-lab và tmp-redis-replica, dựng riêng rồi xoá, không đụng chiennn_redis). Lab HA: Cluster 6 node (3 master + 3 replica, cluster-node-timeout 5000) và Sentinel (1 master + 1 replica + 3 sentinel, quorum 2, down-after-milliseconds 3000). Laravel chạy trong image laravel-app (phpredis 6.3.0), predis 3.6.0 cài tạm, source Laravel 12.64.0. Tài liệu Redis tra qua Context7 (/redis/docs). Thời gian đo phía client có cộng ~100 ms của docker exec, nên số nào quan trọng đều lấy từ SLOWLOG (đo phía server). Chỗ nào chưa verify được sẽ ghi rõ.

1. Nó là gì / chạy thế nào

1.1. Một luồng chạy lệnh — điều quan trọng nhất

flowchart LR
  C1["Client 1"] --> Q["Hàng đợi lệnh"]
  C2["Client 2"] --> Q
  C3["Client 3 ... 5000"] --> Q
  Q --> EL["Event loop
1 luồng, chạy từng lệnh một"]
  EL --> M["RAM"]
  IO["io-threads
chỉ đọc/ghi socket"] -.-> Q

Mỗi lệnh chạy một mình, nên mỗi lệnh đều atomic mà không cần lock. Đó là lý do Redis nhanh và đơn giản. Mặt trái: một lệnh chậm làm tất cả client phải đợi. io-threads mặc định là 1 trên 8.8 (CONFIG GET io-threads). Kể cả khi bật thêm, nó chỉ giúp phần mạng, không giúp phần chạy lệnh.

Đo thật những lệnh hay làm Redis đứng im:

"< 1 ms" nghĩa là lệnh không vào SLOWLOG khi đặt ngưỡng slowlog-log-slower-than 1000 (micro giây).

$ redis-cli SLOWLOG GET
177144  KEYS nomatch*          # micro giay
256186  DEL tmp:big1

Lua script chạy lâu còn tệ hơn:

$ redis-cli CONFIG GET busy-reply-threshold
busy-reply-threshold  5000

# client 1 chay script 7 giay. Giay thu 1, client 2 goi:
$ redis-cli PING
BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.
   -> cho 4117 ms                  # treo khong tra loi toi moc 5 giay, roi moi nhan loi BUSY

Trong 5 giây đầu, client treo không nhận được gì. Sau đó mọi lệnh đều nhận lỗi BUSY. Với app Laravel, 5 giây đó là toàn bộ PHP-FPM worker đứng đợi.

Thay thế an toàn: SCAN thay KEYS (quét 1 triệu key bằng --scan --count 1000 mất ~1000 lệnh nhỏ, mỗi lệnh ngắn, client khác chen vào được giữa các lệnh). UNLINK thay DEL cho key lớn. Lua chỉ làm vài thao tác ngắn, không bao giờ vòng lặp trên dữ liệu lớn.

1.2. Kiểu dữ liệu — chọn đúng kiểu là một nửa thiết kế

Đọc sâu hơn: series Redis — kiểu dữ liệu (7 bài) đi vào từng kiểu: encoding và RAM mỗi phần tử, lệnh mới của Redis 8.0–8.8 (Array, INCREX, SET … IFEQ, TTL từng field, IDMP cho stream…), bẫy khi nhiều worker cùng ghi, khi failover, và các kiểu mới (JSON, Bloom, TimeSeries, vector set). Mục dưới đây là bản tóm tắt.

Encoding: cùng một hash, RAM chênh gần 6 lần

$ redis-cli CONFIG GET hash-max-listpack-entries
hash-max-listpack-entries  512

512 field: listpack    4531 byte
513 field: hashtable  26119 byte      # them DUNG 1 field, RAM x5,8

Hash nhỏ được cất dạng listpack (một mảng byte liền nhau). Vượt ngưỡng thì Redis đổi sang hashtable và không đổi ngược lại. Đo thật: hash lên 600 field thì thành hashtable, xoá còn 1 field vẫn là hashtable. Có hai ngưỡng, vượt cái nào cũng đổi: số field (hash-max-listpack-entries 512) và độ dài value (hash-max-listpack-value 64 byte). Chỉ ghi một value 65 byte là cả hash thành hashtable (đã đo). Ngưỡng khác nhau giữa các bản Redis — kiểm tra bằng CONFIG GET trên bản mình chạy, đừng nhớ số.

Mẹo tiết kiệm RAM: gom nhiều object nhỏ vào bucket

Bài toán ví dụ: lưu tiến độ của 100.000 sinh viên, mỗi người một số nhỏ (vd 75). Cách tự nhiên là mỗi sinh viên một key. Cách tiết kiệm là chia sinh viên thành bucket cố định (vd 500 người), mỗi bucket là một hash, mỗi sinh viên là một field.

flowchart LR
  subgraph K1["Mỗi SV 1 key: 100.000 key"]
    direction TB
    D1["keyspace dict"] --> E1["entry + header + tên key
progress:1 → 75"]
    D1 --> E2["entry + header + tên key
progress:2 → 75"]
    D1 --> E3["... lặp 100.000 lần"]
  end
  subgraph K2["Bucket 500: ~200 key"]
    direction TB
    D2["keyspace dict"] --> B1["progress:0 → listpack
1|75|2|75|...|499|75"]
    D2 --> B2["progress:1 → listpack
500|75|...|999|75"]
  end

Vì sao gom lại đỡ tốn: mỗi key ở tầng ngoài cùng phải trả một khoản phí cố định. Phí đó gồm một ô trong bảng băm chính (keyspace dict), object header, chuỗi tên key progress:12345, header riêng của listpack, và thêm một ô trong bảng expire nếu có TTL. Phí này không phụ thuộc dữ liệu. Dữ liệu càng nhỏ thì phí này càng chiếm gần hết RAM. Trong bucket, mỗi sinh viên chỉ là một cặp field/value nằm liền nhau trong mảng byte: vài byte, không con trỏ, không lặp tên key.

Đo thật trên 100.000 sinh viên (ghi bằng redis-cli --pipe, lấy chênh lệch used_memory):

Đọc bảng: B và C chênh ~15 lần dù cả hai đều là listpack — phần chênh là phí mỗi key. D còn tệ hơn B: bucket đặt sai cỡ tốn RAM hơn cả không gom. Công thức: số SV mỗi bucket ≤ hash-max-listpack-entries / số field mỗi SV, và chừa khoảng trống cho field thêm sau này (3 field → bucket 150, không phải 170).

$bucket = intdiv($studentId, 150);        // id là số tăng liên tục
Redis::hset("progress:{$bucket}", "{$studentId}:pct", 75);
Redis::hget("progress:{$bucket}", "{$studentId}:pct");

// id là UUID hoặc thưa: chọn số bucket cố định từ đầu
$bucket = crc32($uuid) % 1024;

Khi nào KHÔNG dùng: vài chục nghìn object thì cách A chỉ tốn ~5 MB — không đáng để code phức tạp hơn. Mẹo này chỉ có giá khi có hàng triệu key trở lên và RAM Redis là chi phí thật.

Các kiểu khác cũng có encoding gọn và ngưỡng riêng (CONFIG GET '*-max-*' trên 8.8):

Chỉ đo RAM cho hash. Số RAM của set, zset, list chưa đo; ý nghĩa -2 lấy từ chú thích redis.conf, chưa verify.

1.3. Bộ nhớ và eviction

LRU của Redis là xấp xỉ: lấy mẫu vài key (maxmemory-samples) rồi xoá key cũ nhất trong mẫu, không duyệt hết. Chứng minh allkeys-lru xoá cả key TTL 24 giờ nằm ở bài Idempotency key mục 4.1.

maxmemory mặc định là 0 — không giới hạn

$ redis-cli CONFIG GET maxmemory
maxmemory  0

0 nghĩa là Redis dùng RAM tới khi hết máy. Không có eviction, cũng không có lỗi OOM của Redis. Khi đó kernel OOM killer (phần của Linux giết process khi máy hết RAM) giết thẳng Redis, hoặc container bị kill vì vượt memory limit. Dữ liệu chưa persist mất hết. Phần OOM killer là suy ra, chưa đo. Luôn đặt maxmemory rõ ràng, thấp hơn RAM máy hoặc limit của container, chừa chỗ cho fork và buffer của client.

Key hết hạn được xoá thế nào

Theo tài liệu Redis (Context7), có hai cách chạy song song:

• Lazy expiration: khi có client đọc key, Redis kiểm tra TTL. Hết hạn thì xoá và trả nil.
• Active expiration: mỗi 100 ms, Redis lấy mẫu ngẫu nhiên các key có TTL và xoá key đã hết hạn. Nếu hơn 25% mẫu đã hết hạn thì lặp lại ngay.

# ghi 200.000 key PX 300, khong ai doc lai
t~1s  dbsize=0  expired_keys=200000  used_memory_human=1.41M   # truoc do 4.44M

Khi nhiều key cùng hết hạn, active expiration tự lặp nhiều vòng nên dọn rất nhanh (200.000 key trong khoảng 1 giây). Mặt trái: trong lúc đó event loop bận dọn. Hàng triệu key đặt cùng TTL (vd lúc import hoặc warm cache) sẽ hết hạn cùng một lúc. Tài liệu Redis ghi đây là một nguồn gây latency. Cách tránh: cộng jitter (một số giây ngẫu nhiên) vào TTL. Độ giật latency khi hàng triệu key hết hạn cùng lúc chưa đo.

noeviction đầy RAM, đo thật:

$ redis-cli CONFIG SET maxmemory 2mb
# ghi 50.000 key
errors: 44701, replies: 50000
$ redis-cli SET one-more v
OOM command not allowed when used memory > 'maxmemory'.
$ redis-cli GET tmp:o:1            # doc van chay
xxxxxxxx...
$ redis-cli DEL tmp:o:1            # xoa van chay
1

Với Laravel: session không ghi được → mọi request có session đều ném exception → toàn bộ người dùng đã đăng nhập nhận lỗi 500. noeviction không làm mất dữ liệu, nhưng biến "đầy RAM" thành "sập". Luôn phải đi kèm alert used_memory / maxmemory.

1.4. Persistence — RDB, AOF, và cái giá của fork

Chụp RDB cần fork. Đo thật với 1 triệu key:

used_memory_human: 53.79M
$ redis-cli BGSAVE
latest_fork_usec: 8547               # 8,5 ms Redis dung im de fork
rdb_last_bgsave_status: ok

Lúc fork, Redis đứng im. Thời gian fork tăng theo lượng RAM (phải chép bảng trang bộ nhớ). 54 MB mất 8,5 ms trên máy dev. Dataset hàng chục GB có thể mất hàng trăm ms tới vài giây, tuỳ máy — phần này là suy ra, chưa đo trên dataset lớn. Trong lúc process con ghi file, trang nào process chính sửa thì bị copy ra (copy-on-write). Ghi càng nhiều thì RAM phình càng lớn, nặng nhất có thể gần gấp đôi. Vì vậy máy Redis có persistence phải để dư RAM, không đặt maxmemory sát RAM máy.

Bẫy: chụp RDB lỗi thì Redis từ chối mọi lệnh ghi

$ redis-cli CONFIG GET save                 # image redis:alpine mac dinh BAT RDB
save  3600 1 300 100 60 10000
$ redis-cli CONFIG GET stop-writes-on-bgsave-error
stop-writes-on-bgsave-error  yes

# chay Redis voi thu muc /data khong co quyen ghi
$ redis-cli BGSAVE
Background saving started
rdb_last_bgsave_status:err
$ redis-cli SET b 2
MISCONF Redis is configured to save RDB snapshots, but it's currently unable to persist to disk.
Commands that may modify the data set are disabled, ...
$ redis-cli GET a
1                                           # doc van chay
# log: Failed opening the temp RDB file temp-30.rdb (in server root dir /data) for saving: Permission denied

Đĩa đầy, sai quyền thư mục, hoặc fork thất bại là cả site không ghi được session — giống hệt OOM ở mục 1.3, dù RAM vẫn còn dư. Instance chỉ làm cache mà để cấu hình mặc định vẫn dính, vì image mặc định bật RDB. Cách xử lý: instance cache thuần thì tắt hẳn RDB (save ""). Instance cần persistence thì giữ yes (để biết mình đang không có bản sao lưu), nhưng phải alert rdb_last_bgsave_status và dung lượng đĩa. Về fork: chính Redis 8.8 in cảnh báo lúc khởi động trên máy lab: WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Cách sửa là đặt vm.overcommit_memory = 1 trên máy chủ. Chưa tái hiện được một lần fork lỗi thật.

1.5. Replication, failover, và write đã OK vẫn mất

Replication của Redis là async. Dựng master + replica thật, cắt mạng replica (docker network disconnect), rồi giết master:

master_link_status:up
-- replica song, SET + WAIT CUNG connection:
OK
1                                    # 1 replica da nhan
-- cat mang replica
-- SET + WAIT CUNG connection:
OK                                   # master van tra OK cho app
0                                    # nhung 0 replica nhan (doi 500 ms)
-- master chet, promote replica
GET tmp:order:1: paid
GET tmp:order:2:                     # MAT - du app da nhan OK

sequenceDiagram
  participant A as App
  participant M as Master
  participant R as Replica
  A->>M: SET order:2 paid
  M-->>A: OK
  Note over M,R: mạng tới replica đã đứt
  M--xM: master chết
  Note over R: Sentinel bầu replica lên master
  A->>R: GET order:2
  R-->>A: nil (write đã OK nhưng mất)

Bẫy WAIT: chỉ tính lệnh ghi của chính connection

# cung luc replica dang mat mang:
SET + WAIT tren CUNG connection        -> 0
WAIT tren connection MOI (chua ghi gi) -> 1     # tuong la an toan, thuc ra khong

Lần test đầu, tôi chạy SET và WAIT bằng hai lệnh redis-cli riêng (hai connection), và WAIT luôn trả 1 — kết quả sai hoàn toàn. Trong app PHP, WAIT phải gọi trên đúng connection vừa ghi. Và kể cả WAIT trả 1 cũng chỉ giảm rủi ro, không biến Redis thành hệ thống nhất quán mạnh: replica đã nhận chưa chắc đã được chọn làm master mới.

Sentinel hay Cluster

Redis Cluster đo thật: lệnh nào gãy

Tài liệu Redis (Context7): cluster chạy mọi lệnh một key, nhưng lệnh nhiều key chỉ chạy khi mọi key cùng slot, và chỉ có DB 0. Chạy thật trên lab 3 master:

$ redis-cli CLUSTER KEYSLOT a    -> 15495      # b -> 3300, c -> 7365, {u}:1 va {u}:2 -> 11826

# noi vao node giu slot 0-5460, KHONG bat -c
$ redis-cli SET a 1
MOVED 15495 172.21.0.4:6379                  # client phai tu di toi node dung
$ redis-cli -c MSET a 1 b 2
CROSSSLOT Keys in request don't hash to the same slot
$ redis-cli -c MGET a b                      -> CROSSSLOT
$ redis-cli -c EVAL "..." 2 a b              -> CROSSSLOT
$ redis-cli -c MSET {u}:1 x {u}:2 y          -> OK        # cung hash tag -> cung slot
$ printf 'MULTI\nSET b 1\nSET c 1\nEXEC\n' | redis-cli
MOVED 7365 172.21.0.3:6379
EXECABORT Transaction discarded because of previous errors.
$ redis-cli SELECT 1
ERR SELECT is not allowed in cluster mode
# KEYS * chi tra key cua node dang noi: 3 master cho 3 ket qua khac nhau

Laravel 12.64 + phpredis trên cùng cluster (options.cluster = redis, khai báo clusters):

Cluster failover đo thật

# log cua cac node, kill master giu slot 5461-10922
14:44:02.50  replica: Connection with master lost
14:44:10.21  node khac: FAIL message received ... Cluster state changed: fail   # ~7,7 s
14:44:10.81  Failover auth granted ... for epoch 7                              # bau replica
14:44:10.91  Cluster state changed: ok                                          # ~8,4 s tu luc chet

Trong ~8 giây đó chỉ key thuộc slot của master chết bị lỗi, slot khác vẫn ghi bình thường. Bẫy: poll CLUSTER INFO ở giây 2, 4 và 5 sau khi kill đều thấy cluster_state:ok, vì node chưa bị đánh dấu FAIL. ok không có nghĩa là mọi slot đang phục vụ được.

Không mất write nào trong test này, nhưng tốc độ ghi chỉ 10 lệnh/giây. Replication vẫn async, nên write sát lúc master chết vẫn có thể mất (mục 1.5).

Sentinel failover đo thật: Laravel có theo master mới không

Chạy cùng lúc 3 app Laravel ghi liên tục (mỗi app một prefix key để đếm riêng), rồi kill master, rồi bật master cũ lên lại, giống máy chủ reboot:

[10.0s] docker kill master 172.21.0.8
[14.0s] sentinel bau replica 172.21.0.9 len master
[22.0s] docker start master cu        # khong persistence -> khoi dong RONG, tu nhan la master
[23.6s] master cu: role=master, 0 key
[35.6s] sentinel doi master cu thanh replica  -> full sync, xoa sach nhung gi no vua nhan

Vì sao phpredis hỏng: connector của Laravel không biết Sentinel, nên giữ nguyên IP cũ. Master cũ khởi động lại không có replicaof, nên tự nhận là master và nhận ghi trong ~12 giây. Sau đó sentinel đổi nó thành replica, và full sync xoá sạch những gì nó vừa nhận. Đây là split-brain (hai master cùng nhận ghi): write đã trả OK vẫn mất. Rồi app bị READONLY tới khi restart PHP-FPM hoặc đổi config. Nếu master cũ không bao giờ sống lại, client không timeout sẽ treo bao lâu — chưa đo.

// REDIS_CLIENT=predis, composer require predis/predis (da test 3.6.0)
'redis' => [
    'client' => 'predis',
    'options' => [
        // KHONG de 'cluster' => ... o day (config mac dinh co san dong nay)
        'prefix' => env('REDIS_PREFIX', 'laravel-database-'),
    ],
    'default' => [
        'tcp://sentinel-1:26379', 'tcp://sentinel-2:26379', 'tcp://sentinel-3:26379',
        'options' => [
            'replication' => 'sentinel',
            'service' => 'mymaster',
            'parameters' => ['password' => env('REDIS_PASSWORD'), 'database' => 0],
        ],
    ],
    // 'cache' => giong 'default', 'database' => 1
],

Đã test trên cấu hình này: Redis::set/get, Cache::put/get, Cache::lock, queue push/pop đều chạy. Lab không đặt mật khẩu, nên dòng password chưa test. Tài liệu Laravel 13.x (Context7) không nhắc tới Sentinel; cấu hình trên dựa theo tài liệu predis.

Bẫy options.cluster: config/database.php mặc định có 'cluster' => env('REDIS_CLUSTER', 'redis') trong options. Giữ dòng đó thì predis tạo Predis\Connection\Cluster\RedisCluster thay vì sentinel, và mọi lệnh đều lỗi: No connections left in the pool for `CLUSTER SLOTS`. Queue thì báo Cannot use 'EVAL' with redis-cluster (đã đo).

Cách khác: managed Redis có một endpoint cố định tự trỏ về master, hoặc HAProxy kiểm tra role:master. Tài liệu Redis có min-replicas-to-write để master không có replica thì ngừng nhận ghi, nhờ đó chặn được đúng kiểu mất dữ liệu ở trên. Cả ba cách này chưa test.

1.6. Atomic: MULTI, pipeline, Lua — ba thứ hay bị lẫn

"Không rollback" đo thật:

$ redis-cli SET tmp:s abc
MULTI
INCR tmp:s                 -> QUEUED
SET tmp:k2 da-chay         -> QUEUED
EXEC
1) ERR value is not an integer or out of range     # lenh 1 loi
2) OK                                              # lenh 2 VAN chay
$ redis-cli GET tmp:k2
da-chay

Ai quen transaction của PostgreSQL sẽ bị bất ngờ ở đây. MULTI chỉ đảm bảo "chạy liền một mạch". Muốn "đọc rồi ghi có điều kiện" thì dùng WATCH (optimistic) hoặc Lua.

Redis 8.4+ có thêm lệnh so sánh–rồi–ghi, không cần Lua (tài liệu Redis qua Context7, đã chạy thật trên 8.8):

$ redis-cli SET tmp:lock ownerA
$ redis-cli SET tmp:lock ownerX IFEQ ownerB    -> (nil)   # khong khop, khong ghi
$ redis-cli SET tmp:lock ownerX IFEQ ownerA    -> OK
$ redis-cli DELEX tmp:lock IFEQ ownerA         -> 0       # xoa neu gia tri khop
$ redis-cli DELEX tmp:lock IFEQ ownerB         -> 1

1.7. Distributed lock — đúng cách và giới hạn của nó

Laravel làm đúng chuẩn. RedisLock::acquire() (Illuminate/Cache/RedisLock.php:37):

return $this->redis->set($this->name, $this->owner, 'EX', $this->seconds, 'NX') == true;

Còn release() chạy Lua kiểm tra owner rồi mới xoá (LuaScripts::releaseLock()):

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

Vì sao phải kiểm tra owner — chạy thật tình huống lock hết hạn khi A còn đang làm:

A lay lock PX 1000:              OK
# A bi cham 1,2 giay (GC, query lau, goi API ngoai)
B lay lock (A chua xong):        OK       # lock cua A da het han
A release bang Lua check owner:  0        # dung: khong xoa lock cua B
lock hien tai:                   ownerB
A release bang DEL tho:          1        # SAI: xoa mat lock cua B

Cache::lock()->forceRelease() của Laravel chính là DEL thô (RedisLock.php:75). Chỉ dùng khi dọn lock kẹt bằng tay.

Giới hạn: kiểm tra owner không cứu được việc A đang ghi

Lua release chỉ bảo vệ được lock. Nó không ngăn A tiếp tục làm việc và ghi vào DB trong lúc B cũng đang ghi. Lock trên Redis chỉ nói "gần như chắc chỉ có một người". Có ba lý do nó không bao giờ tuyệt đối:

1. Lock hết hạn khi người giữ còn đang chạy (vừa đo ở trên).
2. Failover mất lock (mục 1.5): A lấy lock trên master, master chết trước khi replicate, B lấy được lock trên master mới.
3. Đồng hồ và pause: process bị treo (GC, swap) không biết mình đã quá hạn.

Việc cần đúng tuyệt đối thì chặn ở chỗ ghi cuối cùng: fencing token (mỗi lần cấp lock kèm một số tăng dần, DB từ chối số cũ: UPDATE ... SET fence = :t WHERE id = :id AND fence < :t), hoặc đơn giản là unique constraint / optimistic locking trong DB (xem Optimistic locking). Redlock (lấy lock trên đa số N instance) giảm được lý do 2 nhưng không giải quyết lý do 1 và 3 — đây là tranh cãi nổi tiếng giữa Martin Kleppmann và tác giả Redis; bài này không dựng Redlock để kiểm chứng.

1.8. Pub/Sub, List, Stream — gửi tin nhắn qua Redis

$ redis-cli PUBLISH tmp:ch hello
(integer) 0              # 0 nguoi nghe -> tin nhan bien mat, khong luu lai

1.9. Kết nối từ Laravel — số connection, retry, Sentinel

maxclients mặc định là 10000. Hết chỗ thì connection mới bị từ chối ngay. Đo với maxclients 3 và 4 client đang giữ BLPOP:

$ redis-cli PING
ERR max number of clients reached

Số connection lúc cao điểm ≈ (số PHP-FPM worker × số node app) + queue worker + Horizon + cron. Mặc định mỗi request PHP-FPM mở connection rồi đóng. Bật REDIS_PERSISTENT=true thì mỗi worker giữ connection suốt đời process, nên tổng connection luôn bằng tổng worker, kể cả lúc rảnh. Scale thêm node app là nhân số này lên. Công thức là suy ra, chưa đo trên cụm thật.

2. Lợi ích

3. Tác hại / hạn chế — danh sách bẫy đầy đủ

4. Trade-off — chọn cái nào

Redis hay thứ khác

Tiêu chí chọn cấu hình

5. Khó khăn khi vận hành thực tế

Stack monitoring sẵn có trong môi trường này (monitor-redis-exporter + Prometheus + Grafana) xuất được hầu hết các chỉ số trên. Công cụ khi đang xử lý sự cố: redis-cli --bigkeys, --memkeys, --hotkeys (chỉ chạy với policy LFU), SLOWLOG GET, CLIENT LIST (ai đang giữ connection).

• Con người: developer quen redis-cli KEYS * trên máy local sẽ gõ y như vậy trên production. Chặn bằng ACL, đừng dựa vào trí nhớ.
• Chi phí: RAM đắt hơn đĩa nhiều lần. Có persistence thì phải để dư RAM cho fork. Có HA thì nhân 2–3 lần số máy.
• Debug 3h sáng: Redis không có "lịch sử" như DB. Key hết hạn là mất dấu. Việc quan trọng phải log ở app (key, giá trị, thời điểm).

6. Case thực tế và cách xử lý

Case 1 — Latency giật lên vài trăm ms, đều đặn theo chu kỳ

Triệu chứng: p99 của app giật lên theo chu kỳ, trùng với lịch chụp RDB.

1. INFO persistence → xem latest_fork_usec. Hàng trăm nghìn micro giây là thủ phạm.
2. Xem INFO memory: dataset bao nhiêu GB, máy còn dư bao nhiêu RAM.
3. Chữa: chuyển việc chụp RDB sang replica (master tắt save), giãn lịch chụp, tắt Transparent Huge Pages trên máy chủ, chia dataset nếu quá lớn.

Case 2 — Mọi request timeout vài giây, rồi tự hết

Triệu chứng: không deploy gì, không tăng traffic, toàn site treo 2–3 giây.

1. SLOWLOG GET 20 → thấy KEYS * từ một script debug, hoặc DEL một key lớn.
2. CLIENT LIST tìm ai chạy (địa chỉ IP, tên client).
3. Chữa: ACL chặn @dangerous cho user của app và user của người; bật lazyfree-lazy-user-del yes; tìm big key bằng --bigkeys và chia nhỏ.

Case 3 — Sau khi Redis failover, một job gửi email chạy 2 lần, một đơn bị trùng

Nguyên nhân: lock Cache::lock('send-report') hoặc idempotency key được ghi trên master, master chết trước khi replicate (bẫy 9) → master mới không có lock → process thứ hai lấy được lock.

1. Xác nhận: log của Sentinel có sự kiện failover đúng thời điểm.
2. Dọn hậu quả: tìm bản ghi trùng trong DB theo idempotency key / job id.
3. Chữa gốc: job phải idempotent (kiểm tra "đã gửi chưa" trong DB); đơn hàng có unique constraint ở DB. Redis lock chỉ là lớp giảm tải, không phải lớp đảm bảo.

Case 4 — Toàn bộ người dùng lỗi 500: "OOM command not allowed"

Nguyên nhân: instance session/queue dùng noeviction và đã đầy — thường do có key không TTL (session "remember me" quá dài, job failed tích tụ) hoặc một big key.

1. Chặn máu: tăng maxmemory tạm thời nếu máy còn RAM (CONFIG SET maxmemory).
2. redis-cli --memkeys / --bigkeys tìm key chiếm RAM; SCAN tìm key TTL -1 không lẽ ra phải có.
3. Xoá bằng UNLINK, sửa code đặt TTL, thêm alert used_memory > 80%.

Case 5 — Chạy php artisan cache:clear, người dùng bị đăng xuất hết

Nguyên nhân: cache store và session dùng chung một Redis DB. RedisStore::flush() gọi FLUSHDB trên DB đó (Illuminate/Cache/RedisStore.php:284, bẫy 16).

Config mặc định của Laravel đã tách sẵn: connection default dùng REDIS_DB=0 (session, queue), connection cache dùng REDIS_CACHE_DB=1. Lỗi này chỉ xảy ra khi ai đó đặt hai biến bằng nhau, hoặc khi chuyển sang Redis Cluster — chỉ có DB 0, nên mọi thứ tự nhiên dồn vào một DB. Đo trên lab cluster: Cache::flush chạy FLUSHDB trên từng master, và queue {default} đang có 1 job thì còn 0.

1. Kiểm tra .env: REDIS_DB và REDIS_CACHE_DB có trùng không; session dùng connection nào (SESSION_CONNECTION trong config/session.php).
2. Tách DB số khác nhau, hoặc instance khác nhau (bắt buộc nếu dùng Cluster).
3. Bỏ cache:clear khỏi mọi script deploy. Cần xoá thì xoá theo key/prefix bằng SCAN + UNLINK.

Case 8 — Sau khi Redis failover, app báo READONLY liên tục

Triệu chứng: Sentinel đã bầu master mới từ lâu, nhưng log Laravel vẫn đầy READONLY You can't write against a read only replica., user bị đăng xuất, một số giỏ hàng/session mất.

1. Xác nhận: REDIS_CLIENT=phpredis với REDIS_HOST là IP/host của master cũ. SENTINEL get-master-addr-by-name trả địa chỉ khác.
2. Chặn máu: đổi REDIS_HOST sang master mới, chạy php artisan config:cache, reload PHP-FPM và restart queue worker (worker giữ connection cũ).
3. Đánh giá mất mát: write vào master cũ trong lúc nó tự nhận master đã bị full sync xoá (lab mất 52–112 write). Việc gì Redis là nguồn sự thật thì phải đối chiếu lại với DB.
4. Chữa gốc: chuyển sang predis + sentinel (bỏ options.cluster), hoặc endpoint cố định; đặt timeout; bật persistence hoặc replicaof trong config file để master cũ không tự nhận master khi boot.

Case 6 — RAM còn dư mà mọi lệnh ghi đều lỗi MISCONF

Triệu chứng: log Laravel đầy MISCONF Redis is configured to save RDB snapshots..., người dùng không đăng nhập được, nhưng used_memory vẫn thấp.

1. INFO persistence → rdb_last_bgsave_status:err. Log Redis cho biết lý do: Failed opening the temp RDB file ... Permission denied, đĩa đầy, hoặc fork lỗi.
2. Chặn máu: sửa nguyên nhân (dọn đĩa, sửa quyền) rồi chạy BGSAVE lại. Nếu instance chỉ là cache thì CONFIG SET save "" ngay để site chạy lại.
3. Chữa gốc: ghi cấu hình vào file (CONFIG SET sẽ mất khi restart, trừ khi chạy CONFIG REWRITE); thêm alert rdb_last_bgsave_status và dung lượng đĩa.

Case 7 — RAM Redis tăng gấp mấy lần sau một lần deploy, số key không đổi

Nguyên nhân: tiến độ sinh viên đang được gom theo bucket. Bản mới thêm field last_lesson_title (có tên bài dài hơn 64 byte), hoặc thêm field làm bucket vượt 512 field → bucket thành hashtable (mục 1.2).

1. redis-cli --memkeys hoặc MEMORY USAGE progress:0 trên vài bucket; OBJECT ENCODING trả hashtable là đúng bệnh.
2. Sửa code: chỉ lưu lesson_id, hoặc giảm cỡ bucket bằng tên key mới progress:v2:{id / 150}.
3. Ghi song song v1 và v2, đọc v2 và fallback về v1. Xong thì xoá v1 bằng SCAN + UNLINK. Bucket đã thành hashtable không tự gọn lại nên phải ghi lại. Không nâng ngưỡng khi chưa đo CPU.

7. Câu hỏi phụ interviewer hay hỏi tiếp

Tóm tắt

1. Một luồng chạy lệnh: KEYS, DEL key lớn, Lua dài làm đứng cả server. Dùng SCAN, UNLINK, script ngắn.
2. Bộ nhớ: cache dùng allkeys-lru; state (session, lock, queue, idempotency) dùng instance riêng noeviction + alert. Luôn đặt maxmemory (mặc định 0). Hàng triệu object nhỏ thì gom bucket, nhưng giữ dưới ngưỡng listpack (số field và 64 byte mỗi value).
3. Độ bền: RDB mất vài phút, AOF everysec mất ~1 giây, replication async mất write đã OK khi failover. Redis không phải nguồn sự thật cho dữ liệu nghiệp vụ.
4. Lock: SET NX EX + token + Lua release (hoặc DELEX IFEQ). Đúng tuyệt đối thì phải chặn ở DB.
5. HA với Laravel: phpredis không biết Sentinel — dùng predis + sentinel (bỏ options.cluster) hoặc endpoint cố định. Cluster: queue phải là {tên}, không gọi keys. Luôn đặt timeout.
6. Atomic: pipeline không atomic, MULTI không rollback, Lua atomic nhưng chặn server.

Đọc thêm: Cache nâng cao, Idempotency key ở Redis, Chống double-submit, Bộ công cụ vận hành.