redis持久化及主從複製詳解（轉）
作者:silenceper
日期：2013-10-03
redis 與memcached 最大的一個區別就是Redis支援資料的持久化，可以將記憶體中的資料保持在磁碟中，重啟的時候可以再次載入進行使用。
一、redis提供的持久化：
1). RDB持久化：
該機制是指在指定的時間間隔內將記憶體中的資料集快照寫入磁碟。
2). AOF持久化:
該機制將以日誌的形式記錄伺服器所處理的每一個寫操作，在Redis伺服器啟動之初會讀取該檔案來重新構建資料庫，以保證啟動後資料庫中的資料是完整的。
3). 無持久化：
我們可以通過配置的方式禁用Redis伺服器的持久化功能，這樣我們就可以將Redis視為一個功能加強版的memcached了。
4). 同時應用AOF和RDB。
二、RDB機制的優勢和劣勢：
RDB存在哪些優勢呢？
1). 一旦採用該方式，那麼你的整個Redis資料庫將只包含一個檔案，這對於檔案備份而言是非常完美的。比如，你可能打算每個小時歸檔一次最近24小時的資料，同時還要每天歸檔一次最近30天的資料。通過這樣的備份策略，一旦系統出現災難性故障，我們可以非常容易的進行恢復。
2). 對於災難恢復而言，RDB是非常不錯的選擇。因為我們可以非常輕鬆的將一個單獨的檔案壓縮後再轉移到其它儲存介質上。
3). 效能最大化。對於Redis的服務程序而言，在開始持久化時，它唯一需要做的只是fork出子程序，之後再由子程序完成這些持久化的工作，這樣就可以極大的避免服務程序執行IO操作了。
4). 相比於AOF機制，如果資料集很大，RDB的啟動效率會更高。
RDB又存在哪些劣勢呢？
1). 如果你想保證資料的高可用性，即最大限度的避免資料丟失，那麼RDB將不是一個很好的選擇。因為系統一旦在定時持久化之前出現宕機現象，此前沒有來得及寫入磁碟的資料都將丟失。
2). 由於RDB是通過fork子程序來協助完成資料持久化工作的，因此，如果當資料集較大時，可能會導致整個伺服器停止服務幾百毫秒，甚至是1秒鐘。
三、AOF機制的優勢和劣勢：
AOF的優勢有哪些呢？
1). 該機制可以帶來更高的資料安全性，即資料永續性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事實上，每秒同步也是非同步完成的，其效率也是非常高的，所差的是一旦系統出現宕機現象，那麼這一秒鐘之內修改的資料將會丟失。而每修改同步，我們可以將其視為同步持久化，即每次發生的資料變化都會被立即記錄到磁碟中。可以預見，這種方式在效率上是最低的。至於無同步，無需多言，我想大家都能正確的理解它。
2). 由於該機制對日誌檔案的寫入操作採用的是append模式，因此在寫入過程中即使出現宕機現象，也不會破壞日誌檔案中已經存在的內容。然而如果我們本次操作只是寫入了一半資料就出現了系統崩潰問題，不用擔心，在Redis下一次啟動之前，我們可以通過redis-check-aof工具來幫助我們解決資料一致性的問題。
3). 如果日誌過大，Redis可以自動啟用rewrite機制。
（AOF rewrite的觸發機制
如果Redis只是將客戶端修改資料庫的指令重現儲存在AOF檔案中，那麼AOF檔案的大小會不斷的增加，因為AOF檔案只是簡單的重現儲存了客戶端的指令，而並沒有進行合併。對於該問題最簡單的處理方式，即當AOF檔案滿足一定條件時就對AOF進行rewrite，rewrite是根據當前記憶體資料庫中的資料進行遍歷寫到一個臨時的AOF檔案，待寫完後替換掉原來的AOF檔案即可。
Redis觸發AOF rewrite機制有三種：
1、Redis Server接收到客戶端傳送的BGREWRITEAOF指令請求，如果當前AOF/RDB資料持久化沒有在執行，那麼執行，反之，等當前AOF/RDB資料持久化結束後執行AOF rewrite
2、在Redis配置檔案redis.conf中，使用者設定了auto-aof-rewrite-percentage和auto-aof-rewrite-min-size引數，並且當前AOF檔案大小server.aof_current_size大於auto-aof-rewrite-min-size(server.aof_rewrite_min_size)，同時AOF檔案大小的增長率大於auto-aof-rewrite-percentage(server.aof_rewrite_perc)時，會自動觸發AOF rewrite
3、使用者設定“config set appendonly yes”開啟AOF的時，呼叫startAppendOnly函式會觸發rewrite）
4). AOF包含一個格式清晰、易於理解的日誌檔案用於記錄所有的修改操作。事實上，我們也可以通過該檔案完成資料的重建。
AOF的劣勢有哪些呢？
1). 對於相同數量的資料集而言，AOF檔案通常要大於RDB檔案。
2). 根據同步策略的不同，AOF在執行效率上往往會慢於RDB。總之，每秒同步策略的效率是比較高的，同步禁用策略的效率和RDB一樣高效。
四、持久化的配置
1. Snapshotting:
預設情況下，Redis會將資料集的快照dump到dump.rdb檔案中。此外，我們也可以通過配置檔案來修改Redis伺服器dump快照的頻率，在開啟6379.conf檔案之後，我們搜尋save，可以看到下面的配置資訊：
save 900 1 #在900秒(15分鐘)之後，如果至少有1個key發生變化，則dump記憶體快照。
save 300 10 #在300秒(5分鐘)之後，如果至少有10個key發生變化，則dump記憶體快照。
save 60 10000 #在60秒(1分鐘)之後，如果至少有10000個key發生變化，則dump記憶體快照。
2. Dump快照的機制：
1). Redis先fork子程序。
2). 子程序將快照資料寫入到臨時RDB檔案中。
3). 當子程序完成資料寫入操作後，再用臨時檔案替換老的檔案。
3. AOF檔案：
上面已經多次講過，RDB的快照定時dump機制無法保證很好的資料永續性。如果我們的應用確實非常關注此點，我們可以考慮使用Redis中的AOF機制。對於Redis伺服器而言，其預設的機制是RDB，如果需要使用AOF，則需要修改配置檔案中的以下條目：
將 appendonly no 改為 appendonly yes
從現在起，Redis在每一次接收到資料修改的命令之後，都會將其追加到AOF檔案中。在Redis下一次重新啟動時，需要載入AOF檔案中的資訊來構建最新的資料到記憶體中。
4. AOF的配置：
在Redis的配置檔案中存在三種同步方式，它們分別是：
appendfsync always #每次有資料修改發生時都會寫入AOF檔案。
appendfsync everysec #每秒鐘同步一次，該策略為AOF的預設策略。
appendfsync no #從不同步。高效但是資料不會被持久化。
5. 如何修復壞損的AOF檔案：
1). 將現有已經壞損的AOF檔案額外拷貝出來一份。
2). 執行"redis-check-aof --fix <filename>"命令來修復壞損的AOF檔案。
3). 用修復後的AOF檔案重新啟動Redis伺服器。
6. Redis的資料備份：
在Redis中我們可以通過copy的方式線上備份正在執行的Redis資料檔案。這是因為RDB檔案一旦被生成之後就不會再被修改。Redis每次都是將最新的資料dump到一個臨時檔案中，之後在利用rename函式原子性的將臨時檔案改名為原有的資料檔名。因此我們可以說，在任意時刻copy資料檔案都是安全的和一致的。鑑於此，我們就可以通過建立cron job的方式定時備份Redis的資料檔案，並將備份檔案copy到安全的磁碟介質中。
五、實現主從的複製 master/slave
從伺服器的配置：
在配置檔案找到 REPLICATION 區域並加入:
slaveof 192.168.1.103 6379 //slaveif 主伺服器ip 主伺服器埠
//RDB持久化預設開啟
//為從伺服器開啟AOF持久化
[shell]
dir ./ //預設
appendonly yes
appendfilename appendonly.aof
[/shell]
主伺服器配置採用了預設規則.
這樣就可以實現master上的資料 複製到slave上了！
其他操作:
1、用redis-cli bgsave 命令每天凌晨一次持久化一次master redis上的資料，並CP到其它備份伺服器上。
2、用redis-cli bgrewriteaof 命令每半小時持久化一次 slave redis上的資料，並CP到其它備份伺服器上。
3、寫個指令碼 ，定期get master和slave上的key,看兩個是否同步，如果沒有同步，及時報警。
測試
在master 上新增資料
[shell]
redis 192.168.1.103:6379> set name silenceper
OK
[/shell]在slave 上可以使用get name 獲取資料了
[shell]
redis 192.168.1.104:6379> get name
"silenceper"
[/shell]使用phpRedisAdmin 更加直觀的看到資料的更改。
六、主從複製的原理
無論是初次連線還是重新連線， 當建立一個從伺服器時， 從伺服器都將向主伺服器傳送一個 SYNC 命令。
接到 SYNC 命令的主伺服器將開始執行 BGSAVE ， 並在儲存操作執行期間， 將所有新執行的寫入命令都儲存到一個緩衝區裡面。
當 BGSAVE 執行完畢後， 主伺服器將執行儲存操作所得的 .rdb 檔案傳送給從伺服器， 從伺服器接收這個 .rdb 檔案， 並將檔案中的資料載入到記憶體中。
之後主伺服器會以 Redis 命令協議的格式， 將寫命令緩衝區中積累的所有內容都發送給從伺服器。
你可以通過 telnet 命令來親自驗證這個同步過程： 首先連上一個正在處理命令請求的 Redis 伺服器， 然後向它傳送 SYNC 命令， 過一陣子， 你將看到 telnet 會話（session）接收到伺服器發來的大段資料（ .rdb 檔案）， 之後還會看到， 所有在伺服器執行過的寫命令， 都會重新發送到 telnet 會話來。
即使有多個從伺服器同時向主伺服器傳送 SYNC ， 主伺服器也只需執行一次 BGSAVE 命令， 就可以處理所有這些從伺服器的同步請求。
從伺服器可以在主從伺服器之間的連線斷開時進行自動重連， 在 Redis 2.8 版本之前， 斷線之後重連的從伺服器總要執行一次完整重同步（full resynchronization）操作， 但是從 Redis 2.8 版本開始， 從伺服器可以根據主伺服器的情況來選擇執行完整重同步還是部分重同步（partial resynchronization）。