一、redis的持久化
Redis的持久化是將內存的數據保存到硬盤，防止redis因進程重啓導致的數據丟失。Redis有RDB和AOF兩種持久化的方式。
1、redis RDB持久化
RDB持久化是把當前進程數據生成快照保存到硬盤的過程，觸發RDB的方式有手動觸發和自動觸發。
（1）手動觸發
命令：sava
bgsave
執行save命令時，會阻塞當前Redis服務器，直到RDB過程完成爲止，對於內存較大的實例會造成長時間的阻塞。
執行bgsave命令時，redis進程會執行fork操作創建子進程，RDB持久化過程由子進程負責，完成後自動結束，阻塞只發生在fork階段。
（2）自動觸發機制
在配置文件中使用如”save m n”，表示m秒內數據修改n次,自動觸發bgsave。在執行”debug reload”命令重新加載redis，也會自動觸發save操作，在執行”shutdown”命令時，沒有開啓AOF持久化也會自動執行bgsave。
# Redis中自動觸發的配置如下
save 900 1
save 300 10
save 60 10000
（3）redis對rdb文件的處理
保存：保存在dir配置指定的目錄下，文件名通過dbfilename配置指定。
壓縮：默認採用LZF算法對生成的RDB文件做壓縮處理
校驗：redis加載損壞的RDB文件時拒絕啓動，可使用”redis-check-dump”工具檢測RDB文件並獲取對應的錯誤報告。
（4）RDB的優缺點
優點：RDB是一個緊湊的二進制文件、代表redis在某個時間點上的數據快照。適用於備份、全量複製等場景。Redis加載RDB恢復數據遠遠快於AOF的方式。
缺點：RDB不能做到實時持久化；老版本redis無法兼容新版本RDB。
2、AOF持久化
AOF持久化以獨立日誌的方式記錄每次寫命令，重啓時再重新執行AOF文件中的命令達到恢復數據的目的。AOF解決了數據持久化的實時性，目前已經是redis持久化的主流方式。
（1）配置使用AOF
使用AOF需要配置”appendonly yes”,默認不開啓，AOF文件名通過”appendfilename”配置設置，默認文件名是” appendonly.aof”,保存路勁也是通過”dir”配置。
（2）AOF命令的寫入
AOF命令寫入的內容直接是文本格式。AOF寫入時，先將數據追加到aof_buf中，再同步到硬盤。
文件同步：redis提供了多種AOF緩衝區同步文件策略，由參數appendfsync控制，選項如下：
always:命令寫入aof_buf後調用系統fsync操作同步到AOF文件，fsync 完成後線程返回。每次寫入都要同步AOF文件，與redis高性能背道而馳。
no: 命令寫入aof_buf後調用系統write操作，不對AOF文件做fsync同 步，同步硬盤操作由操作系統負責，通常同步週期最長30秒。當配置爲no時,提升了性能，但是數據安全性無法保證。
everysec:命令寫入aof_buf後調用系統write操作，write完成後線程返回。Fsync同步文件操作命令由專門線程美妙調用一次。everysec爲默認的同步策略，做到了兼顧性能和數據安全。爲默認的值。
（3）AOF重寫機制
AOF重寫機制是把redis內存的數據轉化爲寫命令同步到新的AOF文件的過程，以防止AOF文件的無限增大。
1）重寫規則：
進程內已經超時的數據不再寫入文件；寫入時多條命令會合併爲一條；舊的AOF文件中無效的命令不再寫入
2）AOF重寫觸發機制
手動觸發：使用bgrewriteaof命令
自動觸發：根據”auto-aof-rewrite-min-size”和”auto-aof-rewrite-percentage”參數確定自動觸發機制。
auto-aof-rewrite-min-size：表示AOF重寫時文件最小體積，默認爲60M
auto-aof-rewrite-percentage：代表當前AOF文件空間和上一次重寫後AOF文件空間的比值。
3、持久化文件加載流程
（1）AOF持久化開啓且存在AOF持久化文件時首先加載AOF文件
（2）AOF關閉或AOF持久化文件不存在時，加載RDB文件
（3）加載AOF/RDB文件成功後，redis啓動成功
（4）AOF/RDB文件存在錯誤時，redis啓動失敗並打印錯誤日誌。
二、redis的複製
Redis 的主從複製實現了相同數據的多個redis副本，複製功能是redis高可用的基礎。
1、主從複製的建立與查看
（1）主從複製的建立
1）修改配置文件實現主從複製
在配置文件中加入”slaveof {masterHost} {masterPort}”
2）在redis啓動時建立主從複製
在啓動命令後面加入：--slaveof {masterHost} {masterPort}
# 在啓動時建立主從複製
~]# redis-server --slaveof 192.168.16.129 6379
3）通過命令建立主從複製
登錄redis執行如下命令：slaveof {masterHost} {masterPort}
# 登錄redis通過命令建立主從複製
127.0.0.1:6379> SLAVEOF 192.168.16,128 6379
OK
主從複製建立後，從節點默認使用”slave-read-only=yes”配置爲只讀模式，如果修改從節點的只讀配置，會導致主從數據不一致。
（2）查看redis的的主從複製
命令：127.0.0.1:6379> info replication
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:192.168.16,128
master_port:6379
（3）主從複製斷開
命令：SLAVEOF no one
# 斷開當前redis的主從複製
127.0.0.1:6379> SLAVEOF no one
OK
（4）主從複製中切主操作
命令：slave {newMasterIP} {newMmasterPort}
主從複製切主命令同建立主從複製的命令一樣，切主後從節點會清空之前所有的數據。在生產生謹慎使用。
（5）主從複製安全性
爲了提高複製的安全性，主節點會通過設置requirepass參數進行密碼驗證，這是所有的客戶端訪問必須使用auth命令進行校驗。
（6）主從複製的傳輸延遲
配置選項：repl-disable-tcp-nodelay
當關閉時，主節點產生的命令及時的發送給從幾點，這樣會使主從延遲變小，會增加網絡帶寬的消耗。默認是關閉的。
當開啓時，主節點會合並較小的TCP數據包以節省帶寬，默認發送時間間隔取決於linux的內核，默認40毫秒，這種配置會節省帶寬但會增大主從之間的延遲。
2、主從複製的過程
（1）保存主節點信息
（2）從節點內部通過每秒運行的定時任務維護複製相關邏輯，當定時任務發現存在新的主節點後，會嘗試與該節點建議網絡連接。
（3）從節點發送ping命令請求進行首次通信，ping的目的包括檢測主從之間網絡套接字是否可用及檢測主節點當前是否可以接受處理命令。發送ping命令後，從節點沒有收到主節點的pong回覆或者超時，從節點會斷開復制連接，下次定時任務發起時從連。
（4）權限驗證
（5）同步數據集，主從複製連接正常後，如果爲首次複製，主節點會吧所有的數據全部發送給從節點
（6）命令持續複製
3、主從複製的方式
（1）全量複製
全量複製是redis最早支持的複製方式，也是主從第一次建立複製時必須經歷的階段。觸發全量複製的命令是sync和psync。
（2）部分複製
部分複製時針對全量複製的過高開銷做出的一種優化措施，使用psync {runid} {offset}命令實現。Runid爲從節點所複製的主節點的運行ID，offset爲當前從節點已複製的數據偏移量。
（3）異步複製
主從複製中寫命令的發送過程是異步完成的；主節點自身處理完寫命令後直接返回給客戶端，並不等待從幾點複製完成。
4、 主從複製狀態的維護
主從複製建立後，主從節點都有心跳檢測機制，各自模擬成對方的客戶端進行通信；主節點默認每隔10秒對從節點發送ping命令，判斷從節點的存活性和連接狀態；從節點在主線程中每隔1秒發送”replconf ack {offset}”命令給主節點上報自身當前的複製偏移量。