Redis 是單執行緒的記憶體內資料結構伺服器。本篇講它自己怎麼跑、怎麼活過重啟、怎麼從一台長成一群——不重講應用層怎麼 Cache-Aside。

把 Redis 當「比較快的 Memcached」會漏掉它真正的契約：命令在單一事件迴圈裡依序執行，資料以型別與編碼住在行程記憶體裡，持久化、複寫、叢集都是這份記憶體的外掛，不是另一套資料庫。應用層讀寫模式（Cache-Aside、Write-Through）已經在 快取策略 講完；穿透、擊穿、雪崩的防護在 快取失效模式與雪崩防護。本篇站在 Redis 行程內部：執行模型、編碼、落盤、主從、slot、maxmemory。

flowchart LR
    C["Client"] --> E["單執行緒事件迴圈"]
    E --> M["記憶體資料結構"]
    M -. "fork 後背景寫出" .-> P["RDB / AOF"]
    M -. "命令流 + backlog" .-> R["Replica / Cluster"]
  

所有命令都穿過同一條單執行緒事件迴圈；持久化與複寫是掛在記憶體之後的兩條旁路（虛線），不在命令的關鍵路徑上——這也是為什麼一個 O(N) 命令就能卡住全部人，而 AOF rewrite 卻只在 fork 那一瞬間才痛。

所有命令走同一條迴圈。延遲不是「機器慢」，是上一條命令還沒做完。

Redis 主執行緒用 I/O 多工（epoll／kqueue）收 socket，從輸入緩衝區解析出一條 RESP 命令，執行，再把回覆寫回。執行期間不切換到下一條命令。這讓每個 key 的操作天然原子——INCR 不需要應用層鎖——代價是：一條 O(N) 命令會讓後面所有客戶端一起排隊。

1 · 哪些命令是延遲炸彈

O(N) 的 N 是「這個結構有多少元素」，不是「你有多少台機器」。集群切再細，單一 Hash 百萬 field 仍會卡住那一台的迴圈。

2 · Redis 6 的 I/O threads 不解這個契約

I/O threads 只分擔 socket 讀寫：把位元組從網卡搬進緩衝、把回覆寫出去。命令執行、物件編碼、過期抽樣、eviction 候選，仍在主執行緒。io-threads-do-reads 打開之後，benchmark 的吞吐量會升，但 KEYS 照樣阻塞所有人。

對外四種常用型別，對內各有兩套編碼。記憶體帳單在編碼，不在型別名。

同一個「使用者資料」，SET user:1 "{json}"、HSET user:1 name …、ZADD rank score member 佔的記憶體與能做的查詢完全不同。選型規則是：先列出要做的操作（單點讀、欄位更新、範圍、成員測試），再選型別；最後確認編碼會不會在資料長大時從緊湊結構升級成散列表／跳表。

listpack／intset 是為了 CPU cache 與指標開銷：小集合連續存放。一旦超過 hash-max-listpack-entries 等閾值，就變成真正的 hashtable／skiplist，記憶體會跳一截——這是「昨天還好好的，今天 RSS 爆了」的常見原因。

左欄是選型時該按的順序（先問操作、再選型別、最後才看編碼閾值），右欄是同一個決定在記憶體上的代價。對照著看會發現：真正讓 RSS 跳一截的不是 payload，而是超過閾值後從 listpack／intset 換成 hashtable／skiplist 所帶來的指標開銷。

記憶體是真相來源；RDB 與 AOF 是兩種不同的「死了能救回多少」契約。

不開持久化的 Redis 重啟後是空的——這對純快取可以接受（回填交給應用，見 快取策略）。一旦 Redis 被當成 session、佇列、排行榜的權威，你必須回答兩個問題：崩潰時最多丟多久的資料，以及重啟要多久才能再接寫。

兩欄的分野是「崩潰之後還剩什麼」：RDB 給的是一個完整但過去的時間點，AOF 給的是一條可重放的命令流。看 AOF 那欄的 appendfsync 三行——資料安全的刻度就在那裡，其餘都是還原速度與檔案大小的取捨。

兩種都開時，重啟預設以 AOF 為準（它更新）。面試答「開了 RDB 就不會丟資料」是錯的：RDB 保證的是「有一份過去的完整點」，不是「最後一筆寫入還在」。

Replica 複製的是 Redis 自己的命令流與 backlog，不是通用的 quorum 協議。Sentinel 只決定誰變成 master。

一主多從是 Redis 最常見的高可用形狀：寫進 master，replica 用非同步命令流追上。通用的同步／異步取捨與「讀到什麼」的一致性光譜，資料複寫基礎 已經講過。這裡只留下 Redis 專屬的三個旋鈕：PSYNC 能否部分重同步、replica lag 怎麼觀測、Sentinel 如何選主而避免腦裂。

1 · 全量 SYNC 與部分 PSYNC

flowchart TD
    A["Replica 重新連上"] --> B["送 PSYNC + offset"]
    B --> D{"offset 還在 backlog？"}
    D -- "是" --> E["部分重同步"]
    D -- "否" --> F["master fork RDB"]
    F --> G["期間寫入進 backlog"]
    G --> E
  

分岔點只有一個：replica 的 replication offset 是否還落在 master 的 repl_backlog 窗口內。掉出窗口（長斷線、backlog 太小、master 重啟換了 runid）的帳單是 master 再 fork 一份 RDB——這才是「replica 閃斷會拖垮 master」的來源。

Master 維持一份固定大小的 repl_backlog。Replica 短暫斷線後，若它的 replication offset 仍在 backlog 窗口內，就只補那一段（PSYNC）。窗口外——長斷線、backlog 太小、master 重啟換了 runid——就走全量：master 再 fork 一份 RDB 傳過去，期間寫入仍進 backlog，傳完再補增量。全量期間 master 的 CPU、fork、網路都是帳單；這是「為什麼 replica 閃斷會拖垮 master」的原因。

2 · 延遲觀測與寫入保護

• INFO replication 的 master_repl_offset 與 replica 的 slave_repl_offset 相減，就是以位元組計的落後。
• master_last_io_seconds_ago 看連線是否活著；offset 接近但秒數很大，常常是沒寫入，不是健康。
• min-replicas-to-write + min-replicas-max-lag：落後超過閾值的 replica 不計入，寫入會被拒絕。這是 Redis 版的「不要在沒有足夠新複本時承認寫入」——不是 quorum 協議，是 master 自己數人頭。
• 讀 replica 預設可能讀到舊值。需要讀已確認寫入，讀 master，或在應用層等 offset。

3 · Sentinel 故障轉移

Sentinel 是一組獨立行程，對同一份 Redis 拓撲做監控。主觀下線（SDOWN）只是「我連不上」；客觀下線（ODOWN）要達到設定的 quorum 個 Sentinel 同意。然後 Sentinel 之間再選一個 leader 來執行 failover：挑 replica（看優先級、offset、runid）、SLAVEOF NO ONE、通知其他 replica 改追新主、通知客戶端。

左欄是讓「多數派存在且唯一」的設定，右欄是這組設定沒做對時的長相。重點在右欄第一行：腦裂的成因不是 Sentinel 數量不夠，而是舊主在分區另一側仍然接受寫入——所以要靠 min-replicas-to-write 這類寫入保護把它自己關掉。

Cluster 把 keyspace 切成固定 16384 個 slot。遷移的單位是 slot，客戶端靠 MOVED 與 ASK 找到新家。

一致性雜湊用 ring 與虛擬節點，讓節點增減時只搬鄰近的 key——那是 一致性雜湊 的題。Redis Cluster 不走那條路：它預先切好 16384 個槽，每個槽指到一台主節點。新增節點 = 從既有節點搬走一些槽；刪節點 = 把它的槽交給別人。Hash 函式只決定 key 進哪一槽，不決定槽在哪一台機器。

花括號 hash tag 讓相關 key 進同一槽：{user:100}:profile 與 {user:100}:cart 都只雜湊 user:100，於是 MULTI／WATCH 這類單槽事務才可能成立。沒有 tag 的跨 key 事務，Cluster 會直接拒。

1 · 客戶端必須是 cluster-aware

客戶端本地快取一份 slot → node 對照表。第一次可以對任意節點下命令；之後靠兩種重定向自我修正：

L4 負載平衡把連線打到隨機節點，卻期望「永遠打對槽」，會讓每一條命令都先被 MOVED 一次。正確做法是 client-side 對照表，或懂 cluster 協定的 L7 proxy。

2 · 線上遷移：MIGRATING / IMPORTING

管理員把 slot 7 從節點 A 遷到 C 時，A 標成 MIGRATING，C 標成 IMPORTING，然後一把一把 MIGRATE（實作上接近 DUMP → RESTORE → DEL）。期間：

• key 還在 A：A 直接服務。客戶端對照表仍指向 A，這是 HIT。
• key 已到 C：A 回 ASK C。客戶端這一次去 C；沒更新對照表。
• 整槽搬完、SETSLOT 7 NODE C：歸屬切到 C。之後任何人問 A，得到 MOVED C，對照表才改。

sequenceDiagram
    participant CL as Client
    participant A as 節點 A
    participant C as 節點 C
    Note over CL,C: 遷移中：A MIGRATING、C IMPORTING
    CL->>A: GET cart:42，對照表指向 A
    A-->>CL: ASK C
    CL->>C: ASKING + GET
    C-->>CL: 回值
    Note over CL: 對照表不變，下一次仍先問 A
    Note over CL,C: SETSLOT 7 NODE C 之後
    CL->>A: GET cart:42，對照表仍指向 A
    A-->>CL: MOVED C
    CL->>C: GET cart:42
    C-->>CL: 回值
    Note over CL: 對照表改寫，之後直打 C
  

兩趟都先打到 A，差別在回程之後：ASK 不改對照表，下一次仍先問 A；MOVED 才讓客戶端把 slot 7 記到 C。所以 ASK 是「這一次借道」，MOVED 是「歸屬換人」。

3 · 互動：在 16384 格上看歸屬、傾斜與重定向

三個可驗的點：(1) 加一台的搬遷量正好是 16384 ÷ 新節點數——Redis 只從既有各節點的尾端切走要給新節點的那一份，其餘 slot 不動，所以新節點在格帶上是好幾段同色而不是一整條；這與一致性雜湊的鄰近重映射殊途同歸，但靠的是固定對照表。(2) 同一把 key 在遷移進度 0%／中途／100% 會依序得到 HIT、ASK、MOVED，三者由「它的 slot 排在遷移清單的第幾格」算出。(3) 「正在搬的那一格裡，這把 key 到底搬走了沒」現實中取決於 MIGRATE 跑到哪；本 demo 為了可重現，改用該 key 的 CRC16 落在 slot 索引之外的高位當代理規則（低 14 位就是 slot 本身，對同一格的所有 key 都相同，拿來當代理會讓整格答案一致）——所以同一格裡不同的 key 會拿到不同答案，這正是遷移窗口裡 MGET 會一半 ASK、一半本地的原因。

記憶體上限是硬牆。牆撞上時，Redis 不是變慢，是開始丟 key 或拒絕寫入。

maxmemory 把 RSS 目標設死。超過之後，下一個會增加記憶體的命令先走 eviction：依政策挑犧牲者，直到騰出空間，或發現政策不允許而回 OOM。這與 快取策略 裡「快取滿了用 LRU 踢」是同一類問題，但政策名稱與「哪些 key 有資格被踢」是 Redis 產品細節。

「session 設 TTL、排行榜不設」時用 volatile-*，撞牆只犧牲 session。兩邊都不設 TTL 卻開 volatile-lru，等價於 noeviction——這是上線後寫入突然 OOM 的經典誤配。

大 key 與熱 key

左右兩欄是兩種不同的病：左邊是單鍵太大（一次命令就卡住整條迴圈，複寫與 RDB 也被它拖住），右邊是單鍵太熱（key 不大，但流量全壓在同一個 slot 的同一台主節點）。看處置那一列就知道差別：大 key 要拆結構，熱 key 要複製或打散，兩者都不是加節點能解的。

同一份工作集、同一條存取軌跡，只換政策就換一整組犧牲者。這裡把「候選集合是誰」造成的差別算出來。

預設就停在最經典的誤配上：政策是 volatile-lru，但只有 40% 的 key 設了 expire——無 TTL 的那 60% 會慢慢佔滿記憶體且永遠不被選中，於是驅逐與 OOM 同時出現。把 TTL 比例拉到 0，數字會與 noeviction 一模一樣；切到 volatile-ttl，「被踢的是熱鍵嗎」那一列會跳上去，因為它挑的是 TTL 最短的，不是最冷的。另外兩點要誠實說明：真實 Redis 的 LRU／LFU 是 maxmemory-samples 取樣近似，本模擬用的是精確排序，所以實機的誤殺通常比這裡更多；「業務讀取命中率」刻意把掃描批次的存取排除，因為掃描本來就必然 miss，混在一起會蓋掉政策之間的差別。

先畫執行模型，再決定持久化與拓撲；Cluster 與 Sentinel 不要混成一句「開了高可用」。

本篇停在 Redis 行程與拓撲。下一步若走訊息骨幹，從 訊息佇列基礎 進；若走 API 契約，先備是 gRPC 與 Protocol Buffers。