騰訊雲企業開戶代辦 騰訊雲 Redis 數據持久化（RDB/AOF）導致 CPU 瞬間飆高卡頓排查
一、先看現象：為什麼 Redis 會突然卡一下
線上最常見的報警不是宕機，而是「延遲突然升高」。接口還能回，但 RT 瞬間變長，偶爾幾秒內大量請求超時，過後又恢復正常。騰訊雲 Redis 出現這類抖動時，很多人第一反應是業務流量上來了，實際上更常見的元兇是持久化：RDB 快照或 AOF 重寫在某個時間點開始了。
這種卡頓的特徵很有辨識度。通常不是一直慢，而是周期性地慢；不是整體性能都差，而是某一小段時間 CPU 飆高、延遲抖動明顯；不是所有指標一起壞，而是會看到 fork 耗時上升、內存複製壓力變大、磁碟寫入量抬頭，甚至伴隨主從複製延後。只要抓到這些線索，排查方向就基本對了。
二、先把原理講清楚：RDB 與 AOF 到底在忙什麼
1. RDB 不是簡單寫個文件
RDB 的本質是一次全量快照。Redis 為了不阻塞主線程，通常會先 fork 出子進程，由子進程負責把當前內存中的數據序列化成 RDB 文件。表面看起來是子進程在幹活，實際上 fork 這一步本身就不輕。
fork 的時候，操作系統要複製進程地址空間的頁表。數據量越大、內存越大，頁表就越多，fork 耗時就越長。這個過程雖然不一定等於高 CPU，但在大實例上會直接拉高系統開銷，Redis 主線程也可能因此被短暫拖慢。更麻煩的是，fork 成功之後，父子進程共享物理頁面，後續如果業務持續寫入，就會觸發 COW，也就是寫時複製，額外消耗 CPU 和內存帶寬。
2. AOF 重寫的壓力不在寫文件，而在整理命令
AOF 記錄的是寫命令。當文件越來越大，Redis 會做重寫，把大量歷史命令壓縮成更精簡的重建命令集。這同樣依賴 fork 子進程。主進程繼續接收請求，子進程負責整理和重寫。問題在於，重寫期間如果寫流量很高，父進程需要不停追加緩衝，子進程需要處理內存快照，兩邊都會被放大壓力。
因此，AOF 重寫引發的抖動，常常不是單純的「磁碟寫慢」，而是內存、CPU、頁表複製、COW、磁碟 IO 疊加之後的綜合反應。這也是為什麼很多人只盯著磁碟，最後卻找不到問題根因。
三、排查時先不要猜，按指標把鍋一個個排掉
1. 先確認是不是持久化窗口撞上了業務高峰
排查第一步很簡單：看卡頓發生的時間，是否和 RDB 定時快照、AOF 重寫重疊。騰訊雲控制台一般可以看到 Redis 實例的 CPU、內存、QPS、連接數、延遲、fork 耗時、持久化狀態等指標。把延遲尖峰和持久化事件對齊，往往一眼就能看出關聯。
如果每次都是凌晨一兩點開始抖，且持續時間很短，通常是備份窗口；如果卡頓發生在內存逼近閾值、寫流量升高、AOF 文件增長快的階段，多半是重寫過程被業務寫入拖慢了。
2. 看 CPU 高的是誰
騰訊雲企業開戶代辦 CPU 瞬間飆高，不能只看總量，還要看是 Redis 進程高，還是宿主機整體高。若是 Redis 主進程 CPU 突然上去，並且同時伴隨延遲升高，基本可以懷疑 fork、COW 或大量寫命令。若是系統層 CPU 高，但 Redis 指標不完全對應，還要考慮磁碟 flush、內核態開銷、文件系統壓力。
另外，不要忽略實例規格本身。如果 CPU 配比偏低，Redis 在高併發寫入下本來就接近飽和，這時再碰上 RDB/AOF，抖動會被放大很多。很多問題不是持久化單獨造成的，而是持久化把原本緊繃的系統推過了臨界點。
3. 內存是否有明顯的複製開銷
騰訊雲企業開戶代辦 如果持久化期間內存使用不降反升，或者短時間內瞬間抖高，很可能就是 COW 在作祟。這在大 Key、多寫入、批量更新場景尤其明顯。父子進程共享的頁面被頻繁改寫時，Redis 需要為新寫入分配額外頁面，導致內存帶寬和 CPU 都被拖住。
當實例已經很接近內存上限時，COW 會更危險。它不一定立刻把機器打滿，但會讓系統進入緊張狀態，接著就是延遲波動、主從複製延後、甚至觸發更重的故障。
四、真正容易踩坑的幾個點
1. 大實例 fork 本身就慢
實例越大，fork 成本越高。很多人誤以為 Redis 是內存型數據庫，快照應該只是「複製一下」，實際上頁表複製不是免費的。當內存到十幾 GB、幾十 GB 甚至更高時，fork 的時間和系統抖動都會被放大。這也是為什麼大實例更怕頻繁快照。
2. 寫流量高時做重寫，等於邊整理邊加壓
如果業務寫請求持續高位，AOF 重寫會在繁忙窗口中額外佔用 CPU。它不是單純「把文件變小」，而是要重建語義、去重、壓縮命令，這些都要計算。重寫期間若又有大量變更，父進程還要維護 AOF 緩衝區，壓力很容易疊加成卡頓。
騰訊雲企業開戶代辦 3. 大 Key 和批量操作會把抖動放大
一個超大的 hash、set、list，或者一次大批量更新，都會讓單次操作成本偏高。平時看不出來，到了 fork 或重寫時，這些高成本寫入會把 COW 放大到更明顯。也就是說，持久化只是導火索，真正讓 CPU 飆高的，往往是數據結構和寫入方式本身。
4. 磁碟慢不一定是主因，但常常是加速器
RDB 寫盤、AOF 重寫落盤、AOF 增量追加，都依賴存儲性能。如果磁碟 IO 飽和、延遲高、IOPS 不夠，子進程會寫得更慢，持久化持續時間拉長，進而讓父進程在更長的時間內暴露於 COW 壓力下。這時候表面看是 CPU 飆高，實際上是磁碟拖住了整個過程。
五、實戰排查思路：從現象回到根因
1. 先縮小到某一次抖動
不要一上來就看一周報表，先定位一次最典型的卡頓。記下時間點，對照控制台上的持久化事件、CPU、延遲、內存、帶寬、連接數，確認是否同時出現 fork、重寫、快照或複製延遲。只要事件能對上，後面就好辦。
2. 再看是 RDB 還是 AOF
如果實例同時開了 RDB 和 AOF，就要分清誰在發力。RDB 的特點是周期性更明顯，卡頓往往短而集中；AOF 重寫則更容易和寫壓力綁在一起，持續時間更長，且常伴隨文件增長與 rewrite 事件。兩者都會用 fork，但對業務節奏的影響不一樣。
3. 驗證是否存在配置不合理
常見問題包括快照太頻繁、AOF 重寫觸發太激進、實例規格過小、內存利用率太高、業務寫入模式過於集中。比如在高峰時段做備份，或者同時讓多個實例進入持久化窗口，這些都會把抖動堆在一起。
4. 關注主從與業務端感知
有些情況下，主節點只是短暫卡一下，但主從複製卻明顯落後，從而導致讀請求抖動。業務端如果有超時重試機制，還會把一次短抖放大成一波流量尖峰。排查時一定要把 Redis 本身和上游應用一起看，否則容易誤判。
騰訊雲企業開戶代辦 六、常用處理辦法：不是關掉持久化，而是把壓力分散開
1. 把持久化窗口挪到低峰期
如果業務有明確高峰，優先把 RDB 備份與 AOF 重寫放到低峰。這是最直接、最省成本的做法。很多卡頓不是技術不行，而是時間點不對。只要窗口選得好，問題能直接少一半。
2. 降低單次持久化成本
能縮小數據體量就縮小，能減少大 Key 就減少大 Key。數據越乾淨，fork 越輕，重寫越快，COW 越少。對 Redis 來說，結構設計比很多人想得更重要。把一個超大 key 拆成多個小 key，往往比事後調參有效得多。
3. 調整 AOF 重寫策略
如果 AOF 重寫太頻繁，可以根據業務特徵調整觸發條件，避免文件稍微變大就重寫。重寫不是越勤快越好，過於頻繁只會讓系統一直處在整理狀態，反而更容易抖。核心思路是讓重寫次數和業務波峰錯開，讓每次重寫都能在較穩定的環境下完成。
4. 留出足夠的內存餘量
持久化期間最怕內存卡線。實例平時就打滿，遇到 fork 和 COW，系統幾乎沒有緩衝空間。建議至少預留明顯餘量，具體比例要看業務寫入量和數據模型，但原則很簡單：不要把 Redis 當成可以長期跑在滿負載的機器。
5. 避免高峰批量寫入
大批量 set、mset、pipeline 連發，在持久化期間特別容易放大問題。如果業務允許，盡量做寫入節流、分批提交、錯峰導入。Redis 喜歡穩定流量，不喜歡一波一波地衝。只要寫入節奏平滑一些，持久化期間的抖動通常會小很多。
七、如果已經發生了，怎麼快速止血
1. 先觀察是否正在重寫或快照
如果當下就是持久化窗口，先不要頻繁重啟。很多短暫卡頓是可以自然恢復的，反覆重啟反而會讓持久化狀態更亂，還可能造成更大的恢復成本。先確認卡頓是否會隨快照結束而消退。
2. 立即降低寫入壓力
能限流就限流，能排隊就排隊，能拆批就拆批。把寫入峰值壓下來，COW 和 AOF 緩衝都會立刻減少。這一步通常比盲目加機器更快見效。
3. 必要時臨時調整持久化策略
如果業務已經抖得很明顯，又找到了確定的持久化觸發點，可以根據實際情況暫時調整策略，但前提是要清楚風險。生產環境不是不能改配置，而是不能在不了解後果的情況下亂改。止血之後，還是要回到根因治理。
八、最容易被忽略的不是配置，而是數據形態
很多人把注意力放在參數上，卻忽略了數據形態本身。Redis 是內存數據庫，數據結構一旦膨脹，持久化成本會成倍上升。幾個超大 key、過深的集合、頻繁變動的大對象，都會讓 fork 和 COW 變難看。換句話說，持久化問題的背後，往往是業務模型和數據模型沒有配合好。
所以真正穩定的方案不是單點調參，而是三件事一起做：控制數據體量，控制寫入節奏，控制持久化窗口。只要這三件事平衡住，Redis 的 CPU 突刺和卡頓通常都會明顯下降。
九、結語：先把機理看懂，排查就不會亂
騰訊雲 Redis 在 RDB 或 AOF 場景下出現 CPU 瞬間飆高、請求卡頓，表面像性能問題，底層其實是 fork、COW、寫入壓力、磁碟 IO 與數據結構共同作用的結果。排查時不要只看 CPU 一個點，也不要只怪持久化本身。把時間點、事件、內存、寫流量和磁碟一起串起來，答案通常就很清楚了。
經驗上講，Redis 的大多數「突然卡一下」，不是某一個參數設錯，而是平時的負載模型已經很接近極限，持久化只是最後那根稻草。把這件事想明白，後面的治理就會很務實：錯峰、降壓、減少大 Key、留足餘量、讓重寫不撞高峰。看起來都是老辦法，但真正能把線上穩住的，往往也就是這些老辦法。
