【貪心優化DP】B. 小 A 的卡牌遊戲
目錄
一、Redis高可用概述
在介紹Redis高可用之前，先說明一下在Redis的語境中高可用的含義。
我們知道，在web伺服器中，高可用是指伺服器可以正常訪問的時間，衡量的標準是在多長時間內可以提供正常服務（99.9%、99.99%、99.999% 等等）。但是在Redis語境中，高可用的含義似乎要寬泛一些，除了保證提供正常服務(如主從分離、快速容災技術)，還需要考慮資料容量的擴充套件、資料安全不會丟失等。
在Redis中，實現高可用的技術主要包括持久化、複製、哨兵和叢集，下面分別說明它們的作用，以及解決了什麼樣的問題。
- 持久化：持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段)，主要作用是資料備份，即將資料儲存在硬碟，保證資料不會因程序退出而丟失。
- 複製：複製是高可用Redis的基礎，哨兵和叢集都是在複製基礎上實現高可用的。複製主要實現了資料的多機備份，以及對於讀操作的負載均衡和簡單的故障恢復。缺陷：故障恢復無法自動化；寫操作無法負載均衡；儲存能力受到單機的限制。
- 哨兵：在複製的基礎上，哨兵實現了自動化的故障恢復。缺陷：寫操作無法負載均衡；儲存能力受到單機的限制。
- 叢集：通過叢集，Redis解決了寫操作無法負載均衡，以及儲存能力受到單機限制的問題，實現了較為完善的高可用方案。
二、Redis持久化概述
持久化的功能：Redis是記憶體資料庫，資料都是儲存在記憶體中，為了避免程序退出導致資料的永久丟失，需要定期將Redis中的資料以某種形式(資料或命令)從記憶體儲存到硬碟；當下次Redis重啟時，利用持久化檔案實現資料恢復。除此之外，為了進行災難備份，可以將持久化檔案拷貝到一個遠端位置。
Redis持久化分為RDB持久化和AOF持久化：前者將當前資料儲存到硬碟，後者則是將每次執行的寫命令儲存到硬碟（類似於MySQL的binlog）；由於AOF持久化的實時性更好，即當程序意外退出時丟失的資料更少，因此AOF是目前主流的持久化方式，不過RDB持久化仍然有其用武之地。
下面依次介紹RDB持久化和AOF持久化；由於Redis各個版本之間存在差異，如無特殊說明，以Redis3.0為準。
三、RDB持久化
RDB持久化是將當前程序中的資料生成快照儲存到硬碟(因此也稱作快照持久化)，儲存的檔案字尾是rdb；當Redis重新啟動時，可以讀取快照檔案恢復資料。
1. 觸發條件
RDB持久化的觸發分為手動觸發和自動觸發兩種。
1) 手動觸發
save命令和bgsave命令都可以生成RDB檔案。
save命令會阻塞Redis伺服器程序，直到RDB檔案建立完畢為止，在Redis伺服器阻塞期間，伺服器不能處理任何命令請求。
而bgsave命令會建立一個子程序，由子程序來負責建立RDB檔案，父程序(即Redis主程序)則繼續處理請求。
此時伺服器執行日誌如下：
bgsave命令執行過程中，只有fork子程序時會阻塞伺服器，而對於save命令，整個過程都會阻塞伺服器，因此save已基本被廢棄，線上環境要杜絕save的使用；後文中也將只介紹bgsave命令。此外，在自動觸發RDB持久化時，Redis也會選擇bgsave而不是save來進行持久化；下面介紹自動觸發RDB持久化的條件。
2) 自動觸發
save m n
自動觸發最常見的情況是在配置檔案中通過save m n，指定當m秒內發生n次變化時，會觸發bgsave。
例如，檢視redis的預設配置檔案(Linux下為redis根目錄下的redis.conf)，可以看到如下配置資訊：
其中save 900 1的含義是：當時間到900秒時，如果redis資料發生了至少1次變化，則執行bgsave；save 300 10和save 60 10000同理。當三個save條件滿足任意一個時，都會引起bgsave的呼叫。
save m n的實現原理
Redis的save m n，是通過serverCron函式、dirty計數器、和lastsave時間戳來實現的。
serverCron是Redis伺服器的週期性操作函式，預設每隔100ms執行一次；該函式對伺服器的狀態進行維護，其中一項工作就是檢查 save m n 配置的條件是否滿足，如果滿足就執行bgsave。
dirty計數器是Redis伺服器維持的一個狀態，記錄了上一次執行bgsave/save命令後，伺服器狀態進行了多少次修改(包括增刪改)；而當save/bgsave執行完成後，會將dirty重新置為0。
例如，如果Redis執行了set mykey helloworld，則dirty值會+1；如果執行了sadd myset v1 v2 v3，則dirty值會+3；注意dirty記錄的是伺服器進行了多少次修改，而不是客戶端執行了多少修改資料的命令。
lastsave時間戳也是Redis伺服器維持的一個狀態，記錄的是上一次成功執行save/bgsave的時間。
save m n的原理如下：每隔100ms，執行serverCron函式；在serverCron函式中，遍歷save m n配置的儲存條件，只要有一個條件滿足，就進行bgsave。對於每一個save m n條件，只有下面兩條同時滿足時才算滿足：
（1）當前時間-lastsave > m
（2）dirty >= n
save m n 執行日誌
下圖是save m n觸發bgsave執行時，伺服器列印日誌的情況：
其他自動觸發機制
除了save m n 以外，還有一些其他情況會觸發bgsave：
- 在主從複製場景下，如果從節點執行全量複製操作，則主節點會執行bgsave命令，並將rdb檔案傳送給從節點
- 執行shutdown命令時，自動執行rdb持久化，如下圖所示：
2. 執行流程
前面介紹了觸發bgsave的條件，下面將說明bgsave命令的執行流程，如下圖所示(圖片來源：https://blog.csdn.net/a1007720052/article/details/79126253)：
圖片中的5個步驟所進行的操作如下：
1) Redis父程序首先判斷：當前是否在執行save，或bgsave/bgrewriteaof（後面會詳細介紹該命令）的子程序，如果在執行則bgsave命令直接返回。bgsave/bgrewriteaof 的子程序不能同時執行，主要是基於效能方面的考慮：兩個併發的子程序同時執行大量的磁碟寫操作，可能引起嚴重的效能問題。
2) 父程序執行fork操作建立子程序，這個過程中父程序是阻塞的，Redis不能執行來自客戶端的任何命令
3) 父程序fork後，bgsave命令返回”Background saving started”資訊並不再阻塞父程序，並可以響應其他命令
4) 子程序建立RDB檔案，根據父程序記憶體快照生成臨時快照檔案，完成後對原有檔案進行原子替換
5) 子程序傳送訊號給父程序表示完成，父程序更新統計資訊
3. RDB檔案
RDB檔案是經過壓縮的二進位制檔案，下面介紹關於RDB檔案的一些細節。
儲存路徑
RDB檔案的儲存路徑既可以在啟動前配置，也可以通過命令動態設定。
配置：dir配置指定目錄，dbfilename指定檔名。預設是Redis根目錄下的dump.rdb檔案。
動態設定：Redis啟動後也可以動態修改RDB儲存路徑，在磁碟損害或空間不足時非常有用；執行命令為config set dir {newdir}和config set dbfilename {newFileName}。如下所示(Windows環境)：
RDB檔案格式
RDB檔案格式如下圖所示（圖片來源：《Redis設計與實現》）：
其中各個欄位的含義說明如下：
1) REDIS：常量，儲存著”REDIS”5個字元。
2) db_version：RDB檔案的版本號，注意不是Redis的版本號。
3) SELECTDB 0 pairs：表示一個完整的資料庫(0號資料庫)，同理SELECTDB 3 pairs表示完整的3號資料庫；只有當資料庫中有鍵值對時，RDB檔案中才會有該資料庫的資訊(上圖所示的Redis中只有0號和3號資料庫有鍵值對)；如果Redis中所有的資料庫都沒有鍵值對，則這一部分直接省略。其中：SELECTDB是一個常量，代表後面跟著的是資料庫號碼；0和3是資料庫號碼；pairs則儲存了具體的鍵值對資訊，包括key、value值，及其資料型別、內部編碼、過期時間、壓縮資訊等等。
4) EOF：常量，標誌RDB檔案正文內容結束。
5) check_sum：前面所有內容的校驗和；Redis在載入RBD檔案時，會計算前面的校驗和並與check_sum值比較，判斷檔案是否損壞。
壓縮
Redis預設採用LZF演算法對RDB檔案進行壓縮。雖然壓縮耗時，但是可以大大減小RDB檔案的體積，因此壓縮預設開啟；可以通過命令關閉：
需要注意的是，RDB檔案的壓縮並不是針對整個檔案進行的，而是對資料庫中的字串進行的，且只有在字串達到一定長度(20位元組)時才會進行。
4. 啟動時載入
RDB檔案的載入工作是在伺服器啟動時自動執行的，並沒有專門的命令。但是由於AOF的優先順序更高，因此當AOF開啟時，Redis會優先載入AOF檔案來恢復資料；只有當AOF關閉時，才會在Redis伺服器啟動時檢測RDB檔案，並自動載入。伺服器載入RDB檔案期間處於阻塞狀態，直到載入完成為止。
Redis啟動日誌中可以看到自動載入的執行：
Redis載入RDB檔案時，會對RDB檔案進行校驗，如果檔案損壞，則日誌中會列印錯誤，Redis啟動失敗。
5. RDB常用配置總結
下面是RDB常用的配置項，以及預設值；前面介紹過的這裡不再詳細介紹。
- save m n：bgsave自動觸發的條件；如果沒有save m n配置，相當於自動的RDB持久化關閉，不過此時仍可以通過其他方式觸發
- stop-writes-on-bgsave-error yes：當bgsave出現錯誤時，Redis是否停止執行寫命令；設定為yes，則當硬碟出現問題時，可以及時發現，避免資料的大量丟失；設定為no，則Redis無視bgsave的錯誤繼續執行寫命令，當對Redis伺服器的系統(尤其是硬碟)使用了監控時，該選項考慮設定為no
- rdbcompression yes：是否開啟RDB檔案壓縮
- rdbchecksum yes：是否開啟RDB檔案的校驗，在寫入檔案和讀取檔案時都起作用；關閉checksum在寫入檔案和啟動檔案時大約能帶來10%的效能提升，但是資料損壞時無法發現
- dbfilename dump.rdb：RDB檔名
- dir ./：RDB檔案和AOF檔案所在目錄
四、AOF持久化
RDB持久化是將程序資料寫入檔案，而AOF持久化(即Append Only File持久化)，則是將Redis執行的每次寫命令記錄到單獨的日誌檔案中（有點像MySQL的binlog）；當Redis重啟時再次執行AOF檔案中的命令來恢復資料。
與RDB相比，AOF的實時性更好，因此已成為主流的持久化方案。
1. 開啟AOF
Redis伺服器預設開啟RDB，關閉AOF；要開啟AOF，需要在配置檔案中配置：
appendonly yes
2. 執行流程
由於需要記錄Redis的每條寫命令，因此AOF不需要觸發，下面介紹AOF的執行流程。
AOF的執行流程包括：
- 命令追加(append)：將Redis的寫命令追加到緩衝區aof_buf；
- 檔案寫入(write)和檔案同步(sync)：根據不同的同步策略將aof_buf中的內容同步到硬碟；
- 檔案重寫(rewrite)：定期重寫AOF檔案，達到壓縮的目的。
1) 命令追加(append)
Redis先將寫命令追加到緩衝區，而不是直接寫入檔案，主要是為了避免每次有寫命令都直接寫入硬碟，導致硬碟IO成為Redis負載的瓶頸。
命令追加的格式是Redis命令請求的協議格式，它是一種純文字格式，具有相容性好、可讀性強、容易處理、操作簡單避免二次開銷等優點；具體格式略。在AOF檔案中，除了用於指定資料庫的select命令（如select 0 為選中0號資料庫）是由Redis新增的，其他都是客戶端傳送來的寫命令。
2) 檔案寫入(write)和檔案同步(sync)
Redis提供了多種AOF快取區的同步檔案策略，策略涉及到作業系統的write函式和fsync函式，說明如下：
為了提高檔案寫入效率，在現代作業系統中，當用戶呼叫write函式將資料寫入檔案時，作業系統通常會將資料暫存到一個記憶體緩衝區裡，當緩衝區被填滿或超過了指定時限後，才真正將緩衝區的資料寫入到硬盤裡。這樣的操作雖然提高了效率，但也帶來了安全問題：如果計算機停機，記憶體緩衝區中的資料會丟失；因此係統同時提供了fsync、fdatasync等同步函式，可以強制作業系統立刻將緩衝區中的資料寫入到硬盤裡，從而確保資料的安全性。
AOF快取區的同步檔案策略由引數appendfsync控制，各個值的含義如下：
- always：命令寫入aof_buf後立即呼叫系統fsync操作同步到AOF檔案，fsync完成後執行緒返回。這種情況下，每次有寫命令都要同步到AOF檔案，硬碟IO成為效能瓶頸，Redis只能支援大約幾百TPS寫入，嚴重降低了Redis的效能；即便是使用固態硬碟（SSD），每秒大約也只能處理幾萬個命令，而且會大大降低SSD的壽命。
- no：命令寫入aof_buf後呼叫系統write操作，不對AOF檔案做fsync同步；同步由作業系統負責，通常同步週期為30秒。這種情況下，檔案同步的時間不可控，且緩衝區中堆積的資料會很多，資料安全性無法保證。
- everysec：命令寫入aof_buf後呼叫系統write操作，write完成後執行緒返回；fsync同步檔案操作由專門的執行緒每秒呼叫一次。everysec是前述兩種策略的折中，是效能和資料安全性的平衡，因此是Redis的預設配置，也是我們推薦的配置。
3) 檔案重寫(rewrite)
隨著時間流逝，Redis伺服器執行的寫命令越來越多，AOF檔案也會越來越大；過大的AOF檔案不僅會影響伺服器的正常執行，也會導致資料恢復需要的時間過長。
檔案重寫是指定期重寫AOF檔案，減小AOF檔案的體積。需要注意的是，AOF重寫是把Redis程序內的資料轉化為寫命令，同步到新的AOF檔案；不會對舊的AOF檔案進行任何讀取、寫入操作!
關於檔案重寫需要注意的另一點是：對於AOF持久化來說，檔案重寫雖然是強烈推薦的，但並不是必須的；即使沒有檔案重寫，資料也可以被持久化並在Redis啟動的時候匯入；因此在一些實現中，會關閉自動的檔案重寫，然後通過定時任務在每天的某一時刻定時執行。
檔案重寫之所以能夠壓縮AOF檔案，原因在於：
- 過期的資料不再寫入檔案
- 無效的命令不再寫入檔案：如有些資料被重複設值(set mykey v1, set mykey v2)、有些資料被刪除了(sadd myset v1, del myset)等等
- 多條命令可以合併為一個：如sadd myset v1, sadd myset v2, sadd myset v3可以合併為sadd myset v1 v2 v3。不過為了防止單條命令過大造成客戶端緩衝區溢位，對於list、set、hash、zset型別的key，並不一定只使用一條命令；而是以某個常量為界將命令拆分為多條。這個常量在redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD中定義，不可更改，3.0版本中值是64。
通過上述內容可以看出，由於重寫後AOF執行的命令減少了，檔案重寫既可以減少檔案佔用的空間，也可以加快恢復速度。
檔案重寫的觸發
檔案重寫的觸發，分為手動觸發和自動觸發：
手動觸發：直接呼叫bgrewriteaof命令，該命令的執行與bgsave有些類似：都是fork子程序進行具體的工作，且都只有在fork時阻塞。
此時伺服器執行日誌如下：
自動觸發：根據auto-aof-rewrite-min-size和auto-aof-rewrite-percentage引數，以及aof_current_size和aof_base_size狀態確定觸發時機。
- auto-aof-rewrite-min-size：執行AOF重寫時，檔案的最小體積，預設值為64MB。
- auto-aof-rewrite-percentage：執行AOF重寫時，當前AOF大小(即aof_current_size)和上一次重寫時AOF大小(aof_base_size)的比值。
其中，引數可以通過config get命令檢視：
狀態可以通過info persistence檢視：
只有當auto-aof-rewrite-min-size和auto-aof-rewrite-percentage兩個引數同時滿足時，才會自動觸發AOF重寫，即bgrewriteaof操作。
自動觸發bgrewriteaof時，可以看到伺服器日誌如下：
檔案重寫的流程
檔案重寫流程如下圖所示(圖片來源：http://www.cnblogs.com/yangmingxianshen/p/8373205.html)：
關於檔案重寫的流程，有兩點需要特別注意：(1)重寫由父程序fork子程序進行；(2)重寫期間Redis執行的寫命令，需要追加到新的AOF檔案中，為此Redis引入了aof_rewrite_buf快取。
對照上圖，檔案重寫的流程如下：
1) Redis父程序首先判斷當前是否存在正在執行 bgsave/bgrewriteaof的子程序，如果存在則bgrewriteaof命令直接返回，如果存在bgsave命令則等bgsave執行完成後再執行。前面曾介紹過，這個主要是基於效能方面的考慮。
2) 父程序執行fork操作建立子程序，這個過程中父程序是阻塞的。
3.1) 父程序fork後，bgrewriteaof命令返回”Background append only file rewrite started”資訊並不再阻塞父程序，並可以響應其他命令。Redis的所有寫命令依然寫入AOF緩衝區，並根據appendfsync策略同步到硬碟，保證原有AOF機制的正確。
3.2) 由於fork操作使用寫時複製技術，子程序只能共享fork操作時的記憶體資料。由於父程序依然在響應命令，因此Redis使用AOF重寫緩衝區(圖中的aof_rewrite_buf)儲存這部分資料，防止新AOF檔案生成期間丟失這部分資料。也就是說，bgrewriteaof執行期間，Redis的寫命令同時追加到aof_buf和aof_rewirte_buf兩個緩衝區。
4) 子程序根據記憶體快照，按照命令合併規則寫入到新的AOF檔案。
5.1) 子程序寫完新的AOF檔案後，向父程序發訊號，父程序更新統計資訊，具體可以通過info persistence檢視。
5.2) 父程序把AOF重寫緩衝區的資料寫入到新的AOF檔案，這樣就保證了新AOF檔案所儲存的資料庫狀態和伺服器當前狀態一致。
5.3) 使用新的AOF檔案替換老檔案，完成AOF重寫。
3. 啟動時載入
前面提到過，當AOF開啟時，Redis啟動時會優先載入AOF檔案來恢復資料；只有當AOF關閉時，才會載入RDB檔案恢復資料。
當AOF開啟，且AOF檔案存在時，Redis啟動日誌：
當AOF開啟，但AOF檔案不存在時，即使RDB檔案存在也不會載入(更早的一些版本可能會載入，但3.0不會)，Redis啟動日誌如下：
檔案校驗
與載入RDB檔案類似，Redis載入AOF檔案時，會對AOF檔案進行校驗，如果檔案損壞，則日誌中會列印錯誤，Redis啟動失敗。但如果是AOF檔案結尾不完整(機器突然宕機等容易導致檔案尾部不完整)，且aof-load-truncated引數開啟，則日誌中會輸出警告，Redis忽略掉AOF檔案的尾部，啟動成功。aof-load-truncated引數預設是開啟的：
偽客戶端
因為Redis的命令只能在客戶端上下文中執行，而載入AOF檔案時命令是直接從檔案中讀取的，並不是由客戶端傳送；因此Redis伺服器在載入AOF檔案之前，會建立一個沒有網路連線的客戶端，之後用它來執行AOF檔案中的命令，命令執行的效果與帶網路連線的客戶端完全一樣。
4. AOF常用配置總結
下面是AOF常用的配置項，以及預設值；前面介紹過的這裡不再詳細介紹。
- appendonly no：是否開啟AOF
- appendfilename "appendonly.aof"：AOF檔名
- dir ./：RDB檔案和AOF檔案所在目錄
- appendfsync everysec：fsync持久化策略
- no-appendfsync-on-rewrite no：AOF重寫期間是否禁止fsync；如果開啟該選項，可以減輕檔案重寫時CPU和硬碟的負載（尤其是硬碟），但是可能會丟失AOF重寫期間的資料；需要在負載和安全性之間進行平衡
- auto-aof-rewrite-percentage 100：檔案重寫觸發條件之一
- auto-aof-rewrite-min-size 64mb：檔案重寫觸發提交之一
- aof-load-truncated yes：如果AOF檔案結尾損壞，Redis啟動時是否仍載入AOF檔案
五、方案選擇與常見問題
前面介紹了RDB和AOF兩種持久化方案的細節，下面介紹RDB和AOF的特點、如何選擇持久化方案，以及在持久化過程中常遇到的問題等。
1. RDB和AOF的優缺點
RDB和AOF各有優缺點：
RDB持久化
優點：RDB檔案緊湊，體積小，網路傳輸快，適合全量複製；恢復速度比AOF快很多。當然，與AOF相比，RDB最重要的優點之一是對效能的影響相對較小。
缺點：RDB檔案的致命缺點在於其資料快照的持久化方式決定了必然做不到實時持久化，而在資料越來越重要的今天，資料的大量丟失很多時候是無法接受的，因此AOF持久化成為主流。此外，RDB檔案需要滿足特定格式，相容性差（如老版本的Redis不相容新版本的RDB檔案）。
AOF持久化
與RDB持久化相對應，AOF的優點在於支援秒級持久化、相容性好，缺點是檔案大、恢復速度慢、對效能影響大。
2. 持久化策略選擇
在介紹持久化策略之前，首先要明白無論是RDB還是AOF，持久化的開啟都是要付出效能方面代價的：對於RDB持久化，一方面是bgsave在進行fork操作時Redis主程序會阻塞，另一方面，子程序向硬碟寫資料也會帶來IO壓力；對於AOF持久化，向硬碟寫資料的頻率大大提高(everysec策略下為秒級)，IO壓力更大，甚至可能造成AOF追加阻塞問題（後面會詳細介紹這種阻塞），此外，AOF檔案的重寫與RDB的bgsave類似，會有fork時的阻塞和子程序的IO壓力問題。相對來說，由於AOF向硬碟中寫資料的頻率更高，因此對Redis主程序效能的影響會更大。
在實際生產環境中，根據資料量、應用對資料的安全要求、預算限制等不同情況，會有各種各樣的持久化策略；如完全不使用任何持久化、使用RDB或AOF的一種，或同時開啟RDB和AOF持久化等。此外，持久化的選擇必須與Redis的主從策略一起考慮，因為主從複製與持久化同樣具有資料備份的功能，而且主機master和從機slave可以獨立的選擇持久化方案。
下面分場景來討論持久化策略的選擇，下面的討論也只是作為參考，實際方案可能更復雜更具多樣性。
（1）如果Redis中的資料完全丟棄也沒有關係（如Redis完全用作DB層資料的cache），那麼無論是單機，還是主從架構，都可以不進行任何持久化。
（2）在單機環境下（對於個人開發者，這種情況可能比較常見），如果可以接受十幾分鍾或更多的資料丟失，選擇RDB對Redis的效能更加有利；如果只能接受秒級別的資料丟失，應該選擇AOF。
（3）但在多數情況下，我們都會配置主從環境，slave的存在既可以實現資料的熱備，也可以進行讀寫分離分擔Redis讀請求，以及在master宕掉後繼續提供服務。
在這種情況下，一種可行的做法是：
master：完全關閉持久化（包括RDB和AOF），這樣可以讓master的效能達到最好
slave：關閉RDB，開啟AOF（如果對資料安全要求不高，開啟RDB關閉AOF也可以），並定時對持久化檔案進行備份（如備份到其他資料夾，並標記好備份的時間）；然後關閉AOF的自動重寫，然後新增定時任務，在每天Redis閒時（如凌晨12點）呼叫bgrewriteaof。
這裡需要解釋一下，為什麼開啟了主從複製，可以實現資料的熱備份，還需要設定持久化呢？因為在一些特殊情況下，主從複製仍然不足以保證資料的安全，例如：
- master和slave程序同時停止：考慮這樣一種場景，如果master和slave在同一棟大樓或同一個機房，則一次停電事故就可能導致master和slave機器同時關機，Redis程序停止；如果沒有持久化，則面臨的是資料的完全丟失。
- master誤重啟：考慮這樣一種場景，master服務因為故障宕掉了，如果系統中有自動拉起機制（即檢測到服務停止後重啟該服務）將master自動重啟，由於沒有持久化檔案，那麼master重啟後資料是空的，slave同步資料也變成了空的；如果master和slave都沒有持久化，同樣會面臨資料的完全丟失。需要注意的是，即便是使用了哨兵(關於哨兵後面會有文章介紹)進行自動的主從切換，也有可能在哨兵輪詢到master之前，便被自動拉起機制重啟了。因此，應儘量避免“自動拉起機制”和“不做持久化”同時出現。
（4）異地災備：上述討論的幾種持久化策略，針對的都是一般的系統故障，如程序異常退出、宕機、斷電等，這些故障不會損壞硬碟。但是對於一些可能導致硬碟損壞的災難情況，如火災地震，就需要進行異地災備。例如對於單機的情形，可以定時將RDB檔案或重寫後的AOF檔案，通過scp拷貝到遠端機器，如阿里雲、AWS等；對於主從的情形，可以定時在master上執行bgsave，然後將RDB檔案拷貝到遠端機器，或者在slave上執行bgrewriteaof重寫AOF檔案後，將AOF檔案拷貝到遠端機器上。一般來說，由於RDB檔案檔案小、恢復快，因此災難恢復常用RDB檔案；異地備份的頻率根據資料安全性的需要及其他條件來確定，但最好不要低於一天一次。
3. fork阻塞：CPU的阻塞
在Redis的實踐中，眾多因素限制了Redis單機的記憶體不能過大，例如：
- 當面對請求的暴增，需要從庫擴容時，Redis記憶體過大會導致擴容時間太長；
- 當主機宕機時，切換主機後需要掛載從庫，Redis記憶體過大導致掛載速度過慢；
- 以及持久化過程中的fork操作，下面詳細說明。
首先說明一下fork操作：
父程序通過fork操作可以建立子程序；子程序建立後，父子程序共享程式碼段，不共享程序的資料空間，但是子程序會獲得父程序的資料空間的副本。在作業系統fork的實際實現中，基本都採用了寫時複製技術，即在父/子程序試圖修改資料空間之前，父子程序實際上共享資料空間；但是當父/子程序的任何一個試圖修改資料空間時，作業系統會為修改的那一部分(記憶體的一頁)製作一個副本。
雖然fork時，子程序不會複製父程序的資料空間，但是會複製記憶體頁表（頁表相當於記憶體的索引、目錄）；父程序的資料空間越大，記憶體頁表越大，fork時複製耗時也會越多。
在Redis中，無論是RDB持久化的bgsave，還是AOF重寫的bgrewriteaof，都需要fork出子程序來進行操作。如果Redis記憶體過大，會導致fork操作時複製記憶體頁表耗時過多；而Redis主程序在進行fork時，是完全阻塞的，也就意味著無法響應客戶端的請求，會造成請求延遲過大。
對於不同的硬體、不同的作業系統，fork操作的耗時會有所差別，一般來說，如果Redis單機記憶體達到了10GB，fork時耗時可能會達到百毫秒級別（如果使用Xen虛擬機器，這個耗時可能達到秒級別）。因此，一般來說Redis單機記憶體一般要限制在10GB以內；不過這個資料並不是絕對的，可以通過觀察線上環境fork的耗時來進行調整。觀察的方法如下：執行命令info stats，檢視latest_fork_usec的值，單位為微秒。
為了減輕fork操作帶來的阻塞問題，除了控制Redis單機記憶體的大小以外，還可以適度放寬AOF重寫的觸發條件、選用物理機或高效支援fork操作的虛擬化技術等，例如使用Vmware或KVM虛擬機器，不要使用Xen虛擬機器。
4. AOF追加阻塞：硬碟的阻塞
前面提到過，在AOF中，如果AOF緩衝區的檔案同步策略為everysec，則：在主執行緒中，命令寫入aof_buf後呼叫系統write操作，write完成後主執行緒返回；fsync同步檔案操作由專門的檔案同步執行緒每秒呼叫一次。
這種做法的問題在於，如果硬碟負載過高，那麼fsync操作可能會超過1s；如果Redis主執行緒持續高速向aof_buf寫入命令，硬碟的負載可能會越來越大，IO資源消耗更快；如果此時Redis程序異常退出，丟失的資料也會越來越多，可能遠超過1s。
為此，Redis的處理策略是這樣的：主執行緒每次進行AOF會對比上次fsync成功的時間；如果距上次不到2s，主執行緒直接返回；如果超過2s，則主執行緒阻塞直到fsync同步完成。因此，如果系統硬碟負載過大導致fsync速度太慢，會導致Redis主執行緒的阻塞；此外，使用everysec配置，AOF最多可能丟失2s的資料，而不是1s。
AOF追加阻塞問題定位的方法：
（1）監控info Persistence中的aof_delayed_fsync：當AOF追加阻塞發生時（即主執行緒等待fsync而阻塞），該指標累加。
（2）AOF阻塞時的Redis日誌：
Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.
（3）如果AOF追加阻塞頻繁發生，說明系統的硬碟負載太大；可以考慮更換IO速度更快的硬碟，或者通過IO監控分析工具對系統的IO負載進行分析，如iostat（系統級io）、iotop（io版的top）、pidstat等。
5. info命令與持久化
前面提到了一些通過info命令檢視持久化相關狀態的方法，下面來總結一下。
（1）info Persistence
執行結果如下：
其中比較重要的包括：
- rdb_last_bgsave_status:上次bgsave 執行結果，可以用於發現bgsave錯誤
- rdb_last_bgsave_time_sec:上次bgsave執行時間（單位是s），可以用於發現bgsave是否耗時過長
- aof_enabled:AOF是否開啟
- aof_last_rewrite_time_sec: 上次檔案重寫執行時間（單位是s），可以用於發現檔案重寫是否耗時過長
- aof_last_bgrewrite_status: 上次bgrewrite執行結果，可以用於發現bgrewrite錯誤
- aof_buffer_length和aof_rewrite_buffer_length:aof快取區大小和aof重寫緩衝區大小
- aof_delayed_fsync:AOF追加阻塞情況的統計
（2）info stats
其中與持久化關係較大的是：latest_fork_usec，代表上次fork耗時，可以參見前面的討論。
六、總結
本文主要內容可以總結如下：
1、持久化在Redis高可用中的作用：資料備份，與主從複製相比強調的是由記憶體到硬碟的備份。
2、RDB持久化：將資料快照備份到硬碟；介紹了其觸發條件（包括手動出發和自動觸發）、執行流程、RDB檔案等，特別需要注意的是檔案儲存操作由fork出的子程序來進行。
3、AOF持久化：將執行的寫命令備份到硬碟（類似於MySQL的binlog），介紹了其開啟方法、執行流程等，特別需要注意的是檔案同步策略的選擇（everysec）、檔案重寫的流程。
4、一些現實的問題：包括如何選擇持久化策略，以及需要注意的fork阻塞、AOF追加阻塞等。
原文地址：https://www.cnblogs.com/kismetv/p/9137897.html