目錄
一、redis持久化
持久化的作用：將數據從內存異步保存到硬盤中。
持久化方式：快照 RDB；寫日誌 AOF；
（1）AOF
1、什麼是AOF
AOF（append only file） 持久化： 以獨立日誌的方式記錄每次寫命令，重啓時再重新執行AOF文件中的命令達到恢復數據的目的。 AOF的主要作用是解決了數據持久化的實時性， 目前已經是Redis持久化的主流方式。
開啓AOF功能需要設置配置： appendonly yes， 默認不開啓。 AOF文件名通過appendfilename配置設置， 默認文件名是appendonly.aof。 保存路徑同RDB持久化方式一致， 通過dir配置指定。
redis重啓後
步驟：
- 所有的寫入命令會追加到aof_buf（緩衝區） 中。
- AOF緩衝區根據對應的策略向硬盤做同步操作。
- 隨着AOF文件越來越大， 需要定期對AOF文件進行重寫， 達到壓縮的目的。
- 當Redis服務器重啓時， 可以加載AOF文件進行數據恢復。
2、緩衝區文件同步的三種策略
always，每一條命令都寫入。不會丟失數據，I/O開銷大
everysec，出現故障，會丟失一秒數據。通常使用這種方式。
no
建議：
- 配置爲always時， 每次寫入都要同步AOF文件， 在一般的SATA硬盤上， Redis只能支持大約幾百TPS寫入， 顯然跟Redis高性能特性背道而馳，不建議配置。
- 配置爲no， 由於操作系統每次同步AOF文件的週期不可控， 而且會加大每次同步硬盤的數據量， 雖然提升了性能， 但數據安全性無法保證。
- 配置爲everysec， 是建議的同步策略， 也是默認配置， 做到兼顧性能和數據安全性。 理論上只有在系統突然宕機的情況下丟失1秒的數據。
AOF重寫？
隨着命令不斷寫入AOF， 文件會越來越大， 爲了解決這個問題， Redis引入AOF重寫機制壓縮文件體積。 AOF文件重寫是把Redis進程內的數據轉化爲寫命令同步到新AOF文件的過程。
如incr count一億次，只需設置set count 10000000即可，重複執行一億次，開銷比較大。
bgrewriteaof命令：手動觸發
AOF重寫配置：
配置：
統計：
（2）RDB
1、什麼是RDB？
RDB持久化是把當前進程數據生成快照保存到硬盤的過程， 觸發RDB持久化過程分爲手動觸發和自動觸發。
2、觸發機制
save（ 同步），數據量比較大時，redis會阻塞。 如果存在老的RDB文件，新的替換舊的。複雜度O（n）
bgsave（異步），
步驟：
- 執行bgsave命令， Redis父進程判斷當前是否存在正在執行的子進程， 如RDB/AOF子進程， 如果存在bgsave命令直接返回。
- 父進程執行fork操作創建子進程， fork操作過程中父進程會阻塞， 通過info stats命令查看latest_fork_usec選項， 可以獲取最近一個fork操作的耗時， 單位爲微秒。
- 父進程fork完成後， bgsave命令返回“Background saving started”信息並不再阻塞父進程， 可以繼續響應其他命令。
- 子進程創建RDB文件， 根據父進程內存生成臨時快照文件， 完成後對原有文件進行原子替換。 執行lastsave命令可以獲取最後一次生成RDB的時間， 對應info統計的rdb_last_save_time選項。
- 進程發送信號給父進程表示完成， 父進程更新統計信息
自動
滿足配置，就會觸發。
其他觸發機制：全量複製；debug reload；shutdown；
總結：
1、RDB是redis內存到硬盤的快照，用於持久化。
2、save會阻塞redis。
3、bgsave不會阻塞redis，但會fork新進程。
4、save自動配置滿足任一條件就會被執行。
5、有些觸發機制不容忽視。
（3）RDB和AOF比較
RDB的優缺點
RDB的優點：
- RDB是一個緊湊壓縮的二進制文件， 代表Redis在某個時間點上的數據快照。 非常適用於備份， 全量複製等場景。 比如每6小時執行bgsave備份，並把RDB文件拷貝到遠程機器或者文件系統中（如hdfs） ， 用於災難恢復。
- Redis加載RDB恢復數據遠遠快於AOF的方式。
RDB的缺點：
- RDB方式數據沒辦法做到實時持久化/秒級持久化。 因爲bgsave每次運行都要執行fork操作創建子進程， 屬於重量級操作， 頻繁執行成本過高。
- RDB文件使用特定二進制格式保存， Redis版本演進過程中有多個格式的RDB版本， 存在老版本Redis服務無法兼容新版RDB格式的問題。針對RDB不適合實時持久化的問題， Redis提供了AOF持久化方式來解決。
AOF通過追加寫命令到文件實現持久化， 通過appendfsync參數可以控制實時/秒級持久化。 因爲需要不斷追加寫命令， 所以AOF文件體積逐漸變大， 需要定期執行重寫操作來降低文件體積。
AOF重寫可以通過auto-aof-rewrite-min-size和auto-aof-rewritepercentage參數控制自動觸發， 也可以使用bgrewriteaof命令手動觸發。
二、redis複製的原理與優化
1、什麼是主從配置
單機有什麼問題？
1、內存容量有限 2、處理能力有限 3、無法高可用。
主從複製的作用？
Redis 的複製（replication）功能允許用戶根據一個 Redis 服務器來創建任意多個該服務器的複製品，其中被複制的服務器爲主服務器（master），而通過複製創建出來的服務器複製品則爲從服務器（slave）。 只要主從服務器之間的網絡連接正常，主從服務器兩者會具有相同的數據，主服務器就會一直將發生在自己身上的數據更新同步給 從服務器，從而一直保證主從服務器的數據相同。
特點：
1、master/slave 角色；
2、master/slave 數據相同；
3、降低 master 讀壓力再轉交從庫。
問題：
無法保證高可用；
沒有解決 master 寫的壓力。
2、複製的配置
①slaveof命令
在某臺機器上執行，連接 slaveof 127.0.0.1:6379 斷開 slaveof no one②配置
slaveof ip port slave-read-only yes
3、全量複製和部分複製
runid：是一個標識，
redis-cli -p 6379 info server|grep run由上述命令可以知道該 redis服務器的runid是多少，但服務器被重啓或者是網絡的原因，runid會發生變化，而從庫探測到主庫的runid發生了變化，會認爲進行了很大的改動，則會進行一次全量複製。
①偏移量：偏移量是用來檢測從庫和主庫數據是否一致。
全量複製：
一般用於初次複製場景， Redis早期支持的複製功能只有全量複製， 它會把主節點全部數據一次性發送給從節點， 當數據量較大時， 會對主從節點和網絡造成很大的開銷。
1、完成全量複製的功能，有兩個參數（runid，offset），第一次不知道主節點的runid是多少，傳？和-1做全量複製。
2、master檢測出了slave是第一次複製，因爲slave不知道master的runid和偏移量，所以master把自己的runid和偏移量傳給了slave。
3、保存master的信息。
4、 master開始創建快照（bgsave），與其同時master也會把在創建快照的時間間期中產生的數據傳到了自身的複製緩衝區。
5、master向slave發送RDB文件
6、發送緩衝區中新加入的命令。
7、slave清楚掉舊數據
8、加載RDB文件，同時加載buffer數據。
全量複製開銷：
1、bdsave時間2、RDB文件網絡傳輸時間
3、從節點清空數據時間
4、從節點加載RDB的時間。
②部分複製：
有時候因爲網絡的抖動或者其他原因，導致從庫對主庫失去連接。再次連接後，進行全量複製的話，比較消耗資源，所以就出現了部分複製。
2、master 把新命令加入緩衝區（通常1M）
4、發送自己當前的offset和runid，告訴master自己當前的狀態。
5、如果master發現slave傳輸的偏移量在buffer之內，
6、就把從offset開始，到buffer結尾的數據傳輸給slave。
4、故障處理
master宕機之後，就挑選一個從節點稱爲master，其他從節點也以這個爲新的master。這種方式會比較耗時，redis提供了自動故障轉移機制——把slave晉升爲master，讓其他slave同步新master，通知客戶端新的master。這種方式不需要手動實現。例如redis sentinel
5、常見問題
1、讀寫分離：讀流量分攤到從結點。master只做寫的操作，讀操作分配給slave。
可能遇到問題：
- 複製數據延遲
Redis複製數據的延遲由於異步複製特性是無法避免的， 延遲取決於網絡帶寬和命令阻塞情況， 比如剛在主節點寫入數據後立刻在從節點上讀取可能獲取不到。- 讀到過期數據
當主節點存儲大量設置超時的數據時， 如緩存數據， Redis內部需要維護過期數據刪除策略， 刪除策略主要有兩種： 惰性刪除和定時刪除- 從節點故障
對於從節點的故障問題， 需要在客戶端維護可用從節點列表， 當從節點故障時立刻切換到其他從節點或主節點上。2、主從配置不一致
- maxmemory不一致：丟失數據
- 數據結構優化參數（例如has-max-ziplist-entries）：會出現內存不一致的情況
3、規避全量複製
- 第一次全量複製：第一次不可避免，但是我們可以使用小的主節點（maxmemory不設置過大），或者在半夜低峯的時刻做全量複製。
- 節點運行的ID不匹配：例如主節點重啓，runid就會變化，可以使用自動故障轉移，例如哨兵或者集羣。
- 複製積壓緩衝區不足：默認1M。網絡中斷，部分複製功能無法滿足，這個時候可以增大複製緩衝區配置rep_backlog_size。
4、規避複製風暴
- 單主節點複製風暴：由於主節點重啓，多個從節點要複製，會產生複製風暴。
解決辦法是：更換複製拓撲。slave掛slave。
- 單機器複製風暴：由於多個主節點都部署在同一個機器上面，機器宕機後需要大量的全量複製。
解決辦法是：主節點分配到多臺機器上面或者使用一些高可用架構，將從節點晉升爲主節點。
