本文是跨 vendor migration playbook、cross-link 到 Redis（source）跟 Valkey（target）。跑 6 維 diff dimension audit 後判定為 Type B drop-in（全維度 Low），結構走 6-section + 相容性 audit 前置。實機驗證於 valkey/valkey:8（valkey_version 8.1.8、redis_version 7.2.4）、最後檢查日 2026-06-16。

同一份程式碼、不同授權

多數 migration 的工作量在「source 跟 target 不一樣」——schema 要翻譯、API 要改、資料要轉。Redis → Valkey 幾乎沒有這個問題：Valkey 是 2024 年從 Redis 7.2.4 直接 fork 出來的，那一刻它跟 Redis 是 bit-for-bit 同一份程式碼。RDB 與 AOF 檔案格式相同（可以直接把 Redis 的資料目錄拷給 Valkey 載入）、RESP 協定相同、所有 Redis client library 不改一行就能連。技術上，這是 cache 領域最容易的遷移。

那為什麼要寫一篇 playbook？因為這個遷移的工作量不在資料層，在兩個別的地方。第一是授權——Redis 2024 改成 RSALv2 / SSPL（非 OSI 認可），Valkey 是 BSD 3-clause（OSI、Linux Foundation 治理），這個遷移的整個 driver 是授權合規，而合規驗證有它自己的流程。第二是fork 後的分歧——fork 那一刻兩者相同，但之後各自演進：Redis 加了 7.4+ 的新功能、Valkey 加了自己的（如 8.x 多執行緒），用到 fork 之後 Redis 新功能的部署會有相容缺口。

INFO server 上看得到這個「同源但分歧」的事實：

1valkey-cli INFO server | grep -E "redis_version|valkey_version"
2# redis_version:7.2.4    ← fork 點、client 以此判斷相容性（裝成 Redis 7.2.4）
3# valkey_version:8.1.8   ← Valkey 自己的演進線

redis_version:7.2.4 是相容性的保證（client 看到就以 Redis 7.2.4 行為運作）；valkey_version 是分歧的證據。這篇 playbook 處理的就是「資料層幾乎零工作、工作在授權與分歧盤點」的 drop-in 遷移。

6 維 diff dimension audit：為什麼是 Type B

跑 diff dimension audit，Redis → Valkey 全維度 Low：

全 Low → Type B drop-in（6-section + 相容性 audit 前置、週期 1-4 週）。跟同模組的 Redis → DragonflyDB 對照：DragonflyDB 是 C++ 重寫（drop-in 但 Lua / encoding / module 有差異），Valkey 是 fork（同源、連 RDB 檔都相容）——Valkey 的相容度比 DragonflyDB 更高，是 Type B 裡最純粹的一端。

這個遷移的特殊之處是 driver 在資料層之外：它是授權 / 合規驅動。依 migration 方法論 的漏類處理，政策 / 合規驅動的遷移資料層仍走 Type B，但 audit 重點多一塊授權驗證與證據收集。

相容性 audit：cutover 前要確認的清單

Valkey 號稱 100% 相容 Redis 7.2.4，但「100%」的邊界在 fork 之後的分歧。Pre-migration 必跑的 audit：

audit 的關鍵 output：兩份清單——(1) 用到的 Redis 7.4+ 功能（fork 後新增、Valkey 可能沒有）、(2) 載入的 Redis Stack module。這兩塊是僅有的相容風險，其餘資料層零工作。盤點方法：

1# 盤點載入的 module（最大相容風險）
2redis-cli MODULE LIST
3
4# 盤點是否用到 7.4+ 功能（抓 production traffic 對照 Redis 7.4 changelog）
5redis-cli MONITOR    # 限時抓樣、grep 可疑的新命令

Step-by-step cutover

因為 RDB 檔案相容，cutover 比 DragonflyDB 更簡單（無版本轉換風險）：

 1# 1. 部署 Valkey（同 Redis 配置、可直接沿用 redis.conf）
 2docker run -d --name valkey -p 6380:6379 \
 3  -v /data/valkey:/data \
 4  valkey/valkey:8 valkey-server /etc/valkey/valkey.conf
 5
 6# 2. Redis 端 BGSAVE 產生 RDB
 7redis-cli -h redis-primary BGSAVE
 8redis-cli -h redis-primary INFO Persistence | grep rdb_last_save_time
 9
10# 3. 把 dump.rdb 拷給 Valkey（檔案格式相容、無需轉換）
11scp redis-primary:/var/lib/redis/dump.rdb valkey-host:/data/valkey/
12
13# 4. 重啟 Valkey 載入 RDB
14docker restart valkey
15
16# 5. 驗證資料一致 + 版本
17valkey-cli -h valkey-host -p 6380 DBSIZE          # 對齊 Redis DBSIZE
18valkey-cli -h valkey-host -p 6380 INFO server | grep redis_version  # 7.2.4
19
20# 6. 替代方案（零停機）：用 replicaof 讓 Valkey 當 Redis 的 replica、即時同步後 promote
21#    valkey-cli -h valkey-host REPLICAOF redis-primary 6379
22#    重要邊界：此路徑只在 source 是 Redis 7.2 或更早版本時成立。
23#    Redis 7.4+（Community Edition）改了複製格式、Valkey 無法當其 replica
24#    → source 為 7.4+ 時改走上面的 RDB 拷貝路徑（步驟 2-4）。
25
26# 7. Cutover：client 配置切到 Valkey endpoint、Redis 留 standby

關鍵時間點：

• RDB 拷貝 + load：100GB 約 5-15 分鐘（無版本轉換、比 DragonflyDB 少一道風險）
• replicaof 路徑：要零停機可讓 Valkey 當 Redis replica 即時同步、確認 lag 趨零後 promote + 切 client（僅限 source 為 Redis 7.2 或更早；7.4+ 複製格式已分歧、不適用、改走 RDB 拷貝）
• Cutover：client 配置切換（單次完成、硬邊界）、Redis 留 standby 1-2 週
• Decom：無相容問題後關閉 Redis

Production 故障演練

Case 1：用到 Redis 7.4+ 功能、Valkey 沒有

徵兆：cutover 後某功能報 unknown command 或行為不同，命令是 Redis 在 7.4 之後（fork 點之後）才加的。

根因：Valkey fork 自 Redis 7.2.4，Redis 7.4+ 新增的功能 Valkey 不一定跟進。pre-migration audit 漏掉了這些 fork 後的新功能。

修法：

1. pre-migration 對照 Redis 7.4+ changelog 盤點用到的新功能（audit 清單第一項）
2. Valkey 有對應就確認版本、沒有就評估改寫或留在 Redis 商業版
3. 多數標準 cache 用法不碰 7.4+ 新功能，這個風險集中在用了較新進階功能的部署
4. Valkey 自己的 roadmap（valkey.io）會逐步補上 Redis 新功能，可追蹤

Case 2：載入了 Redis Stack 商業 module

徵兆：cutover 後 JSON.SET / FT.SEARCH 報 unknown command，application 部分功能失效。

根因：用了 Redis Stack 的商業 module（RedisJSON / RedisSearch），這些不在 fork 範圍。Valkey 有自己的 valkey-search / valkey-bloom，但不是同一套命令、要另外安裝。

修法：

1. pre-migration MODULE LIST 盤點所有載入的 module（audit 清單第二項）
2. 確認 Valkey 對應替代（valkey-search 對 RedisSearch）、確認命令相容度
3. 沒有對應的評估改 module-free 設計（JSON 操作拉回 application 層）或留在 Redis Inc 商業版
4. 對應 Valkey 相容性 deep article 的三層相容邊界

Case 3：以為換 Valkey 解決了記憶體 / fork 問題

徵兆：因為 Redis 的 OOM 或 fork 延遲尖峰而遷 Valkey，遷完發現同樣問題還在。

根因：Valkey fork 自 Redis 7.2.4，繼承了完全相同的記憶體模型、eviction 演算法、AOF/RDB fork 機制。這些行為在 Valkey 上一模一樣——遷移沒有改變它們。

修法：

1. 記憶體 / fork 調校在 Valkey 上跟 Redis 完全相同，直接套用 Redis 記憶體調校 與 persistence / fork latency
2. 遷 Valkey 的理由應是授權合規 / 多執行緒吞吐 / managed 成本，不是記憶體問題
3. fork 尖峰要根治走 DragonflyDB 的 fork-less，不是換 Valkey
4. 遷移前釐清痛點是授權（Valkey 解）還是架構（Valkey 不解）

Case 4：授權合規驗證沒做完整、合規卡關

徵兆：技術遷移完成、但法務 / 合規 review 要求證明「不再使用 RSALv2 / SSPL 授權的軟體」，缺少證據。

根因：這個遷移的 driver 是授權合規，但團隊只做了技術 cutover、沒收集合規證據。Redis 的 binary / image / 相依套件若還殘留在某些環境，合規目標沒真正達成。

修法：

1. 盤點所有環境（dev / staging / prod / CI）的 Redis binary / image / 相依，確認全部換成 Valkey
2. 收集合規證據：image SBOM、套件清單、部署 manifest 顯示 Valkey BSD 授權
3. 把「不再使用非 OSI 授權 cache」寫成可驗證的 CI 檢查（掃 image / 依賴）
4. 依 migration 方法論 的合規驅動漏類，audit 重點就是 evidence collection

Case 5：監控 dashboard 部分指標斷掉

徵兆：cutover 後 RedisInsight 或某監控 dashboard 部分面板空白、vendor-specific 命令回錯。

根因：RedisInsight 等 Redis Inc 工具有部分偏商業版的命令，Valkey 不一定實作。核心指標通用，但進階面板可能缺。

修法：

1. 監控改用通用工具：valkey-cli INFO、Prometheus + redis_exporter（相容 Valkey）、Grafana
2. 核心指標（used_memory / keyspace_hits / connected_clients）在 Valkey 完全相容、覆蓋不受影響
3. 把監控相容性納入 cutover 前驗證、不要遷完才發現面板空白
4. RedisInsight 連 Valkey 多數仍可用、只是部分 vendor 進階面板缺

Capacity / cost 對照

判讀：合規敏感（公部門 / 企業 OSI 政策）或想降 managed 成本 → 遷 Valkey（drop-in、風險集中在 module / 7.4+ 盤點）；重度依賴 Redis Stack 商業 module → 留 Redis Inc 商業版。

整合 / 下一步

跟 ElastiCache for Valkey 對位

AWS 已把 ElastiCache default engine 設為 Valkey（約低 Redis 20%）。自管 Redis → ElastiCache for Valkey 是「換授權 + 轉 managed」一次到位，但要同時處理 managed 責任邊界（failover / cluster mode / client 重連）。

跟 client / 監控整合

client library 零改（透過 redis_version 協商）；監控把 exporter 指向 Valkey 即可（redis_exporter 相容）、RedisInsight 部分面板需換通用工具。

跟 Valkey 8 多執行緒對位

遷移後可評估開 Valkey 8 的 io-threads 榨多核吞吐（Redis 7.2.4 沒有的能力），見 Valkey 相容性與 io-threads deep article。

下一步議題

• 反向遷移（Valkey → Redis）：僅在重度依賴 Redis 7.4+ 功能或 Stack 商業 module 時需要、同樣 drop-in
• 跨雲 managed Valkey：GCP Memorystore / Azure Cache 的 Valkey 支援陸續推出、評估 vendor boundary
• 授權合規 CI 化：把「不使用非 OSI 授權 cache」寫成持續檢查

相關連結

• Source vendor：Redis
• Target vendor：Valkey
• 平行 migration playbook：Redis → DragonflyDB（重寫型 drop-in）、Redis → Memcached
• Methodology：Migration playbook methodology（Type B drop-in + 合規驅動漏類）

本文是跨 vendor migration playbook、cross-link 到 Redis（source）跟 DragonflyDB（target）。跟前一篇 Splunk → Elastic Security 的 6-phase playbook 對照、Redis → DragonflyDB 是 drop-in 相容 形態的 migration、結構更接近 vendor deep article methodology 的 6-section flow + 一段「相容性驗證」前置。

為什麼遷：cost / single-thread / multi-tenancy 三條 driver

反向 driver（DragonflyDB → Redis）也存在 — 主要是 Redis Modules 依賴（RedisJSON / RedisSearch / RedisGraph）DragonflyDB 不支援、或 Lua script 用了 redis.call 進階 API。

跟 phased migration 的對照：drop-in 不需要 phased

跟前一篇 Splunk → Elastic 的 6-phase playbook 不同、Redis → DragonflyDB 的 migration 結構接近 standard deep article：

判斷依據：migration 結構由 source 跟 target 的 schema / protocol 差異程度 決定、不是 universal phased playbook。本批第 2 篇驗證 deep article methodology 的 6-section 框架 在 drop-in migration 仍適用（只需前置 相容性驗證 段、其他 6 段對位）。

相容性驗證：在 cutover 前要確認的清單

DragonflyDB 號稱 Redis drop-in、但「drop-in」涵蓋範圍依 Redis feature 使用程度而定。Pre-migration 必跑的相容性 audit：

Audit 的關鍵 output：列「不相容功能」清單 + 對應 application code 修改範圍；若 Modules 在 production 使用、migration 退役。

Step-by-step cutover

 1# 1. 部署 DragonflyDB
 2docker run -d --name dragonfly -p 6380:6379 \
 3  -v /data/dragonfly:/data \
 4  docker.dragonflydb.io/dragonflydb/dragonfly:latest \
 5  --logtostderr --requirepass=<your_password>
 6
 7# 2. Redis 端 BGSAVE
 8redis-cli -h redis-primary BGSAVE
 9# 等到 BGSAVE 完成
10redis-cli -h redis-primary INFO Persistence | grep rdb_last_save_time
11
12# 3. 把 dump.rdb 拷到 DragonflyDB
13scp redis-primary:/var/lib/redis/dump.rdb dragonfly-host:/data/dragonfly/
14
15# 4. 重啟 DragonflyDB 載入 RDB
16docker restart dragonfly
17
18# 5. 驗證資料一致
19redis-cli -h dragonfly-host -p 6380 DBSIZE
20redis-cli -h redis-primary DBSIZE
21# 兩端 key 數對齊
22
23# 6. Dual-write 1-7 天（application 同時寫兩端）
24# 7. Read 切換到 DragonflyDB、Redis 端只寫不讀
25# 8. Write 切換、Redis 端 standby
26# 9. 觀察 1-2 週、無異常後 Redis decommission

關鍵時間點：

• BGSAVE → load：100GB RDB 約 5-15 分鐘、跨網路 SCP 時間另算
• Dual-write window：1-7 天觀察、application 寫兩端、read 仍走 Redis
• Cutover：read switch → write switch、每步間隔 24 小時
• Decom：Redis 保留 standby 1-2 週、無異常後關閉

Production 故障演練

Case 1：RDB 版本差，DragonflyDB load 失敗

徵兆：Redis 7.2 端 BGSAVE 出的 dump.rdb 在 DragonflyDB load 時報 Unsupported RDB version、DragonflyDB 啟動失敗。

根因：Redis 7.2 RDB version 11 含新 feature（function library / sharded pubsub）DragonflyDB 當前 release 沒支援；版本相容性需逐 release 確認。

修法：

1. Pre-migration 版本相容矩陣 audit：DragonflyDB release note 對照 Redis version、確認 RDB version 支援
2. 降級 BGSAVE：Redis 端設 rdb-version 9（Redis 6.x 兼容版本）、犧牲 Redis 7.x 新 feature
3. 替代方案：用 redis-cli --scan + MIGRATE 命令 incremental 搬、不用 RDB；速度慢 100x 但相容性好

Case 2：Lua script 跑進 EVAL 不一致

徵兆：dual-write 階段、發現某些 EVAL script 在 Redis 跟 DragonflyDB 結果不同；具體是某個 redis.call("OBJECT", "ENCODING", key) 在 DragonflyDB 回不一樣的 encoding 字串。

根因：DragonflyDB 內部不用 Redis 的 ziplist / listpack encoding（dashtable 不需要）、OBJECT ENCODING 返回值不對等；script 邏輯依賴 encoding 來決定行為、結果不同。

修法：

1. Audit Lua script：grep 所有 redis.call("OBJECT"、列出依賴 encoding 的 script
2. 改寫 application：不依賴 encoding、改用 MEMORY USAGE 或 high-level check
3. 接受差異：DragonflyDB 不會回 encoding 但 functional 結果對等、SOC review 確認可接受

Case 3：Pub/Sub fanout 高負載 latency

徵兆：production 切到 DragonflyDB 後、Pub/Sub 訂閱端 latency p99 從 5ms 漲到 20-50ms；topic fanout >10K subscriber 場景。

根因：DragonflyDB 多 thread 設計、Pub/Sub message 在 thread 間 dispatch 需要 routing；Redis single-thread 沒這個 overhead。高 fanout 是 DragonflyDB 設計取捨。

修法：

1. 架構：高 fanout Pub/Sub 不用 DragonflyDB、改 NATS / Redis Streams + consumer group
2. DragonflyDB 配置調整：--proactor_threads 對 Pub/Sub 影響大、調到符合 CPU 核心數
3. 接受 latency：< 10K subscriber 差異可忽略、不必動

Case 4：Cluster mode 看似相容但 slot routing 行為差

徵兆：application 用 Redis Cluster client（lettuce / Jedis cluster mode）連 DragonflyDB emulated cluster、運行幾天後 MOVED redirect 異常、key 找不到。

根因：DragonflyDB emulated cluster mode 是 single node 模擬、CLUSTER SLOTS 返回固定 mapping；某些 client 端 cluster topology cache 跟實際 routing 不對齊、發 redirect。

修法：

1. Application 改 standalone client：DragonflyDB single node 已能達 cluster 級 throughput、不必用 cluster client
2. Client config：lettuce 端 clusterTopologyRefreshOptions(...) 設較長 refresh、減少 redirect 機會
3. 長期：等 DragonflyDB cluster 正式 GA 後再評估

Case 5：Modules 用了沒注意，migration 卡住

徵兆：cutover 後幾天、application 某個功能完全壞、log 顯示 ERR unknown command 'JSON.SET'；DragonflyDB 不支援 RedisJSON。

根因：Pre-migration audit 漏掉 application 用了 RedisJSON（透過某 client library 抽象）；DragonflyDB 不支援該 Module 命令、application 直接壞。

修法：

1. Pre-migration audit 必跑：MONITOR 抓 1 小時 production traffic、grep 非 standard command（JSON.* / FT.* / GRAPH.*）
2. 應急回退：Redis standby 還在、application client config 切回
3. 長期：JSON 改用 standard Hash + serialization、Search 改 Elasticsearch / Meilisearch、Graph 改 Neo4j

Capacity / cost 對照

判讀：cache use case 簡單（pure cache / session store）走 DragonflyDB；複雜 use case（Modules / Pub/Sub fanout / strict durability）保留 Redis。

整合 / 下一步

跟 client library 整合

主流 Redis client（lettuce / Jedis / redis-py / node-redis / go-redis）都直接相容 DragonflyDB；唯一例外是 cluster client 模式行為差（見 Case 4）。

跟 monitoring 整合

DragonflyDB exporter 提供 Prometheus metric、跟 Redis exporter 對應 metric 名稱 80% 相同；grafana dashboard 需小改：

• redis_memory_used_bytes → dragonfly_memory_used_bytes
• redis_commands_processed_total → dragonfly_commands_processed_total

跟 Redis Sentinel HA 對位

DragonflyDB 不直接支援 Sentinel、HA 走自家 master-replica + DNS-based failover：

1. DragonflyDB primary + replica
2. K8s 用 StatefulSet + Service + readiness probe
3. 失敗 failover 比 Sentinel 慢（30s-2min vs 5-15s）

下一步議題

• DragonflyDB Cluster GA：正式 cluster mode 出來後重評估
• Stream + consumer group 細節：dual-write 期間驗證每個 consumer pattern
• Modules 替代方案：JSON / Search / Graph 各自的 cloud-native 替代評估

相關連結

• Source vendor：Redis
• Target vendor：DragonflyDB
• 平行 migration playbook：Splunk → Elastic Security
• Methodology：Vendor 深度技術文章的寫作方法論

本文是跨 vendor migration playbook、cross-link Redis 跟 Memcached。跑 migration-playbook-methodology 6 維 audit 後對映 Paradigm = High（multi-paradigm → pure cache）→ Type E paradigm shift；本文是 paradigm reduction（downgrade 方向）的 dogfood。

Memcached 不是 simpler Redis、是 cache paradigm

把 Redis → Memcached 當「移除 Redis 功能」是最常見的誤判：

核心差異不在「Memcached 少了 Redis 功能」、在「Memcached 是不同的 cache paradigm」。 Redis 的 features（hash / sorted set / pub/sub）多數 不該移除、是 重新分配到對應 specialized service：

• Hash / sorted set → application 端用 JSON + 自管 index
• Pub/Sub → message queue（NATS / Redis Streams / Kafka）
• Lua scripts → application code
• Persistence → 真正需要的 data 該存 DB、不是 cache
• Replication / cluster → Memcached 自己 cluster strategy

為什麼遷：simplification / cost / ops 三條 driver

• Operational simplification：Memcached 沒 persistence / replication / cluster mode、ops surface 縮小、團隊不用懂 Redis 25+ command family
• Cost：對 純 cache use case 而言、Memcached 每 GB 比 Redis 便宜（memory efficiency 略勝 + 無 persistence overhead）
• Strict cache discipline：Memcached 逼 application code 把「真正的 cache」跟「半 persistent state」分開、避免 Redis 變 poor man’s database

反向 driver（Memcached → Redis）：

• Application 寫到 Memcached 後發現需要 atomic counter / leaderboard / queue / lock、應該升 Redis（不是繼續 wrap Memcached）

跑 6 維 audit

3 維 High（Schema / Paradigm / Application change）多軸高、主導維度 = Paradigm → Type E paradigm shift；Schema + Application change 抽獨立段補充。

結構：類 Type E + paradigm reduction 分配路線

 11. Memcached 不是 simpler Redis（concept reverse 開頭）
 22. 為什麼遷
 33. 6 維 audit
 44. Paradigm reduction 路線（Redis features 對應的 specialized service）
 55. Schema 差段（Redis vs Memcached command set）
 66. Application 重設計（per-call-site refactor）
 77. Migration 流程（漸進、部分 use case 切）
 88. Production 故障演練
 99. Capacity / cost
1010. 整合 / 下一步

10 章節、220-260 行。比 Type E（Kafka ↔ NATS）多 paradigm reduction 路線 段。

Paradigm reduction 路線

Redis features 對應的 specialized service：

 1Redis Hash           → Application 端 JSON.stringify + Memcached SET
 2                       (or 直接存 DB + Memcached cache layer)
 3
 4Redis List (queue)   → NATS / Kafka / RabbitMQ / SQS
 5
 6Redis List (stack)   → Application 端用 array + 自管 LIFO
 7
 8Redis Set            → Application 端用 array + dedup OR 用 DB unique index
 9
10Redis Sorted Set     → Application 端用 ordered list + comparator
11                       OR PostgreSQL + index
12
13Redis Stream         → Kafka / Redis Streams (保留) / NATS JetStream
14
15Redis Pub/Sub        → NATS Core / Redis Streams / Kafka
16
17Redis Lua script     → Application code（避免 atomic 假設）
18
19Redis distributed lock → Consul / etcd / DB advisory lock / Redis (保留)
20
21Redis Bitmap         → DB bit column / 應用端 bitset
22
23Redis HyperLogLog    → DB approx_count_distinct / 應用端 cardinality estimator

Migration scope 包含 每個 Redis-specific feature use case 對應的 service 評估；不是「移除」、是「重新分配」。

Application 重設計

 1# Before: Redis hash
 2redis.hset('user:123', 'email', 'a@b.com')
 3redis.hset('user:123', 'name', 'Alice')
 4user = redis.hgetall('user:123')
 5
 6# After: Memcached + JSON
 7import json
 8user_data = {'email': 'a@b.com', 'name': 'Alice'}
 9mc.set('user:123', json.dumps(user_data))
10user = json.loads(mc.get('user:123') or '{}')

1# Before: Redis sorted set (leaderboard)
2redis.zadd('leaderboard', {'alice': 100, 'bob': 95})
3top_10 = redis.zrevrange('leaderboard', 0, 9, withscores=True)
4
5# After: PostgreSQL + index + Memcached cache
6# Persistent: write to DB
7# Cache: pre-compute top 10 in DB query, cache in Memcached
8mc.set('leaderboard:top10', json.dumps(db.query('SELECT user, score FROM scores ORDER BY score DESC LIMIT 10')))

1# Before: Redis distributed lock
2with redis.lock('resource:1', timeout=10):
3    process_resource()
4
5# After: PostgreSQL advisory lock OR Consul session
6with db.advisory_lock(resource_id):
7    process_resource()

每個 Redis-specific pattern 都要 per-call-site refactor、不是 SDK 換。

Migration 流程

跟 Kafka ↔ NATS 同 partial migration：

 11. Audit application code、列所有 Redis call site + feature 使用
 22. 按 feature 分類處理 plan:
 3   - Pure KV (GET/SET/DEL/TTL): 切 Memcached 直接
 4   - Hash → JSON + Memcached: per-call-site refactor
 5   - List/Sorted Set: 評估是 queue / leaderboard / 其他用途、對應 service
 6   - Pub/Sub: 移到 message queue
 7   - Lock: 移到 DB 或保留 Redis
 83. 部分 application 先切（純 KV use case）
 94. 複雜 use case 逐步 refactor 到對應 service
105. Memcached 跑 production 後、Redis 可降為 *narrow scope*（只跑剩餘 Redis-specific feature）
11   或完全退役（如果 application 已 refactor 乾淨）
126. 長期混合架構：Memcached cache layer + DB persistent state + 可選的 Redis（locks / specialty）

整體 3-12 個月、依 Redis-specific feature 使用深度。

Production 故障演練

Case 1：Hash → JSON 後 GET/SET round-trip 變 N+1

徵兆：cutover 後 application latency p99 從 5ms 漲到 50ms；profiling 顯示「為了改 user.email、要先 GET user object → modify → SET」、原本 Redis HSET 1 個 round-trip 現在 2 個。

根因：JSON-encoded value 不能 partial update、每次改一欄都要 read-modify-write。

修法：

1. Application 端 cache JSON object in memory：read-modify-write 仍 1 個 SET、但 read 是 memory
2. Compare-and-swap (CAS)：Memcached CAS 防止 concurrent update lost
3. Field-level cache key：把 hash 拆成 N 個 Memcached key（user:123:email / user:123:name）、避開 JSON

Case 2：Sorted set leaderboard 退化、recomputation cost 爆

徵兆：原本 Redis leaderboard ZADD + ZREVRANGE < 1ms；切 DB-backed leaderboard 後 SELECT ... ORDER BY ... LIMIT 10 在 1M+ row 跑 100-500ms。

根因：Memcached 不支援 sorted set、leaderboard 必須在 DB 算、N 大時 sort 慢。

修法：

1. Cache pre-computed top N：DB scheduled job 每分鐘算 top 100、寫 Memcached、application 讀 cache 不直查 DB
2. Materialized view + index：DB 端用 materialized view + index、毫秒級 query
3. 保留 Redis sorted set：leaderboard 是 Redis 強項、不該退到 Memcached、走混合架構

Case 3：Pub/Sub 移除、缺 fan-out 機制

徵兆：原本 Redis Pub/Sub 跑 cache invalidation broadcast、N 個 application instance 都收 invalidation msg；切 Memcached 後失去 broadcast、cache stale。

根因：Memcached 沒 Pub/Sub；application 需要外部 fan-out 機制。

修法：

1. NATS / Redis Streams + consumer group：each application instance 是 consumer、收 invalidation
2. Database trigger + LISTEN/NOTIFY：PostgreSQL LISTEN/NOTIFY 對中型 fan-out 足夠
3. Architecture rethink：是否真需要 broadcast invalidation？通常用 TTL-based cache + cache key versioning 就能 cover 多數 invalidation use case

Case 4：Atomic INCR 沒對等、race condition

徵兆：rate limiter / counter pattern 切 Memcached、mc.incr(key) 在 key 不存在時 return None（不 auto-init 為 0）；application 端 if None: mc.set(key, 1) race condition、低機率 counter reset。

根因：Memcached INCR 對 missing key 不像 Redis 自動 init；application 端 init logic 容易 race。

修法：

1# 用 ADD（atomic put-if-absent）
2mc.add(key, 0)  # only sets if missing
3mc.incr(key)    # always works after add

ADD + INCR 兩個 atomic operation 合起來 race-free。

Case 5：Eviction policy 差異、production cache hit rate 降

徵兆：cutover 後 cache hit rate 從 95% 降到 80%；profiling 發現「重要 key 沒在 cache」、新 key 一直擠走熱 key。

根因：Redis 預設 allkeys-lfu (least frequently used)、長期熱 key 不被擠；Memcached 只有 LRU、單純按 access time、burst access 的 cold key 擠走 long-tail hot key。

修法：

1. Memory headroom：Memcached memory 限制拉高 30-50%、避免 eviction pressure
2. Application-side cache priority：critical key 用 no-expiration set + 主動 refresh
3. 保留 Redis for LFU workload：long-tail hot key 場景 Redis LFU 更合適、不該退 Memcached

Capacity / cost

判讀：純 cache use case 走 Memcached 省 ops + 略省 cost；application 已用 Redis-specific feature 不該切；混合架構是 long-term default。

整合 / 下一步

跟 Redis → DragonflyDB 對比

兩條路：

• DragonflyDB：保留 Redis paradigm、優化 throughput + memory；application 不用改
• Memcached：退到 pure cache paradigm、application 必須改、但 ops 簡化

選擇取決於 是否真的需要 Redis multi-paradigm features：用得到就 DragonflyDB / Redis、用不到就 Memcached。

跟 NATS 整合

Redis Pub/Sub 移除後、應用端 fan-out / messaging 需求轉到 NATS / Redis Streams / Kafka；本文 cross-link migration playbook Kafka ↔ NATS 有 paradigm shift 流程參考。

下一步議題

• Memcached Cluster strategy：client-side consistent hashing vs server-side cluster mode、ops 簡化 vs scalability 取捨
• Long-term mixed architecture：80% Memcached + 20% Redis 是常見 stable state、不一定要完全消除 Redis

相關連結

• Source vendor：Redis
• Target vendor：Memcached
• 平行 migration playbook (Type E)：Kafka ↔ NATS / PostgreSQL → CockroachDB
• 平行 Type B 對照：Redis → DragonflyDB（保留 paradigm）
• Methodology：Migration playbook methodology

本文是 Redis overview 的 implementation-layer deep article。本文是 Migration playbook methodology 「何時不該套」段的第 3 項實證（容量重新規劃 / re-sharding）— source / target 同 vendor 同 cluster、但 data topology 重劃、不在 5 type 內。

Source = Target，但 topology 重劃

Migration 通常假設 source 跟 target 是不同 cluster / vendor；re-sharding 是 同 cluster 內的 slot 重分配、source 跟 target 是 同一個 Redis Cluster 的不同 state：

1Before re-shard:
2  Cluster A: [node1: slots 0-5460] [node2: slots 5461-10921] [node3: slots 10922-16383]
3              ~ 33% load           ~ 50% load              ~ 17% load (heavy imbalance)
4
5After re-shard:
6  Cluster A: [node1: slots 0-4095] [node2: slots 4096-8191] [node3: slots 8192-12287] [node4: slots 12288-16383]
7              ~ 25% load           ~ 25% load              ~ 25% load              ~ 25% load

source 跟 target 是 同 cluster、區別在 slot 對 node 的 mapping。Application connection string 不變、cluster API 不變、data model 不變。但 slot migration 期間 application 行為跟 normal operation 差很多 — 這是 re-sharding 主要工作。

跑 diff dimension audit 對 Redis cluster re-sharding：

5 維皆 Low、對映 Type B drop-in；但 data topology 是 5 type 沒有的 第 6 維度。本文採用 re-sharding-specific 結構、不是 5 type 任一個。

4 種 re-sharding driver

不同 driver 對應不同 re-sharding 策略：

前 3 種是 cluster-internal、用 redis-cli --cluster 工具完成；第 4 種需要 application 端 dual-write + migration、本文不展開。

Slot migration 機制

Redis Cluster 16384 個 slot、每個 key 經 CRC16(key) % 16384 對應 slot。Slot migration 過程：

 1Source node:     [slot N: MIGRATING to dest]
 2Dest node:       [slot N: IMPORTING from source]
 3                 ↓
 4Source node:     SCAN slot N → for each key:
 5                 1. DUMP key (serialize value)
 6                 2. send to dest via MIGRATE command
 7                 3. dest RESTORE key
 8                 4. source DEL key
 9                 ↓
10Source node:     [slot N: OWNED by dest]
11Dest node:       [slot N: OWNED]
12                 ↓
13跨 cluster broadcast: slot N 屬於 dest

期間 client 行為：

• Key 在 source 端（未 migrate）：source 直接 serve
• Key 在 dest 端（已 migrate）：source 回 -ASK redirect、client 重發到 dest
• 寫入 MIGRATING slot 的新 key：source serve、之後也會 migrate
• Application 不需要改 code、cluster-aware client 自動處理 -ASK redirect

redis-cli –cluster 工具

production 用 official tool、不要手寫 slot migration：

 1# 1. Rebalance（slot 重分配、適合 imbalance）
 2redis-cli --cluster rebalance 10.0.0.1:6379 \
 3  --cluster-use-empty-masters \
 4  --cluster-threshold 5
 5
 6# 2. Reshard（指定來源 → 目標、適合 capacity expansion）
 7redis-cli --cluster reshard 10.0.0.1:6379 \
 8  --cluster-from <source-node-id> \
 9  --cluster-to <dest-node-id> \
10  --cluster-slots 4096 \
11  --cluster-yes
12
13# 3. Add-node（加新 node 進 cluster）
14redis-cli --cluster add-node 10.0.0.4:6379 10.0.0.1:6379 \
15  --cluster-master-id <existing-master-id>
16
17# 4. Del-node（移除 node、需先 drain slot）
18redis-cli --cluster del-node 10.0.0.1:6379 <node-to-remove>

關鍵：

• --cluster-threshold 5：load 差異超過 5% 才 rebalance、避免反覆觸發
• --cluster-slots：一次 migrate 多少 slot；太大 lock 久、太小步驟多
• Rebalance / reshard 過程 cluster 仍 serve traffic、但 latency 升高（migration overhead）

5 段執行流程

 11. Pre-resharding analysis
 2   - 當前 slot 分佈跟 load
 3   - Hot key 識別（CLUSTER COUNTKEYSINSLOT）
 4   - 預估 migration 時間
 5
 62. Backup checkpoint
 7   - BGSAVE on all master
 8   - 確認 replica 跟得上（replication offset diff < 10MB）
 9
103. Execute re-sharding
11   - 用 redis-cli --cluster 工具
12   - Monitor cluster health（CLUSTER INFO + CLUSTER NODES）
13   - Migration 期間 application 端 latency baseline 比對
14
154. Verify
16   - Slot distribution 對 expected mapping
17   - Application traffic pattern 對 baseline
18   - 跑 cross-node sanity check
19
205. Cleanup
21   - 舊 node（若 decommission）reset / 釋放
22   - Monitoring dashboard 更新 (Prometheus target / Grafana panel)
23   - Document new topology

整體 1-7 天、依 cluster 大小（10GB ~ 1 小時、TB 級 1-3 天）。

Production 故障演練

Case 1：Cluster busy 期間 application timeout

徵兆：re-sharding 跑到一半、application 端開始大量 CLUSTER BUSY error / OOM warning / latency p99 從 5ms 跳到 200-2000ms；某些 batch operation 完全失敗。

根因：MIGRATE command 對單 key 是 blocking（DUMP + send + RESTORE + DEL atomic）— 大 value（HASH / SORTED SET / LIST 含 100K+ entry）migration 可能 lock node 數秒；同期間其他 query 阻塞。

修法：

1. Pre-resharding audit：MEMORY USAGE 跑 sample key、找 > 1MB 的 fat key、列出單獨處理
2. MIGRATE timeout 調：redis.conf 設 cluster-migration-timeout 10000（10s）、避免單 key migration 卡爆 cluster
3. 降低並行：--cluster-pipeline 1 一次只搬一個 slot（預設 10）、減少 CPU 壓力
4. Fat key refactor：production 不該有 1M+ entry 的 collection、refactor 拆分

Case 2：Replica lag during re-sharding

徵兆：reshard 完成後、replica 顯示 stale data 數分鐘、application 端 read from replica 拿到舊值。

根因：master 端 slot migration 產生大量 DEL + RESTORE 命令、replication stream 量爆、replica 跟不上、accumulated lag。

修法：

1. Pre-resharding 確認 replica lag < 5MB、否則先 fix replica issue 再開始
2. Throttle migration：用 --cluster-replace + lower pipeline、放慢 master 寫入速度
3. Application 端 read-write split policy：reshard 期間強制 read from master、暫時放棄 replica read
4. 預備計畫：若 lag > 30s 撐了 5+ 分鐘、考慮暫停 reshard、wait replica catch up

Case 3：Client-side topology cache stale

徵兆：reshard 完、application 端持續報 MOVED <slot> <new-node> redirect、但隔 30s 又 redirect 一次；某些 client 直接 connection refused（連到已 decommission node）。

根因：cluster-aware client（lettuce / Jedis cluster mode）有 topology cache、reshard 後不主動 refresh；遇 MOVED 後 refresh 一次、但 cache TTL 內可能繼續用舊 mapping。

修法：

1. Client config：lettuce clusterTopologyRefreshOptions(...) 設較短 refresh interval（60s）+ enablePeriodicRefresh()
2. Reshard 完後 trigger refresh：application 端可主動發 CLUSTER NODES 拿最新 topology、不依賴 client lib 自動 refresh
3. Graceful client shutdown / restart：對 latency-sensitive 服務、reshard 完 rolling restart application pod、避免 stale cache
4. Decommissioned node 保留 5 分鐘：不立刻 stop node、給 stale client 自然 retry 機會

Case 4：Cross-slot transaction 失敗

徵兆：application 用 MULTI/EXEC 跨多 key、reshard 期間部分 transaction 報 MOVED error、整個 transaction 失敗、business logic 不一致。

根因：Redis Cluster transaction 要求 所有 key 在同 slot（用 hash tag {user:123}）；reshard 期間如果 transaction 內某 key migrate 到 dest、cluster topology 暫時 inconsistent、transaction 拒絕。

修法：

1. Pre-resharding audit：grep application code 找 MULTI / pipeline 使用、確認所有都用 hash tag co-locate
2. Reshard 期間 application 端加 retry：transaction failure 後 backoff retry、cluster stabilize 後成功
3. 架構：transaction-heavy 場景考慮不用 Redis Cluster、用 Redis Sentinel single master（無 slot 概念）

Case 5：Monitor visibility gap during reshard

徵兆：reshard 期間 Prometheus dashboard 對某 node 的 metric 突然顯示 錯位 — load = 95% 但 slot count 顯示 6% slot；SOC 不知道 node 健康狀況。

根因：Prometheus exporter 對 slot count 跟 traffic load 分開計算；reshard 期間 slot count 已 migrate 但流量仍打 source node（client cache stale）— metric 看似矛盾。

修法：

1. Reshard 期間關 alert：knownmaintenance window、Prometheus silence alert
2. 加 reshard-aware metric：用 redis_cluster_migration_slots 量化 in-flight migration
3. Dashboard 加註解：reshard 期間 SOC 看 dashboard 知道是 normal anomaly

Capacity / cost

實務 default：

• 跑在 低流量時段（夜間 / 週末）
• Throughput 容忍度 < 50% 再 reshard、不要 80%+ 時操作
• 預留 回退 window — reshard 卡住時能 abort + 恢復原狀

整合 / 下一步

跟 Redis → DragonflyDB migration 對位

DragonflyDB 設計上 單機效能取代 cluster、re-sharding 議題消失；如果 cluster re-sharding 頻繁觸發、評估直接遷 DragonflyDB 是否更便宜。

跟 Sentinel HA 對比

Sentinel 模式無 slot 概念、re-sharding 不適用；但 manual sharding by application 場景仍可能需要類似 topology re-layout、application 端要自己處理。

跟 Redis 7+ Function / Cluster v2

Redis 7 推 Cluster v2 跟 Functions、slot migration 機制部分升級；keyspace migration 仍是核心議題、但 API 跟 monitoring 改進。

下一步議題

• Auto-rebalance via operator：Redis Enterprise / Aiven 等 managed Redis 提供自動 rebalance、不需手動觸發
• Cross-DC slot migration：跨 region cluster slot migration 對 latency / cost 影響大、通常用 application-level sharding 取代 cluster-level
• Hash tag 治理：application code grep / lint 強制 hash tag、避免 cross-slot transaction 反模式

相關連結

• 上游 vendor 頁：Redis
• 平行 migration playbook：Redis → DragonflyDB
• 對位 deep article：PostgreSQL major version upgrade（另一個 5 type 漏類驗證）
• Methodology：Vendor 深度技術文章的寫作方法論 / Migration playbook methodology（本文驗證 容量重劃漏類）

本文是 Redis overview 的 implementation-layer deep article。選型層（Redis vs Valkey vs Memcached）見 overview；本文只處理「已經選了 Redis、記憶體怎麼配才不會在尖峰爆掉」。配置以 Redis 官方 memory optimization 文件 為準、最後檢查日 2026-06-16。

你的 Redis 會在凌晨三點 OOM

Redis 的記憶體問題很少在有人盯著儀表板時發生。它發生在流量爬升、某個 key 集合悄悄長大、AOF rewrite 剛好撞上 RDB save 的那個瞬間——通常是凌晨三點，沒人盯著。徵兆是 application 端突然一片 OOM command not allowed when used memory > 'maxmemory'，所有寫入失敗，但讀取還活著，於是監控的「Redis 還在回應」綠燈騙過了 on-call。

這類事故的根因幾乎都不是「Redis 不夠快」，而是三個記憶體旋鈕在設計時被當成預設值放著沒動：maxmemory 設多少、maxmemory-policy 選哪個、以及沒人注意到的記憶體碎片化。這三個旋鈕決定了 Redis 在記憶體壓力下是「優雅地淘汰冷資料繼續服務」還是「拒絕所有寫入直到有人重啟」。本文處理這三者的會計模型、選型判讀，以及它們怎麼被寫成事故。

對延遲就是業務 KPI 的服務，這個旋鈕的代價更直接。Tinder 的配對引擎每次滑動要查多個快取（profile、距離、偏好、推薦池），4700 萬月活下 cache 不是 DB 的補救、是主要服務面，cache miss 是邊緣案例。eviction policy 選錯，淘汰掉的若是熱資料，下一次滑動就打回 origin，sub-millisecond 的延遲預算瞬間破表。

核心概念：Redis 記憶體的會計模型

要調校記憶體，先要分清楚 used_memory 這個數字到底由什麼組成。INFO memory 回報的是幾層疊加的記憶體會計，每一層去處不同：

used_memory 是 Redis allocator（預設 jemalloc）配給資料、結構與 buffer 的總量。used_memory_rss 是作業系統視角看到的 Redis 進程實體記憶體（resident set size），它通常大於 used_memory——兩者的比值就是 mem_fragmentation_ratio。used_memory_dataset 才是純資料的部分，扣掉了 Redis 自身的 overhead。

理解三個跟 OOM 直接相關的記憶體去處：

資料本身的編碼會放大或縮小記憶體。一個小 hash（field 數少於 hash-max-listpack-entries、value 短於 hash-max-listpack-value）用 listpack 緊湊編碼，記憶體可能只有大 hash 用 hashtable 編碼的幾分之一。同樣的邏輯套用在 list、set、sorted set。一個欄位設計的小決定（把 user object 拆成 200 個獨立 key 還是壓成一個 hash）會讓記憶體差好幾倍。

client output buffer 不計入 dataset 但會吃光記憶體。慢速 consumer、MONITOR、大量 pub/sub 訂閱者都會讓 Redis 在 server 端堆積 reply buffer。client-output-buffer-limit 沒設好，一個讀很慢的 replica 或一個掛著的 MONITOR 連線就能把記憶體推到 maxmemory。

fork 期間記憶體會短暫翻倍。RDB save 與 AOF rewrite 都靠 fork() + copy-on-write，父進程在 fork 後若持續寫入，被改動的 page 會被複製，最壞情況記憶體接近翻倍。這是 maxmemory 必須留 headroom 的核心原因，細節見 persistence 與 fork latency deep article。

maxmemory 框住的是 used_memory，不是 used_memory_rss。所以 maxmemory 設成機器 RAM 的 100% 是錯的——碎片化、fork copy-on-write、client buffer 都在 maxmemory 之外，會把 RSS 推爆系統，觸發 Linux OOM killer 直接砍掉 Redis 進程（比 Redis 自己的 noeviction 更糟，因為是無預警 SIGKILL）。

配置：maxmemory 與 policy 的設定路徑

設定分兩步：先框住記憶體上限，再決定撞到上限時的行為。

 1# 1. 設定記憶體上限（留 headroom 給 fork / fragmentation / client buffer）
 2# 機器 RAM 8GB → maxmemory 設 ~5-6GB、留 25-35% headroom
 3redis-cli CONFIG SET maxmemory 6gb
 4
 5# 2. 設定撞到上限時的淘汰行為
 6redis-cli CONFIG SET maxmemory-policy allkeys-lfu
 7
 8# 3. 永久化到 redis.conf（CONFIG SET 重啟後失效）
 9# redis.conf:
10#   maxmemory 6gb
11#   maxmemory-policy allkeys-lfu

八個 maxmemory-policy 選項分三類，選型靠「資料是不是全部都能淘汰」與「淘汰要靠存取頻率還是 TTL」兩個問題：

LRU 跟 LFU 的真實差異

allkeys-lru 跟 allkeys-lfu 看起來像同一件事的兩種寫法，但選錯會在特定 workload 下讓 hit rate 掉一截。LRU 看「最後一次被存取是多久以前」，LFU 看「被存取的頻率」。差別在一次性掃描（scan pollution）：某個批次任務一次讀過大量冷 key，LRU 會把這些剛被碰過的冷 key 排到淘汰隊伍最後面，反而把真正的熱 key 擠出去。LFU 因為看頻率，一次性的存取不會讓冷 key 假裝成熱 key。

Redis 4.0 後的 LFU 用的是 probabilistic counter（Morris counter）加 decay，不是精確計數，靠兩個參數調：

1# lfu-log-factor：counter 增長的對數速度、越大越能區分高頻 key
2redis-cli CONFIG SET lfu-log-factor 10
3# lfu-decay-time：counter 衰減的分鐘數、越小越快遺忘舊熱度
4redis-cli CONFIG SET lfu-decay-time 1

對 Tinder 這類有明顯熱資料（熱門 profile、熱區域推薦池）的服務，allkeys-lfu 比 allkeys-lru 更能保護熱 key 不被批次掃描或冷流量擠出。

approximate eviction 的取樣

Redis 的 LRU/LFU 都是近似演算法，不掃全 keyspace，而是每次取樣 maxmemory-samples 個 key（預設 5）挑最該淘汰的。樣本數越大越接近精確 LRU/LFU，但越吃 CPU。記憶體壓力大、淘汰頻繁時，預設 5 已夠；要更精準可調到 10，代價是淘汰路徑的 CPU 上升。

Production 故障演練

Case 1：noeviction 讓寫入全滅、讀取假裝健康

徵兆：application 寫入路徑大量 OOM command not allowed when used memory > 'maxmemory'，但 GET 仍正常、health check（通常打 PING 或 GET）綠燈，on-call 收到的是 application 層的 500、不是 Redis 告警。

根因：maxmemory-policy 預設是 noeviction。當 Redis 把 cache 當 cache 用，但 policy 留在 noeviction，記憶體一滿，所有會增加記憶體的命令（SET、LPUSH、HSET）直接報錯，唯讀命令照常。health check 若只測讀取，完全偵測不到。

修法：

1. 純 cache 場景把 policy 改成 allkeys-lru 或 allkeys-lfu，讓記憶體壓力自動透過淘汰釋放
2. health check 加一個寫入探針（SET healthcheck:probe <ts> EX 10），讓 OOM 寫入失敗能被偵測
3. 告警掛在 used_memory / maxmemory > 0.85，不要等 OOM 才反應
4. 若資料真的不能淘汰（誤把 Redis 當 source-of-truth），那不該用 cache 配置，見本文 Capacity / cost 邊界段的路由判斷

Case 2：碎片化吃掉 30% 記憶體

徵兆：used_memory 顯示 4GB、但 used_memory_rss 是 5.5GB，mem_fragmentation_ratio 是 1.37，機器 RAM 開始吃緊但資料量沒漲。重啟 Redis 後 RSS 掉回 4GB 出頭。

根因：大量寫入後刪除、或 value 大小頻繁變動（例如 list 一直 push/pop），jemalloc 的記憶體頁出現空洞——配出去的 page 還佔著 RSS，但裡面只有零星資料。mem_fragmentation_ratio 持續 > 1.5 是明確訊號。

修法：

1. 開 active defrag 讓 Redis 在背景整理（4.0+）：

   1redis-cli CONFIG SET activedefrag yes
   2redis-cli CONFIG SET active-defrag-ignore-bytes 100mb
   3redis-cli CONFIG SET active-defrag-threshold-lower 10

2. fragmentation_ratio < 1.0 是另一種警訊——代表 Redis 在用 swap，比碎片化更危險，要立刻降記憶體壓力

3. 結構選擇上避免大幅波動的 collection；穩態大小的資料碎片化天然較低

4. 計算 maxmemory headroom 時把 1.2-1.4 的 fragmentation 算進去

Case 3：一個 MONITOR 連線把記憶體推爆

徵兆：某次 debug 後記憶體莫名持續上升，used_memory_dataset 沒變但 used_memory 一直漲，CLIENT LIST 看到一個連線的 omem（output buffer memory）有幾百 MB。

根因：有人開了 MONITOR 去看即時命令流、然後忘了關（或 client crash 但連線沒斷）。MONITOR 把每一條命令都推給該連線，高 QPS 下 server 端 output buffer 爆量堆積，計入 used_memory 但不在 dataset。慢速 replica 或大量 pub/sub 訂閱者也會觸發同類問題。

修法：

1. 設定 client output buffer 上限，超過就斷線：

   1# normal client / replica / pubsub 分開設
   2redis-cli CONFIG SET client-output-buffer-limit "normal 256mb 64mb 60"
   3redis-cli CONFIG SET client-output-buffer-limit "pubsub 32mb 8mb 60"

2. MONITOR 在 production 嚴格禁用或限時，它本身也拖慢整個 server

3. 監控加 CLIENT LIST 的 omem 巡檢，找出異常 buffer 的連線

4. replica lag 過大時 output buffer 會堆，對應 replication / failover deep article

Case 4：欄位設計讓記憶體多用三倍

徵兆：資料筆數跟預估一致，但 used_memory 是試算的 3 倍。MEMORY USAGE <key> 抽樣發現單筆 object 的記憶體遠超 value 本身的 byte 數。

根因：把一個有 10 個欄位的 user object 拆成 10 個獨立 string key（user:123:name、user:123:age…），每個 key 都帶 Redis 的 key overhead（dict entry、expire dict entry、key 字串本身）。10 個 key 的 overhead 是一個 hash 的好幾倍。反過來，超過 hash-max-listpack-entries 的大 hash 從緊湊的 listpack 退化成 hashtable 編碼，也會放大記憶體。

修法：

1. 同一 entity 的欄位用一個 hash 存，共享 key overhead

2. 保持 hash 在 listpack 閾值內以用緊湊編碼：

   1redis-cli CONFIG GET hash-max-listpack-entries  # 預設 128
   2redis-cli CONFIG GET hash-max-listpack-value    # 預設 64

3. 用 MEMORY USAGE <key> 跟 redis-cli --bigkeys 抽樣驗證實際記憶體，不靠試算

4. Shopify 的 serialization 遷移（Marshal → MessagePack）正是用更省的編碼壓 payload，欄位編碼決策對記憶體與頻寬同時有效

Case 5：淘汰把熱 key 一起帶走、hit rate 崩

徵兆：記憶體壓力下開始 eviction（evicted_keys 持續上升），同時 keyspace_hits / (hits + misses) 從 95% 掉到 70%，origin QPS 跟著飆，下游 DB 開始吃緊。

根因：用了 allkeys-random，或 allkeys-lru 撞上批次掃描污染，淘汰演算法把熱 key 跟冷 key 一視同仁，熱 key 被淘汰後下一個請求 miss、回源、再寫回，形成淘汰與回填的拉鋸，hit rate 持續惡化。

修法：

1. 有明顯熱資料就用 allkeys-lfu，讓頻率高的 key 留下
2. 把 maxmemory-samples 調到 10 提高淘汰精準度
3. 根因常是記憶體真的不夠——evicted_keys 持續高代表 working set 超過 maxmemory，該擴容或分片，不是純調 policy 能解
4. 熱 key 本身過熱（單 key QPS 遠超其他）要走 local cache + Redis 兩層，對應 2.6 high concurrency

Capacity / cost 邊界

記憶體配置的容量判讀，核心是「working set 對 maxmemory 的比值」與「淘汰是否健康」：

撞牆後的路由判斷：

• 單機記憶體不夠、working set 持續超量：垂直擴容（換更大記憶體機型）是第一步，但有單機上限。超過後走 Redis Cluster 分片，把 keyspace 切到多 node。
• 想用 Redis API 但要極致單機記憶體效率：DragonflyDB 的 dashtable 在同 dataset 下通常比 Redis 省 20-40% 記憶體（依資料形狀、以官方 benchmark 為準），且單機多核能撐到 Redis 要靠 cluster 才能達到的規模——若 cluster re-sharding 頻繁觸發，評估直接遷 DragonflyDB 是否更省維運。
• 資料其實不能淘汰（被當 source-of-truth）：那它不是 cache，該走 durable store。AWS 生態下用 MemoryDB（Redis-compatible durable），或把正式狀態放回 database 模組。

整合 / 下一步

記憶體與淘汰是 Redis 運維的第一層旋鈕，但它跟其他子系統耦合：

• 跟 persistence / fork latency：fork 期間的 copy-on-write 是 maxmemory headroom 的主要消耗者，記憶體調校跟持久化調校必須一起看。
• 跟 TTL 與 eviction 概念：TTL 設計決定哪些 key 帶過期時間，直接影響 volatile-* policy 的淘汰範圍。
• 跟 cache stampede：大量 key 同時被淘汰或同時過期會引發回源雪崩，eviction 調校要跟 TTL jitter / singleflight 一起設計。
• 跟 Tubi 的 cache vs durable 選型：Tubi 把 ML feature store 從 ScyllaDB 遷到 ElastiCache，前提是「feature 可重新計算」——這個判斷決定了 eviction 是可接受的，記憶體調校才有意義。資料若不可重建，問題不在淘汰 policy，在選錯了儲存層。

相關連結

• 上游 vendor 頁：Redis
• 同 vendor deep article：persistence 與 fork latency、Cluster re-sharding
• 上游概念：2.3 TTL 與 eviction
• Methodology：Vendor 深度技術文章寫作方法論

本文是 Redis overview 的 implementation-layer deep article。持久化跟記憶體調校互相耦合（fork 的 copy-on-write 是 maxmemory headroom 的主要消耗者），兩篇建議一起讀。機制以 Redis persistence 官方文件 為準、最後檢查日 2026-06-16。

fork 那一瞬間

Redis 是單執行緒處理命令的，這是它延遲可預測的根基——直到它需要把記憶體裡的資料寫到磁碟。RDB snapshot 跟 AOF rewrite 都不能在主執行緒上慢慢做（會凍結所有命令），於是 Redis 的解法是 fork()：複製出一個子進程，由子進程把當下的記憶體快照寫到磁碟，主進程繼續服務。

問題在 fork() 本身不是免費的。Linux 的 fork() 要複製父進程的分頁表（page table），記憶體越大、分頁表越大，這個複製動作越久——而它發生在主執行緒上，是阻塞的。一個 20GB 的 Redis 實例，fork 可能凍結主執行緒數百毫秒到一秒。在這段時間裡，所有命令排隊，p99 延遲從 1ms 跳到 500ms+。

更糟的是 fork 之後。fork() 用 copy-on-write：子進程跟父進程共享實體分頁，直到某一方寫入才複製。子進程只讀（在寫 snapshot），但父進程持續服務寫入，每改一個分頁就觸發一次複製。寫入越密集、snapshot 跑越久，被複製的分頁越多，最壞情況記憶體接近翻倍。這就是為什麼 Redis 的 maxmemory 必須留 headroom——不是給資料，是給 fork 期間的分頁複製。

理解持久化，本質是理解「fork 的延遲尖峰」與「資料持久性」之間的取捨。本文按這條線展開機制、配置與踩坑。

核心概念：AOF 與 RDB 是兩種不同的持久性語意

Redis 的兩種持久化不是「二選一的同類選項」，它們回答的是不同問題。

RDB 是某個時間點的記憶體快照。它把整個 dataset 序列化成一個緊湊的二進位檔（dump.rdb）。優點是檔案小、還原快（直接載入記憶體）、fork 一次寫完。缺點是兩次 snapshot 之間的寫入會在崩潰時全部遺失——RDB 的持久性顆粒度是「上一次 save 到現在」，可能是幾分鐘的資料。

AOF 是命令的 append-only log。每個改變資料的命令（SET、LPUSH…）被追加到 log 檔，還原時重放整個 log。優點是持久性顆粒度細（最多丟 fsync 策略決定的一小段）。缺點是 log 會無限增長，需要定期 rewrite 壓縮——而 rewrite 也要 fork。

兩者的 fork 觸發點不同但機制相同：RDB 是 BGSAVE（手動或 save 規則觸發）fork，AOF 是 BGREWRITEAOF（log 太大時觸發）fork。兩個若同時跑，記憶體壓力疊加。

AOF 的 fsync 策略決定丟多少資料

AOF 寫 log 分兩步：先 write 到 OS 的 page cache，再 fsync 刷到磁碟。appendfsync 控制 fsync 頻率，這是持久性與延遲的核心旋鈕：

everysec 是多數場景的預設選擇——背景執行緒每秒 fsync，主執行緒不等磁碟，崩潰最多丟 1 秒。但要注意：當磁碟 I/O 飽和，背景 fsync 跑超過 1 秒沒完成，主執行緒會被迫等待（避免 buffer 無限堆積），這時延遲尖峰跟 always 一樣明顯。

混合持久化：RDB preamble + AOF tail

Redis 4.0 後的 aof-use-rdb-preamble yes（4.0+ 預設開）把兩者結合：AOF rewrite 時，先寫一段 RDB 格式的快照當前綴，後面接增量命令 log。還原時先快速載入 RDB preamble，再重放尾端的 log。這拿到了 RDB 的還原速度與 AOF 的細顆粒持久性，是目前的建議配置。

配置：持久化的設定路徑

 1# --- RDB snapshot 規則（多久 + 多少改動觸發 BGSAVE）---
 2# redis.conf:
 3#   save 900 1      # 900 秒內有 1 個 key 改動
 4#   save 300 100    # 300 秒內有 100 個改動
 5#   save 60 10000   # 60 秒內有 10000 個改動
 6# 純 cache 不需要 RDB 可關閉：
 7#   save ""
 8
 9# --- AOF 設定 ---
10redis-cli CONFIG SET appendonly yes
11redis-cli CONFIG SET appendfsync everysec
12# AOF rewrite 觸發條件：比上次 rewrite 大 100% 且至少 64MB
13redis-cli CONFIG SET auto-aof-rewrite-percentage 100
14redis-cli CONFIG SET auto-aof-rewrite-min-size 64mb
15# 混合持久化（4.0+ 預設）
16redis-cli CONFIG SET aof-use-rdb-preamble yes

降低 fork 衝擊的兩個系統層設定：

1# 1. 關閉 Transparent Huge Pages（THP）——THP 會讓 copy-on-write 以 2MB 為單位複製、放大 fork 後的記憶體與延遲
2echo never > /sys/kernel/mm/transparent_hugepage/enabled
3
4# 2. 允許 overcommit memory——fork 時 Linux 預設可能因 overcommit 檢查拒絕 fork、導致 BGSAVE 失敗
5# /etc/sysctl.conf:
6#   vm.overcommit_memory = 1

這兩個是 Redis 官方明確建議的系統設定，沒設好會直接讓 fork 失敗或放大延遲尖峰。

Production 故障演練

Case 1：BGSAVE 那一刻 p99 延遲尖峰

徵兆：監控上每隔一段時間（對齊 save 規則）出現規律的延遲尖峰，p99 從 2ms 跳到 300-800ms，持續一兩秒後恢復。INFO stats 的 latest_fork_usec 顯示某次 fork 花了 700000 微秒（0.7 秒）。

根因：大記憶體實例的 fork() 要複製分頁表，這個動作阻塞主執行緒。實例越大尖峰越明顯，THP 開著會更嚴重。

修法：

1. 確認 THP 關閉（最常見的放大原因）
2. 把 RDB save 規則放寬或關閉——純 cache 場景靠 AOF 或乾脆不持久化
3. 大實例考慮分片，把單實例記憶體降下來，fork 成本隨之降低
4. 在 replica 上做持久化（master 只服務、replica 負責 BGSAVE），把 fork 尖峰移出服務路徑

Case 2：fork 期間記憶體翻倍觸發 OOM

徵兆：BGSAVE 開始後記憶體快速上升，used_memory_rss 在 snapshot 期間衝高，撞到機器 RAM 上限，Linux OOM killer 把 redis-server 進程 SIGKILL，無預警下線。

根因：copy-on-write 在寫入密集期間複製大量分頁，maxmemory 沒留足夠 headroom。maxmemory 設成 RAM 的 90%+ 時，fork 期間的分頁複製把 RSS 推爆系統。

修法：

1. maxmemory 設成 RAM 的 60-70%，留 30-40% 給 fork copy-on-write（寫入越密集留越多）
2. 設 vm.overcommit_memory = 1 避免 fork 直接被拒
3. 在低寫入時段（夜間）排程 BGSAVE，減少 fork 期間被複製的分頁
4. 監控 latest_fork_usec 與 BGSAVE 期間的 RSS 峰值，跟 記憶體調校的 headroom 計算合看

Case 3：AOF everysec 在磁碟飽和時退化成 always

徵兆：平常延遲穩定，某段時間（通常伴隨大量寫入或磁碟被其他進程佔用）延遲全面上升，INFO 的 aof_delayed_fsync 計數持續增加。

根因：everysec 的背景 fsync 應該每秒完成，但磁碟 I/O 飽和時 fsync 跑超過 1 秒。Redis 為了不讓 AOF buffer 無限堆積，會在主執行緒上阻塞等 fsync 完成——everysec 在這個情境下退化成接近 always 的延遲行為。

修法：

1. 用獨立的高 IOPS 磁碟給 AOF（不要跟 OS / log / 其他服務共用 I/O）
2. 監控 aof_delayed_fsync，持續增加代表磁碟跟不上寫入
3. 評估 no-appendfsync-on-rewrite yes——AOF rewrite 期間暫停 fsync，避免 rewrite 的 I/O 跟 fsync 互搶（代價是 rewrite 期間崩潰丟更多）
4. 寫入吞吐超過單磁碟負荷是擴容訊號，不是調 fsync 能解

Case 4：AOF 檔尾損壞讓 Redis 起不來

徵兆：Redis 崩潰後重啟失敗，log 顯示 Bad file format reading the append only file，服務無法載入 AOF。

根因：崩潰發生在 AOF 寫到一半，最後一條命令只寫了部分 byte，AOF 檔尾不完整。Redis 預設 aof-load-truncated yes 應能容忍尾端截斷，但若損壞在中段（罕見的磁碟錯誤）或設了 aof-load-truncated no，載入直接失敗。

修法：

1. 確認 aof-load-truncated yes（預設），容忍尾端截斷自動修復
2. 中段損壞用 redis-check-aof --fix appendonly.aof 修復（會截掉損壞點之後的內容、有資料遺失）
3. 修復前先備份原 AOF 檔，不要直接覆蓋
4. 混合持久化下還原優先用 RDB preamble，降低純 AOF replay 的損壞風險

Case 5：以為有持久化、其實 BGSAVE 一直在失敗

徵兆：某次需要從 RDB 還原時發現 dump.rdb 是好幾天前的，期間的資料全沒了。回查 log 發現 BGSAVE 一直報 Can't save in background: fork: Cannot allocate memory。

根因：vm.overcommit_memory 是預設的 0，Linux 在 fork 時做嚴格的記憶體檢查——當 Redis 已用掉大半 RAM，fork 估算可能需要翻倍記憶體而被拒。BGSAVE 靜默失敗，RDB 停留在最後一次成功的版本，但沒人在看 log。

修法：

1. 設 vm.overcommit_memory = 1，讓 fork 在記憶體吃緊時仍能成功（靠 copy-on-write 實際不會真的翻倍）
2. 監控 rdb_last_bgsave_status 與 aof_last_bgrewrite_status，err 要立刻告警
3. 監控 rdb_last_save_time，距今太久代表持久化已停擺
4. 持久化的存在不等於可用——定期演練從備份還原，驗證 RDB / AOF 真的能載入

Capacity / cost 邊界

持久化的容量判讀，圍繞 fork 成本與磁碟負荷：

撞牆後的路由判斷：

• fork 尖峰無法接受、實例又必須大：把持久化移到 replica（master 純服務），或走 Cluster 分片降低單實例記憶體。
• 大記憶體下 fork 成本是結構性瓶頸：DragonflyDB 用 fork-less snapshot 機制，大記憶體場景的快照不付 fork 的延遲與記憶體翻倍代價——若 fork 尖峰是主要痛點，這是值得評估的架構替代。
• 需要真正的 source-of-truth 持久性（不是盡力而為）：Redis 持久化本質是 cache 的回填保險，不是交易級持久性。要強持久性走 MemoryDB（multi-AZ transaction log）或 database 模組。

整合 / 下一步

持久化決策的起點其實是一個選型問題：這份資料是 cache 還是 source-of-truth。

• 跟 記憶體調校：fork 的 copy-on-write 是 maxmemory headroom 的主要消耗者，兩者必須一起算。
• 跟 replication / failover：replica 是承接持久化負擔的地方，也是 fork 尖峰的替代執行點。
• 跟 Tubi 的 cache vs durable 選型：Tubi 把 ML feature store 從 ScyllaDB（durable）遷到 ElastiCache，判斷是「feature 可重新計算」——這正是「不需要持久化」的判斷，持久化配置應隨之簡化甚至關閉。反過來，若資料不可重建，問題在選錯儲存層，不在持久化調校。
• 跟 cache copy boundary：服務若把 Redis 當主要 serving layer，持久化決定了重啟後是冷啟動回源雪崩還是溫啟動，跟 stampede 防護直接相關。

相關連結

• 上游 vendor 頁：Redis
• 同 vendor deep article：記憶體與淘汰調校、Cluster re-sharding
• 上游概念：2.7 cache copy boundary
• Methodology：Vendor 深度技術文章寫作方法論

本文是 Redis overview 的 implementation-layer deep article。Sentinel 處理的是「單 master 容量夠、但 master 不能是單點」的 HA 場景；要橫向擴容超過單機記憶體則走 Cluster re-sharding，兩者解的問題不同。機制以 Redis Sentinel 官方文件 為準、最後檢查日 2026-06-16。

Failover 是一條時序鏈、不是一個瞬間

「master 掛了 Sentinel 會自動切換」這句話把 failover 講成一個原子動作，但真正在 production 出事時，問題永遠出在這條鏈的某一段卡住。把 failover 攤開成時序，才看得到延遲跟資料遺失藏在哪：

 1T0   master 失去回應
 2     ↓ (down-after-milliseconds)
 3T1   單一 Sentinel 標記 master 為 SDOWN（主觀下線）
 4     ↓ (Sentinel 之間互問)
 5T2   達到 quorum 數量的 Sentinel 同意 → ODOWN（客觀下線）
 6     ↓ (Sentinel 之間選出 leader 來主導 failover)
 7T3   leader Sentinel 從 replica 中挑一個當新 master
 8     ↓ (SLAVEOF NO ONE + 其他 replica 改指向新 master)
 9T4   新 master 提升完成
10     ↓ (Sentinel 廣播新 topology、更新 DNS / 通知 client)
11T5   client 發現新 master、重連、恢復寫入

從 T0 到 T5 的總時間決定了「寫入中斷多久」。每一段都有對應的旋鈕跟失敗模式：T0→T1 由 down-after-milliseconds 控制（太短誤判、太長反應慢）；T1→T2 由 quorum 設定控制（太低腦裂風險、太高切不動）；T4→T5 由 client 的 topology 感知能力控制。理解 failover 就是理解這條鏈的每一段。

對把 cache 當主要 serving layer 的服務，這條鏈的長度直接是業務中斷時間。Tinder 的配對引擎每次滑動讀多個 cache、cache miss 是邊緣案例——failover 期間若寫入中斷十幾秒，新寫入的 profile 互動全部 hang，sub-millisecond 的 SLA 在這幾秒徹底失守。這也是為什麼大規模服務多半走 managed multi-AZ failover（見 ElastiCache）而非自管 Sentinel。

核心概念：Sentinel 的判定模型

Sentinel 是獨立於 Redis 資料節點的監控進程，它的判定靠兩層共識避免單一 Sentinel 誤判。

SDOWN（Subjectively Down，主觀下線）：單一 Sentinel 在 down-after-milliseconds 內收不到 master 的有效回應（PING），就主觀認定它下線。這只是一個 Sentinel 的意見，不觸發 failover。

ODOWN（Objectively Down，客觀下線）：當標記 SDOWN 的 Sentinel 數量達到 quorum 設定值，master 被客觀認定下線。只有 master 的 ODOWN 才會觸發 failover（replica 的下線只標記不 failover）。

quorum 是「多少個 Sentinel 同意才算真的下線」，它跟「多少個 Sentinel 同意才能執行 failover」是兩個不同的數字——後者需要 Sentinel 的多數（majority），確保同時只有一個 leader 主導 failover，避免兩個 Sentinel 各自提升不同 replica 造成腦裂。

為什麼 Sentinel 要部署奇數個且至少三個：quorum 跟 majority 都需要足夠的 Sentinel 投票。兩個 Sentinel 無法在其中一個故障時達成 majority；三個才能容忍一個故障。Sentinel 應部署在不同故障域（不同 AZ / 機架），且不要跟 Redis 資料節點同生共死。

Sentinel 不是 proxy：client 不透過 Sentinel 讀寫資料。client 向 Sentinel 查詢「現在的 master 是誰」，拿到地址後直連 Redis。failover 後 client 必須重新向 Sentinel 查詢——這是 T4→T5 的關鍵，client library 要支援 Sentinel 模式才能自動完成。

配置：Sentinel 的設定路徑

最小三 Sentinel 配置，每個 Sentinel 一份 sentinel.conf：

 1# sentinel.conf
 2# 監控名為 mymaster 的 master、quorum=2（三個 Sentinel 中兩個同意算 ODOWN）
 3sentinel monitor mymaster 10.0.0.1 6379 2
 4
 5# 多久收不到回應算 SDOWN（5 秒）
 6sentinel down-after-milliseconds mymaster 5000
 7
 8# failover 後同時最多幾個 replica 去 resync 新 master
 9# 設 1 = 串行 resync、避免所有 replica 同時 resync 拖垮新 master
10sentinel parallel-syncs mymaster 1
11
12# failover 整體逾時（三分鐘內沒完成算失敗、可重試）
13sentinel failover-timeout mymaster 180000

啟動 Sentinel：

1redis-sentinel /path/to/sentinel.conf
2# 或 redis-server /path/to/sentinel.conf --sentinel

client 端要用 Sentinel-aware 連線（以 Python redis-py 為例）：

 1from redis.sentinel import Sentinel
 2
 3sentinel = Sentinel(
 4    [("10.0.0.10", 26379), ("10.0.0.11", 26379), ("10.0.0.12", 26379)],
 5    socket_timeout=0.5,
 6)
 7# 寫入走 master（failover 後自動重新發現）
 8master = sentinel.master_for("mymaster", socket_timeout=0.5)
 9master.set("key", "value")
10# 讀取可走 replica
11replica = sentinel.slave_for("mymaster", socket_timeout=0.5)
12replica.get("key")

關鍵：client 透過 master_for 拿到的是一個會在 failover 後重新查詢 Sentinel 的連線封裝，不是寫死的 IP。直接寫死 master IP 的 client 在 failover 後會持續連到死掉的舊 master。

防腦裂的兩個 master 端設定

Sentinel 選主的同時，要防止舊 master 復活後繼續接受寫入（split-brain）。在 Redis master 端設：

1# 至少要有 1 個 replica 連著、且 replica lag < 10 秒、master 才接受寫入
2redis-cli CONFIG SET min-replicas-to-write 1
3redis-cli CONFIG SET min-replicas-max-lag 10

這讓被網路隔離的舊 master（連不到 replica）自動停止接受寫入，避免它在隔離期間累積的寫入在復活後跟新 master 衝突。

Production 故障演練

Case 1：down-after 太短、網路抖動誤觸 failover

徵兆：master 其實沒死，只是一次短暫的網路抖動或 GC 暫停，Sentinel 卻觸發了 failover，造成一次不必要的中斷；甚至反覆 failover（flapping）。

根因：down-after-milliseconds 設太短（例如 1000ms），master 一個短暫的 STW GC 或跨 AZ 網路抖動就超過閾值，被誤判 SDOWN→ODOWN。

修法：

1. down-after-milliseconds 設成能容忍正常抖動的值（5000-10000ms 是常見起點），用實際 RTT 與 GC pause 分布反推
2. quorum 設成多數而非 1，要求多個 Sentinel 同時看到下線，過濾單一 Sentinel 的網路問題
3. Sentinel 跟 Redis 不要跨高延遲鏈路放，網路品質直接影響誤判率
4. 監控 failover 觸發頻率，flapping 是調參訊號

Case 2：failover 後 client 連到死掉的舊 master

徵兆：failover 完成、Sentinel 日誌顯示新 master 已提升，但部分 application 持續寫入失敗或寫到舊 master（資料進黑洞），CLIENT LIST 在新 master 上看不到這些 client。

根因：client 寫死了 master IP，或用的 client library 不支援 Sentinel 模式，failover 後不會重新向 Sentinel 查詢新 master。

修法：

1. client 一律用 Sentinel-aware 連線（master_for / lettuce 的 Sentinel 配置），不寫死 IP
2. 確認 client library 版本支援 Sentinel 且配置正確（連的是 Sentinel port 26379，不是 Redis 6379）
3. 對 latency-sensitive 服務，failover 後可主動 rolling restart application，清掉殘留連線
4. 設 min-replicas-to-write 讓被隔離的舊 master 自動停寫，即使 client 連上去也寫不進，避免資料進黑洞

Case 3：選到 lag 大的 replica、failover 丟資料

徵兆：failover 後發現最近幾秒的寫入不見了，新 master 的資料比預期舊。

根因：Redis replication 是非同步的，replica 之間 lag 不一。Sentinel 選主會優先選 lag 小的（靠 replica-priority 與複製 offset），但若所有 replica 都 lag 大（master 寫入遠快於複製），無論選哪個都會丟掉未複製的寫入。Sentinel 的 failover 保證可用性，不保證零資料遺失。

修法：

1. 設 min-replicas-to-write + min-replicas-max-lag，lag 過大時 master 主動停寫，限制資料遺失窗口
2. 監控 replication lag（master_repl_offset vs replica 的 offset），lag 持續大代表複製跟不上寫入，要降寫入或擴容
3. 用 replica-priority 把不適合當 master 的 replica（例如做備份的、跨區的）設成 0 排除
4. 需要零資料遺失的場景，Sentinel 的非同步複製不夠，走 MemoryDB 的 multi-AZ transaction log（強一致持久性）

Case 4：腦裂——舊 master 復活後雙寫衝突

徵兆：網路分區期間 Sentinel 提升了新 master，分區恢復後舊 master 回來，兩個 master 各自接受過寫入，資料出現衝突或舊 master 的寫入被覆蓋遺失。

根因：舊 master 在分區期間被隔離（連不到 Sentinel 多數），但 client 若還連得到它且它沒設停寫保護，就繼續接受寫入。分區恢復後舊 master 被降為 replica，它在分區期間的寫入被新 master 的資料覆蓋。

修法：

1. min-replicas-to-write 1 + min-replicas-max-lag 10 是核心防護——被隔離的舊 master 連不到 replica，自動停寫
2. Sentinel 部署在多數能存活的故障域，確保分區時多數 Sentinel 在新 master 那側
3. 接受 Redis 的 CAP 取捨：Sentinel 偏向可用性，極端分區下無法完全避免資料遺失，要強一致走別的儲存層
4. failover 後監控舊 master 復活的降級流程，確認它正確變成 replica 且 resync

Case 5：parallel-syncs 設太大、failover 後新 master 被 resync 拖垮

徵兆：failover 完成的瞬間新 master 延遲暴增、甚至短暫無回應，所有 replica 同時對它發起全量同步。

根因：parallel-syncs 設成大於 1（或等於 replica 數），failover 後所有 replica 同時對新 master 做 full resync。full resync 要新 master 做 BGSAVE（fork、見 persistence deep article）並把 RDB 傳給每個 replica，多個同時進行直接打爆新 master。

修法：

1. parallel-syncs 設 1，replica 串行 resync，犧牲一點恢復速度換新 master 不被拖垮
2. 確認 master 端 repl-backlog-size 夠大，讓短暫斷線的 replica 走部分同步（partial resync）而非全量
3. 監控 failover 後新 master 的 CPU / 記憶體，resync 期間是脆弱窗口
4. resync 的 fork 成本跟 記憶體 headroom 直接相關，新 master 也要留 fork 空間

Capacity / cost 邊界

Sentinel 的容量判讀，圍繞 failover 時間與資料遺失窗口：

撞牆後的路由判斷：

• 單 master 容量不夠（記憶體 / 吞吐超過單機）：Sentinel 解 HA 不解容量。要橫向擴容走 Redis Cluster，它自帶 sharding 與 per-shard failover。
• 不想自己運維 Sentinel 與 failover 演練：ElastiCache 的 Multi-AZ 自動 failover 把這條時序鏈託管，failover ~30 秒到幾分鐘，省掉 Sentinel 部署與調參，代價是 managed premium。
• 需要零資料遺失的強持久性：Sentinel 的非同步複製在 failover 時會丟未複製的寫入。要強一致走 MemoryDB 的 multi-AZ transaction log。

整合 / 下一步

Sentinel 是 HA 的一層，但它的每一段都跟其他子系統耦合：

• 跟 Cluster re-sharding：Sentinel 是「不分片的 HA」，Cluster 是「分片 + 每 shard 自帶 failover」。容量需求決定走哪條，本文是前者。
• 跟 persistence / fork latency：failover 後的 resync 靠 BGSAVE（fork），新 master 的 fork 成本是 resync 期間的脆弱點。
• 跟 記憶體調校：新 master 提升後要承接全部寫入並支援 replica resync 的 fork，記憶體 headroom 不能少。
• 跟 Meta cache consistency：failover / replica promotion 期間的 stale read 與一致性議題，是大規模 cache 治理的核心，Sentinel 的非同步複製是 stale window 的來源之一。

相關連結

• 上游 vendor 頁：Redis
• 同 vendor deep article：Cluster re-sharding、persistence 與 fork latency、記憶體與淘汰調校
• 平行 vendor：AWS ElastiCache（managed multi-AZ failover）
• Methodology：Vendor 深度技術文章寫作方法論

本文是 Redis overview 的 implementation-layer deep article。連線與往返是 application 端量到的延遲主因，跟 server 端的記憶體、持久化調校互補。pipeline 機制以 Redis pipelining 官方文件 為準、最後檢查日 2026-06-16。

延遲不在 Redis、在往返

把單一 GET 丟進 redis-cli --latency，會看到 server 端執行時間是微秒級。但 application 端的 APM 量到的 Redis 呼叫卻是 1-3ms。這個差距不是 Redis 變慢了，是網路往返（round-trip time，RTT）——命令從 application 送到 Redis、結果送回來，這趟來回就是毫秒級，而 Redis 的執行只佔其中一小部分。

這個認知翻轉了 Redis 優化的方向：當你的服務每個請求要打 10 個 Redis 命令，瓶頸不是 Redis 的吞吐，是 10 次 RTT 疊加成 10-30ms。pipelining 常被講成「批次發命令省效能」，但它真正消除的是 RTT 稅——把 10 次往返打包成 1 次往返，server 端執行時間幾乎不變，但 application 端延遲從 10×RTT 降到 1×RTT。

對每次互動要查多個 cache 的服務，這筆 RTT 稅是延遲預算的主要支出。Snap 在 multi-cloud 架構下的痛點正是這個放大版：application 在一個 cloud、cache 在另一個，每次 lookup 多吃 5-30ms 跨 cloud RTT，「5ms × 10 cache lookup = 50ms 額外延遲」。Snap 把 KeyDB 部署到同 cloud 減少跨 cloud RTT，本質就是降低往返稅。本文處理 RTT 的會計、連線池配置與 pipeline 的正確使用。

核心概念：RTT 會計與三種降稅手段

Redis 一次請求的延遲拆成三段：client 序列化 + 送出、網路往返（RTT）、server 執行。多數 cache 場景下 RTT 是主導項，server 執行可忽略。降低總延遲有三種手段，對應三種「省 RTT」的方式：

連線池消除「每次都建連線」的稅。建立 TCP 連線（三次握手）本身就是一趟 RTT，若還有 TLS 再加幾趟。每個請求都新建連線等於每次都付建連稅。連線池讓連線重用，把建連成本攤平到接近零。

pipelining 把 N 次 RTT 壓成 1 次。連續送 N 個命令而不等每個的回應，一次讀回 N 個結果。這要求這 N 個命令彼此無依賴（後一個不需要前一個的結果）。

Lua script / 多 key 命令把多操作合成 1 次往返且原子。當命令之間有依賴（讀了再決定怎麼寫），pipeline 不適用（後面的命令送出時前面的結果還沒回來），這時用 Lua script 把邏輯放到 server 端一次執行，省 RTT 又拿到原子性。

pipeline 跟 MULTI 是不同的東西

這兩個常被混淆，但解的問題不同：

pipeline 純粹是傳輸層優化，不保證原子性——pipeline 裡的命令在 server 端仍可能跟其他 client 的命令交錯。要原子性用 MULTI/EXEC 或 Lua。兩者也可以組合（在 pipeline 裡送 MULTI…EXEC）。

注意 Redis 的 MULTI/EXEC 不是關聯式 DB 的 transaction：執行期某命令出錯（例如對 string 做 list 操作）不會回滾已執行的命令，它沒有 rollback。

配置：連線池與 pipeline 的設定路徑

連線池配置（以 Python redis-py 為例，多數 client library 概念一致）：

 1import redis
 2
 3pool = redis.ConnectionPool(
 4    host="10.0.0.1", port=6379,
 5    max_connections=50,          # 池上限、依並發量與 Redis maxclients 反推
 6    socket_timeout=0.5,          # 單命令逾時（秒）——必設、否則慢命令拖垮 caller
 7    socket_connect_timeout=0.5,  # 建連逾時
 8    health_check_interval=30,    # 定期檢查連線存活、清掉壞連線
 9)
10r = redis.Redis(connection_pool=pool)

socket_timeout 是最常被遺漏卻最關鍵的設定——沒設逾時，一個慢命令或網路黑洞會讓 caller 無限等待，連鎖拖垮上游。

pipeline 的使用：

1# pipeline：N 個無依賴命令、一次往返
2pipe = r.pipeline(transaction=False)  # transaction=False 純 pipeline、不包 MULTI
3for uid in user_ids:                  # 假設要拿 100 個 user 的 profile
4    pipe.hgetall(f"user:{uid}")
5results = pipe.execute()              # 一次往返拿回 100 個結果

依賴型操作改用 Lua（命令間有讀後寫的依賴，pipeline 不適用）：

 1# 原子的 check-and-set：讀目前值、符合條件才更新——一次往返且原子
 2lua = """
 3local current = redis.call('GET', KEYS[1])
 4if current == ARGV[1] then
 5  redis.call('SET', KEYS[1], ARGV[2])
 6  return 1
 7end
 8return 0
 9"""
10cas = r.register_script(lua)
11cas(keys=["lock:resource"], args=["old_token", "new_token"])

MGET / MSET / HMGET 等原生多 key 命令是最簡單的省 RTT 手段——能用多 key 命令就不用 pipeline，更省事且原子。

Production 故障演練

Case 1：每請求新建連線、延遲全是建連稅

徵兆：Redis 呼叫延遲偏高且不穩，INFO stats 的 total_connections_received 速率極高（接近 QPS），Redis 的 connected_clients 反覆上下震盪。

根因：application 沒用連線池，或每個請求 redis.Redis(...) 重新建立 client。每次請求付一趟 TCP 握手（加 TLS 更多）的 RTT，建連稅疊在每個請求上。

修法：

1. 用連線池並重用，client 物件在 application 生命週期內共用，不是每請求建立
2. 短生命週期環境（Lambda / serverless）把連線池放在 handler 外（容器重用時連線存活）
3. 監控 total_connections_received 速率，遠高於合理重連頻率代表沒重用
4. TLS 場景的建連稅更高，連線重用的收益更大

Case 2：沒設 socket_timeout、一個慢命令拖垮整條鏈

徵兆：某次 Redis 短暫卡頓（fork 尖峰、網路抖動），application 端大量請求 hang 住不回，thread / connection 被耗盡，影響擴散到跟 Redis 無關的請求。

根因：連線沒設 socket_timeout。Redis 一旦慢回應或網路黑洞，caller 無限等待，佔住 thread 與連線，連鎖拖垮整個服務。

修法：

1. 一律設 socket_timeout（cache 場景通常幾百 ms 就該逾時，cache 本來就該快）
2. 逾時後 application 要有 fallback（回源或降級），不是把逾時當 fatal
3. 連線池 max_connections 設上限，避免無限建連把 Redis 的 maxclients 打滿
4. fork 尖峰是常見的慢源頭，對應 persistence deep article 的延遲尖峰治理

Case 3：一個巨大 pipeline 把 server 跟 client 都撐爆

徵兆：用 pipeline 批次處理時，某次塞了幾十萬個命令進一個 pipeline，Redis 記憶體尖峰、client 端記憶體爆，甚至 OOM。

根因：pipeline 把所有命令的 request 跟 response 都 buffer 起來。一次塞太多，server 端要 buffer 全部 reply（計入 used_memory、見 記憶體調校 的 output buffer），client 端要 hold 全部結果，雙邊記憶體尖峰。

修法：

1. pipeline 分批（chunk），每批幾百到幾千命令，不要一個 pipeline 塞無上限
2. 大量資料的掃描用 SCAN 游標分批，不要 KEYS * 一次撈
3. 監控 client output buffer（CLIENT LIST 的 omem），異常大代表有巨型 pipeline 或慢 consumer
4. 批次大小靠 RTT 與記憶體權衡——批次越大省越多 RTT，但記憶體尖峰越高

Case 4：在 cluster 模式對跨 slot key 開 pipeline / transaction 失敗

徵兆：單機 Redis 上運作正常的 pipeline 或 MULTI，搬到 Redis Cluster 後報 CROSSSLOT Keys in request don't hash to the same slot。

根因：Cluster 模式下 MULTI/EXEC 與某些多 key 命令要求所有 key 在同一個 hash slot。pipeline 在 cluster 下也要按 slot 分組送到對應 node——若 client library 不自動處理跨 slot，會失敗。

修法：

1. 同組操作的 key 用 hash tag {...} 強制同 slot（例如 user:{123}:profile、user:{123}:settings）
2. 用支援 cluster pipeline 的 client library，它會自動按 slot 分組
3. 設計階段就考慮 key 的 slot 分布，避免事後重構，對應 cluster re-sharding 的 hash tag 治理
4. 跨 slot 的批次邏輯改用 application 端聚合，不依賴 server 端原子性

Case 5：把 pipeline 當 transaction 用、出現資料競態

徵兆：用 pipeline 做「讀一個值、根據它決定寫什麼」的邏輯，高並發下偶發資料不一致——兩個 client 讀到同樣的舊值、各自寫入，一方覆蓋另一方。

根因：把 pipeline 誤當原子操作。pipeline 只是把命令打包傳輸，命令之間 server 端仍可能插入其他 client 的命令——它沒有原子性。讀後寫的依賴邏輯放 pipeline 裡，等於沒有任何併發保護。

修法：

1. 讀後寫的依賴邏輯用 Lua script（server 端原子執行），不用 pipeline
2. 樂觀鎖場景用 WATCH + MULTI/EXEC（watch 的 key 被改則 EXEC 失敗、重試）
3. 分清楚需求：要省 RTT 用 pipeline，要原子性用 Lua / MULTI，兩者目的不同
4. distributed lock 場景見 2.5 distributed lock，Redis 的鎖有自己的正確性陷阱

Capacity / cost 邊界

連線與往返的容量判讀，圍繞連線數與每請求往返次數：

撞牆後的路由判斷：

• 單執行緒 CPU 打滿、命令吞吐到頂：Redis 主執行緒單線處理命令，pipeline 省 RTT 但不增加 server 端平行度。CPU 到頂走 Cluster 分片把命令分散到多 node。
• 想要單機多核平行處理命令：DragonflyDB 的 shared-nothing 多核架構讓命令在單機就能多核平行，Redis 要靠 cluster 才能達到的吞吐它單機就能撐——高吞吐單機 workload 的替代。
• 跨 cloud / 跨 region 的 RTT 是結構性瓶頸：Snap 的解法是把 cache 部署到跟 application 同 cloud / 同 region，從根本消除跨區 RTT——這是架構層決策，不是 pipeline 能補的。

整合 / 下一步

連線與往返是 application 端延遲的主因，但它跟 server 端調校互補：

• 跟 記憶體調校：巨型 pipeline 的 server 端 reply buffer 計入 used_memory、慢 consumer 的 output buffer 是記憶體洩漏源頭。
• 跟 persistence / fork latency：fork 尖峰是 socket_timeout 必須存在的理由之一——慢源頭不只網路。
• 跟 Cluster re-sharding：cluster 模式改變 pipeline / transaction 的 key 分布規則，hash tag 治理是前提。
• 跟 2.6 high concurrency：高並發下的連線數爆炸與熱 key 是同一組壓力的不同面向，連線池上限與 local cache 兩層都是解法。

相關連結

• 上游 vendor 頁：Redis
• 同 vendor deep article：記憶體與淘汰調校、persistence 與 fork latency、Sentinel 與 failover 時序、Cluster re-sharding
• 上游概念：2.6 high concurrency、2.5 distributed lock
• Methodology：Vendor 深度技術文章寫作方法論

本文是跨 vendor migration playbook、cross-link Redis / Valkey（source、自管）跟 AWS ElastiCache（target、managed）。跑 migration-playbook-methodology 6 維 audit 對映 Operational model = High（自管 → managed）、其他 Low → Type C operational hybrid。ElastiCache 是 managed SaaS、AWS 操作依官方文件（未本機驗證、引數以官方為準）、最後檢查日 2026-06-16。

engine 不變、變的是誰運維

多數 vendor 遷移會換掉某個本質的東西——協定、data model、paradigm。自管 Redis/Valkey → ElastiCache 一個都沒換：ElastiCache 跑的就是 Redis 或 Valkey engine，同樣的 RESP 協定、同樣的 data types、同樣的 client library、同樣的命令。application code 幾乎不用動。

那遷的是什麼？運維責任的歸屬。自管時要自己部署、自己打 patch、自己設 replication、自己半夜處理 failover。ElastiCache 把這些接走——AWS 做 failover、patching、snapshot、跨 AZ 複製。這個遷移的全部工作量集中在「把運維交出去」這件事上：網路（VPC）、安全（IAM / Security Group）、cutover 的資料連續性，以及想清楚交出運維的同時、交出了哪些控制權（不再能 SSH 進機器、不能改任意 config、parameter group 限定可調項）。

這對映 migration 方法論 的 Type C operational hybrid——operational model 是唯一的 High 維度，其他全 Low。本文展開這個「engine 不變、運維轉移」遷移的實際工作與責任邊界。

6 維 diff dimension audit

唯一 High 是 operational model，對映 Type C operational hybrid。Type C 的結構是「operational audit 前置 + drop-in cutover」——因為 engine/API 不變，cutover 本身接近 drop-in（換 endpoint），重點在前置的網路/安全/責任邊界盤點。

operational audit：cutover 前要盤點的

ElastiCache 把運維接走，但也劃下新的邊界。cutover 前必盤：

audit 的關鍵 output：(1) 目前改了哪些 redis.conf 項、ElastiCache parameter group 是否支援；(2) client 是否有 failover reconnect 邏輯（managed failover 不會代為重連）；(3) 監控要從自管工具搬到 CloudWatch。這三項是 Type C 的核心工作。詳細的 managed 責任邊界見 ElastiCache 責任邊界 deep article。

cutover：資料連續性的兩條路

因為 engine/API 不變，cutover 接近 drop-in（換 endpoint）。資料連續性有兩條路：

 1路徑 A：re-warm（cache 可重建、最簡單）
 2  1. 建 ElastiCache cluster（空的、選 Valkey / Redis engine、設 parameter group）
 3  2. application 雙寫（自管 + ElastiCache）、讀仍走自管
 4  3. 讀切到 ElastiCache endpoint、cache miss 回源 warm up
 5  4. 命中率追上 → 停寫自管 → 下線自管
 6
 7路徑 B：RDB seed（要 cache 連續性、避免 warm-up origin 衝擊）
 8  1. 自管端 BGSAVE 產生 RDB
 9  2. RDB 上傳 S3、ElastiCache 從 S3 seed 建 cluster（依官方 restore 流程）
10  3. application 換 endpoint cutover
11  （ElastiCache 也提供 self-managed Redis online migration、見官方文件）

判讀：

• 純 cache、能接受短暫 warm-up → 路徑 A（最簡單、無資料遷移）
• 大 dataset、warm-up 會打爆 origin → 路徑 B（RDB seed 保連續性）
• AWS CLI 建 cluster 與 restore 細節依 ElastiCache 官方文件（未本機驗證）
• engine 選 Valkey（AWS default、約低 Redis 20%）除非有 Redis 商業 module 依賴

Production 故障演練

Case 1：parameter group 不支援自管時改的 config

徵兆：自管時改了某個 redis.conf 項（例如特定 client-output-buffer-limit 或某個進階參數），遷到 ElastiCache 後該設定無法套用或行為不同。

根因：ElastiCache 只允許改 parameter group 開放的項，部分 config 被 AWS 鎖死（為了 managed 穩定性）。自管時的任意 config 自由度在 managed 後收窄。

修法：

1. pre-migration 列出自管端所有非預設 config，逐項對照 ElastiCache parameter group 支援度
2. 不支援的項要評估影響——有些是 AWS 已用更好的方式處理、有些要調整 application 適應
3. 把這個盤點放在 operational audit（cutover 前），不要遷完才發現
4. 高度依賴特殊 config 調校的場景，managed 可能不適合、留自管

Case 2：failover 後 client 不重連（managed 不代為重連）

徵兆：ElastiCache Multi-AZ failover 完成，但 application 持續連舊 primary、寫入失敗。

根因：ElastiCache 接走了 failover（自動晉升 replica），但 application 的 client 重連仍是 application 端的責任——這是 managed 責任邊界 的核心：AWS 換 primary，client 要自己跟上。

修法：

1. client 連 primary endpoint（會跟著 failover 更新 DNS）、不寫死 node IP
2. client 設合理 socket timeout + retry + 縮短 DNS 快取
3. 遷移前就驗證 client 有 failover reconnect 行為（自管 Sentinel 時可能靠不同機制）
4. 對應 Redis Sentinel failover 時序：自管與 managed 的 failover 機制不同、client 處理要重驗

Case 3：endpoint 只在 VPC 內、cutover 後連不上

徵兆：cutover 後 application 完全連不上 ElastiCache、連線逾時。

根因：ElastiCache endpoint 只在 VPC 內可達、不對公網開放。Security Group 沒開 6379、subnet group 配置錯、或 application 不在同 VPC / 沒有 VPC peering，就連不上。

修法：

1. cutover 前確認 Security Group 開 6379 給 application 的來源、subnet group 正確
2. application 不在同 VPC 要設 peering / Transit Gateway
3. 從 VPC 內 EC2 先 redis-cli -h <endpoint> ping 驗證連通，再切 application
4. 這是自管（自己的網路）→ managed（AWS VPC 模型）最常見的卡點

Case 4：監控斷層（自管工具 → CloudWatch）

徵兆：cutover 後原本的 Prometheus / Grafana dashboard 全空、告警失效。

根因：自管時用 redis_exporter + Prometheus，ElastiCache 的指標在 CloudWatch、指標名與維度不同。直接搬 dashboard 不會動。

修法：

1. cutover 前把關鍵告警在 CloudWatch 重建（DatabaseMemoryUsagePercentage / ReplicationLag / CurrConnections 等）
2. 要保留 Grafana 可用 CloudWatch data source 接
3. 把監控遷移納入 operational audit、不要遷完才發現沒監控
4. 核心指標語意相同（記憶體 / 命中 / 連線 / 複製延遲）、只是來源與命名變了

Case 5：以為 managed 就不會 OOM / stampede / 熱 key

徵兆：遷到 ElastiCache 後仍然 OOM、cache stampede、熱 key 打爆單 shard。

根因：ElastiCache 接走的是運維（failover/patch/snapshot），不是 cache 使用方式的問題。記憶體淘汰、stampede、熱 key、key 設計仍是 application 端的責任——managed 不等於 hands-off。

修法：

1. 記憶體 / eviction 調校仍要做（透過 parameter group 設 maxmemory-policy），見 記憶體調校
2. stampede / 熱 key 的 application 端防護（jitter / singleflight / 兩層 cache）照舊
3. 釐清 managed 的責任邊界——左欄 AWS 管、右欄 application 端管，見 責任邊界 deep article
4. 遷 managed 是減運維、不是免設計

Capacity / cost 對照

判讀：在 AWS 生態、要把運維交出去、能接受 config 自由度收窄 → 遷 ElastiCache（engine 不變、Type C 低風險）；要極致控制 / 跨雲 / 依賴特殊 config → 留自管。engine 選 Valkey 省約 20%。

整合 / 下一步

self-managed → ElastiCache 是運維轉移，它跟 managed 邊界與 engine 調校交織：

• 跟 ElastiCache 責任邊界 deep article：遷過去後哪些 AWS 管、哪些仍 application 端管，是這個遷移的核心後果。
• 跟 Redis Sentinel failover：自管 failover（Sentinel）→ managed failover（Multi-AZ），client 重連邏輯要重驗。
• 跟 Valkey：ElastiCache default engine 是 Valkey，自管 Redis 遷 ElastiCache for Valkey 是「換授權 + 轉 managed」一次到位（見 Redis → Valkey 遷移）。
• 跟能力級買 vs 建：自管 vs managed 的上層取捨見該章，本文是「決定買（managed）之後」的遷移執行。

相關連結

• Source vendor：Redis / Valkey（自管）
• Target vendor：AWS ElastiCache
• 對應 deep article：ElastiCache 責任邊界
• 相關 migration：Redis → Valkey（換授權 + 可同時轉 managed）
• Methodology：Migration playbook methodology（Type C operational hybrid）