Redis數據"丟失"討論及規避和解決的幾點總結

 

Redis大部分應用場景是 純緩存服務，請求後端有Primary Storage的組件,如MySQL,HBase;請求Redis的鍵未命中，會從primary Storage中獲取數據返回，同時更新Redis緩存。若是少許數據丟失，至關於請求"緩衝未命中"； 通常對業務的影響是無感知的。但 如今Redis用做存儲的業務場景變多，數據丟失對業務是致命的影響。
下面簡單討論幾個Redis常見數據"丟失"現象，以及怎麼規避；

 

數據丟失的影響
-   Redis存儲的應用場景，數據丟失是不能接受的;
-   由於Redis的持久化特性，數據還原很難保證一致性，因rdb全備和aof重寫備份，RPO不能像MySQL這樣保證恢復到故障操做的前一個事務。
-   緩存的應用場景，若是大量緩存數據丟失，每每致使後端存儲組件」打死「，應用程序雪崩的狀況。

 

常見Redis數據丟失的狀況
-   程序bug或人爲誤操做。
-   因客戶端緩衝區內存使用過大，致使大量鍵被LRU淘汰。
-   主庫故障後自動重啓，可能致使數據丟失。
-   網絡分區的問題，可能致使短期的寫入數據丟失。
-   主從複製數據不一致，發生故障切換後，出現數據丟失。
-   大量過時鍵，同時被淘汰清理。

 

程序bug或人爲誤操做
-   程序bug誤刪除數據；
-   DBA/RD誤操做執行flushall/flushdb這類命令。
這類問題的預防和監控
-   重命名危險命令：keys(程度大批量誤刪除，不少經過keys獲取鍵後再刪除)，flushall，flushdb
-   細化幾個重要的監控項：
    -   實例當前的鍵個數(dbsize/info), 當大量鍵丟失時，可經過此項歷史監控圖，定位發生的時間範圍。
    -   各種刪除命令的執行數監控：cmdtats_flushall, cmdstats_flushdb,cmdstat_del。
    -   對應時間範圍，確認具體是什麼操做。

 

因客戶端緩衝區內存使用過大，致使大量鍵被LRU淘汰
因客戶端緩衝區的內存大小很難限制,它們消耗的內存數會計算在used_memory內；若是使用不當，致使緩衝區內存使用過大，達到maxmemory限制；（緩存場景）會致使大量的鍵被淘汰，最壞會把全部鍵清理，緩衝無鍵可淘汰，寫入失敗。至關於整個緩衝失效，對業務影響較大。

這類問題的預防和監控：
-   業務容量規劃時把緩衝正常消耗計算在內，合理高大maxmemory的限制；
每一個實例最好可預留幾百M(大小根據客戶端鏈接數和key的使用有關，根據大小集羣合理調整)。
-   對輸出緩衝區設置合理limit；如normal設置10MB, SLAVE設置1GB等。 若是複製因slave線程輸出緩衝區反覆同步，需臨時調大slave client-output-buffer，要同時調大maxmemory限制。
-   主要監控
     -   監控內存使用大小 used_memory。
     -   監控兩個buffer的使用量client_longest_output_list和client_biggest_input_buf。
     -   監控鍵的LRU驅逐數量：evicted_keys。

 

主庫故障後自動重啓，可能致使數據所有丟失
這種故障發生，極有可能數據所有丟失。
問題發生的現象：時間點T1,主庫故障關閉了，因設置有自動重啓的守護程序，時間點T2主庫被從新拉起，因(T2-T1)時間間隔太小，未達到Redis集羣或哨兵的主從切換判斷時長；這樣從庫發現主庫runid變了或斷開過，會全量同步主庫rdb清理，並清理本身的數據。而爲保障性能,Redis主庫每每不作數據持久化設置，那麼時間點T2啓動的主庫，頗有多是個空實例（或好久前的rdb文件）。這種問題發生時間間隔，通常小於1分鐘，可能監控告警沒法感知到。
這類老是的預防和監控：
-   強烈反對Redis粗暴地設置自動重啓。
-   這種監控鍵個數的變化，緩存命中率，同時ELK類型準實時監控redis日誌變化並告警。

建議：數據庫這類重「狀態性」服務，不建議程序暴力自動重啓！

 

網絡分區的問題，可能致使短期的寫入數據丟失
這種問題出現丟失數據都不多，網絡分區時，Redis集羣或哨兵在判斷故障切換的時間窗口，這段時間寫入到原主庫的數據，5秒~15秒的寫入量。

 

主從複製數據不一致，發生故障切換後，出現數據丟失
主從數據出現不一致，發生故障切換，從庫提高爲主後，致使數據丟失的狀況。

 

大量過時鍵，同時被淘汰清理
這類狀況不是真正的「數據丟失」，只是按期主動清理Redis堆積的過時鍵，會致使Redis的鍵個數(dbsize)出現陡降(最大能達20%）。業務方常誤覺得有數據丟失。
這時可經過監控過時鍵淘汰的數量：expireed_keys的增加量，與dbsize鍵總數減小數據量是否相等。

 

======================================================================================

Redis的數據回寫機制

Redis的數據回寫機制分同步和異步兩種，
-  同步回寫即SAVE命令，主進程直接向磁盤迴寫數據。在數據大的狀況下會致使系統假死很長時間，因此通常不是推薦的。
-  異步回寫即BGSAVE命令，主進程fork後，複製自身並經過這個新的進程回寫磁盤，回寫結束後新進程自行關閉。因爲這樣作不須要主進程阻塞，系統不會假死，通常默認會採用這個方法。

 

我的感受方法２採用fork主進程的方式很拙劣，但彷佛是惟一的方法。內存中的熱數據隨時可能修改，要在磁盤上保存某個時間的內存鏡像必需要凍結。凍結就會致使假死。fork一個新的進程以後等於複製了當時的一個內存鏡像，這樣主進程上就不須要凍結，只要子進程上操做就能夠了。

 

在小內存的進程上作一個fork,不須要太多資源，但當這個進程的內存空間以Ｇ爲單位時，fork就成爲一件很恐怖的操做。況且在16G內存的主機上fork 14G內存的進程呢？確定會報內存沒法分配的。更可氣的是，越是改動頻繁的主機上fork也越頻繁，fork操做自己的代價恐怕也不會比假死好多少。

找到緣由以後，直接修改/etc/sysctl.conf內核參數vm.overcommit_memory= 1
而後執行sysctl -p

 

Linux內核會根據參數vm.overcommit_memory參數的設置決定是否放行。
-  若是 vm.overcommit_memory = 1，直接放行
-  vm.overcommit_memory = 0：則比較 這次請求分配的虛擬內存大小和系統當前空閒的物理內存加上swap，決定是否放行。
-  vm.overcommit_memory= 2：則會比較進程全部已分配的虛擬內存加上這次請求分配的虛擬內存和系統當前的空閒物理內存加上swap，決定是否放行。

 

Redis持久化實踐及災難恢復模擬
1）對Redis持久化的探討與理解
目前Redis持久化的方式有兩種： RDB 和 AOF
首先，咱們應該明確持久化的數據有什麼用，答案是用於重啓後的數據恢復。Redis是一個內存數據庫，不管是RDB仍是AOF，都只是其保證數據恢復的措施。因此Redis在利用RDB和AOF進行恢復的時候，都會讀取RDB或AOF文件，從新加載到內存中。RDB就是Snapshot快照存儲，是默認的持久化方式。可理解爲半持久化模式，即按照必定的策略週期性的將數據保存到磁盤。對應產生的數據文件爲dump.rdb，經過配置文件中的save參數來定義快照的週期。下面是默認的快照設置：

save 900 1    #當有一條Keys數據被改變時，900秒刷新到Disk一次
save 300 10   #當有10條Keys數據被改變時，300秒刷新到Disk一次
save 60 10000 #當有10000條Keys數據被改變時，60秒刷新到Disk一次

Redis的RDB文件不會壞掉，由於其寫操做是在一個新進程中進行的。當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，而後經過原子性rename系統調用將臨時文件重命名爲RDB文件。

 

同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。 第一次Slave向Master同步的實現是：Slave向Master發出同步請求，Master先dump出rdb文件，而後將rdb文件全量傳輸給slave，而後Master把緩存的命令轉發給Slave，初次同步完成。 第二次以及之後的同步實現是：Master將變量的快照直接實時依次發送給各個Slave。但無論什麼緣由致使Slave和Master斷開重連都會重複以上兩個步驟的過程。Redis的主從複製是創建在內存快照的持久化基礎上的，只要有Slave就必定會有內存快照發生。

能夠很明顯的看到，RDB有它的不足，就是一旦數據庫出現問題，那麼咱們的RDB文件中保存的數據並非全新的。從上次RDB文件生成到Redis停機這段時間的數據所有丟掉了。

 

AOF(Append-Only File)比RDB方式有更好的持久化性。
因爲在使用AOF持久化方式時，Redis會將每個收到的寫命令都經過Write函數追加到文件中，相似於MySQL的binlog。當Redis重啓是會經過從新執行文件中保存的寫命令來在內存中重建整個數據庫的內容。對應的設置參數爲：
# vim /opt/redis/etc/redis_6379.conf

appendonly yes       #啓用AOF持久化方式
appendfilename appendonly.aof #AOF文件的名稱，默認爲appendonly.aof
# appendfsync always #每次收到寫命令就當即強制寫入磁盤，是最有保證的徹底的持久化，但速度也是最慢的，通常不推薦使用。
appendfsync everysec #每秒鐘強制寫入磁盤一次，在性能和持久化方面作了很好的折中，是受推薦的方式。
# appendfsync no     #徹底依賴OS的寫入，通常爲30秒左右一次，性能最好可是持久化最沒有保證，不被推薦。

AOF的徹底持久化方式同時也帶來了另外一個問題，持久化文件會變得愈來愈大。好比咱們調用INCR test命令100次，文件中就必須保存所有的100條命令，但其實99條都是多餘的。由於要恢復數據庫的狀態其實文件中保存一條SET test 100就夠了。爲了壓縮AOF的持久化文件，Redis提供了bgrewriteaof命令。收到此命令後Redis將使用與快照相似的方式將內存中的數據以命令的方式保存到臨時文件中，最後替換原來的文件，以此來實現控制AOF文件的增加。因爲是模擬快照的過程，所以在重寫AOF文件時並無讀取舊的AOF文件，而是將整個內存中的數據庫內容用命令的方式重寫了一個新的AOF文件。對應的設置參數爲:
# vim /opt/redis/etc/redis_6379.conf

no-appendfsync-on-rewrite yes   #在日誌重寫時，不進行命令追加操做，而只是將其放在緩衝區裏，避免與命令的追加形成DISK IO上的衝突。
auto-aof-rewrite-percentage 100 #當前AOF文件大小是上第二天志重寫獲得AOF文件大小的二倍時，自動啓動新的日誌重寫過程。
auto-aof-rewrite-min-size 64mb  #當前AOF文件啓動新的日誌重寫過程的最小值，避免剛剛啓動Reids時因爲文件尺寸較小致使頻繁的重寫。

到底選擇什麼呢？下面是來自官方的建議：
一般，若是你要想提供很高的數據保障性，那麼建議你同時使用兩種持久化方式。
若是你能夠接受災難帶來的幾分鐘的數據丟失，那麼你能夠僅使用RDB。
不少用戶僅使用了AOF，可是咱們建議，既然RDB能夠時不時的給數據作個完整的快照，而且提供更快的重啓，因此最好仍是也使用RDB。
所以，但願能夠在將來（長遠計劃）統一AOF和RDB成一種持久化模式。

 

在數據恢復方面：
RDB的啓動時間會更短，緣由有兩個：
-  RDB文件中每一條數據只有一條記錄，不會像AOF日誌那樣可能有一條數據的屢次操做記錄。因此每條數據只須要寫一次就好了。
-  RDB文件的存儲格式和Redis數據在內存中的編碼格式是一致的，不須要再進行數據編碼工做，因此在CPU消耗上要遠小於AOF日誌的加載。

 

2）災難恢復模擬
既然持久化的數據的做用是用於重啓後的數據恢復，那麼咱們就很是有必要進行一次這樣的災難恢復模擬了。據稱若是數據要作持久化又想保證穩定性，則建議留空一半的物理內存。由於在進行快照的時候，fork出來進行dump操做的子進程會佔用與父進程同樣的內存，真正的copy-on-write，對性能的影響和內存的耗用都是比較大的。目前，一般的設計思路是利用Replication機制來彌補aof、snapshot性能上的不足，達到了數據可持久化。即Master上Snapshot和AOF都不作，來保證Master的讀寫性能，而Slave上則同時開啓Snapshot和AOF來進行持久化，保證數據的安全性。首先，修改Master上的以下配置：
# vim /opt/redis/etc/redis_6379.conf

#save 900 1 #禁用Snapshot
#save 300 10
#save 60 10000

appendonly no #禁用AOF

接着，修改Slave上的以下配置：
# vim /opt/redis/etc/redis_6379.conf

save 900 1 #啓用Snapshot
save 300 10
save 60 10000

appendonly yes #啓用AOF
appendfilename appendonly.aof #AOF文件的名稱
# appendfsync always
appendfsync everysec #每秒鐘強制寫入磁盤一次
# appendfsync no  

no-appendfsync-on-rewrite yes   #在日誌重寫時，不進行命令追加操做
auto-aof-rewrite-percentage 100 #自動啓動新的日誌重寫過程
auto-aof-rewrite-min-size 64mb  #啓動新的日誌重寫過程的最小值

分別啓動Master與Slave

# /etc/init.d/redis start

啓動完成後在Master中確認未啓動Snapshot參數

redis 127.0.0.1:6379> CONFIG GET save
1) "save"
2) ""

而後經過如下腳本在Master中生成25萬條數據：
# cat redis-cli-generate.temp.sh

#!/bin/bash

REDISCLI="redis-cli -a slavepass -n 1 SET"
ID=1

while(($ID<50001))
do
  INSTANCE_NAME="i-2-$ID-VM"
  UUID=`cat /proc/sys/kernel/random/uuid`
  PRIVATE_IP_ADDRESS=10.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`.`echo "$RANDOM % 255 + 1" | bc`\
  CREATED=`date "+%Y-%m-%d %H:%M:%S"`

  $REDISCLI vm_instance:$ID:instance_name "$INSTANCE_NAME"
  $REDISCLI vm_instance:$ID:uuid "$UUID"
  $REDISCLI vm_instance:$ID:private_ip_address "$PRIVATE_IP_ADDRESS"
  $REDISCLI vm_instance:$ID:created "$CREATED"

  $REDISCLI vm_instance:$INSTANCE_NAME:id "$ID"

  ID=$(($ID+1))
done

接着執行該腳本

# chmod 755 redis-cli-generate.temp.sh
# ./redis-cli-generate.temp.sh

在數據的生成過程當中，能夠很清楚的看到Master上僅在第一次作Slave同步時建立了dump.rdb文件，以後就經過增量傳輸命令的方式給Slave了。
dump.rdb文件沒有再增大。

# ls -lh
total 4.0K
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb

而Slave上則能夠看到dump.rdb文件和AOF文件在不斷的增大，而且AOF文件的增加速度明顯大於dump.rdb文件。

# ls -lh
total 24M
-rw-r--r-- 1 root root 15M Sep 27 12:06 appendonly.aof
-rw-r--r-- 1 root root 9.2M Sep 27 12:06 dump.rdb

等待數據插入完成之後，首先確認當前的數據量。

redis 127.0.0.1:6379> info
redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:27623
run_id:e00757f7b2d6885fa9811540df9dfed39430b642
uptime_in_seconds:1541
uptime_in_days:0
lru_clock:650187
used_cpu_sys:69.28
used_cpu_user:7.67
used_cpu_sys_children:0.00
used_cpu_user_children:0.00
connected_clients:1
connected_slaves:1
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33055824
used_memory_human:31.52M
used_memory_rss:34717696
used_memory_peak:33055800
used_memory_peak_human:31.52M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:0
changes_since_last_save:250000
bgsave_in_progress:0
last_save_time:1348677645
bgrewriteaof_in_progress:0
total_connections_received:250007
total_commands_processed:750019
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:246
vm_enabled:0
role:master
slave0:10.6.1.144,6379,online
db1:keys=250000,expires=0

當前的數據量爲25萬條key，佔用內存31.52M。而後直接Kill掉Master的Redis進程，模擬災難。

# killall -9 redis-server

接着到Slave中查看狀態：

redis 127.0.0.1:6379> info
redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:13003
run_id:9b8b398fc63a26d160bf58df90cf437acce1d364
uptime_in_seconds:1627
uptime_in_days:0
lru_clock:654181
used_cpu_sys:29.69
used_cpu_user:1.21
used_cpu_sys_children:1.70
used_cpu_user_children:1.23
connected_clients:1
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33047696
used_memory_human:31.52M
used_memory_rss:34775040
used_memory_peak:33064400
used_memory_peak_human:31.53M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:1
changes_since_last_save:3308
bgsave_in_progress:0
last_save_time:1348718951
bgrewriteaof_in_progress:0
total_connections_received:4
total_commands_processed:250308
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:694
vm_enabled:0
role:slave
aof_current_size:17908619
aof_base_size:16787337
aof_pending_rewrite:0
aof_buffer_length:0
aof_pending_bio_fsync:0
master_host:10.6.1.143
master_port:6379
master_link_status:down
master_last_io_seconds_ago:-1
master_sync_in_progress:0
master_link_down_since_seconds:25
slave_priority:100
db1:keys=250000,expires=0

能夠看到master_link_status的狀態已是down了，Master已經不可訪問了。而此時，Slave依然運行良好，而且保留有AOF與RDB文件。下面將經過Slave上保存好的AOF與RDB文件來恢復Master上的數據。首先，將Slave上的同步狀態取消，避免主庫在未完成數據恢復前就重啓，進而直接覆蓋掉從庫上的數據，致使全部的數據丟失。

redis 127.0.0.1:6379> SLAVEOF NO ONE
OK

確認一下已經沒有了master相關的配置信息：

redis 127.0.0.1:6379> INFO
redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:13003
run_id:9b8b398fc63a26d160bf58df90cf437acce1d364
uptime_in_seconds:1961
uptime_in_days:0
lru_clock:654215
used_cpu_sys:29.98
used_cpu_user:1.22
used_cpu_sys_children:1.76
used_cpu_user_children:1.42
connected_clients:1
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33047696
used_memory_human:31.52M
used_memory_rss:34779136
used_memory_peak:33064400
used_memory_peak_human:31.53M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:1
changes_since_last_save:0
bgsave_in_progress:0
last_save_time:1348719252
bgrewriteaof_in_progress:0
total_connections_received:4
total_commands_processed:250311
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:1119
vm_enabled:0
role:master
aof_current_size:17908619
aof_base_size:16787337
aof_pending_rewrite:0
aof_buffer_length:0
aof_pending_bio_fsync:0
db1:keys=250000,expires=0

在Slave上覆制數據文件：

# tar cvf /home/kevin/data.tar *
appendonly.aof
dump.rdb

將data.tar上傳到Master上，嘗試恢復數據:能夠看到Master目錄下有一個初始化Slave的數據文件，很小，將其刪除。

#ls -l
total 4
-rw-r--r-- 1 root root 10 Sep 27 00:40 dump.rdb

# rm -f dump.rdb

而後解壓縮數據文件：

# tar xf /home/kevin/data.tar
# ls -lh
total 29M
-rw-r--r-- 1 root root 18M Sep 27 01:22 appendonly.aof
-rw-r--r-- 1 root root 12M Sep 27 01:22 dump.rdb

啓動Master上的Redis

# /etc/init.d/redis start

查看數據是否恢復：

redis 127.0.0.1:6379> INFO
redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:16959
run_id:6e5ba6c053583414e75353b283597ea404494926
uptime_in_seconds:22
uptime_in_days:0
lru_clock:650292
used_cpu_sys:0.18
used_cpu_user:0.20
used_cpu_sys_children:0.00
used_cpu_user_children:0.00
connected_clients:1
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33047216
used_memory_human:31.52M
used_memory_rss:34623488
used_memory_peak:33047192
used_memory_peak_human:31.52M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:0
changes_since_last_save:0
bgsave_in_progress:0
last_save_time:1348680180
bgrewriteaof_in_progress:0
total_connections_received:1
total_commands_processed:1
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
vm_enabled:0
role:master
db1:keys=250000,expires=0

能夠看到25萬條數據已經完整恢復到了Master上。此時，能夠放心的恢復Slave的同步設置了。

redis 127.0.0.1:6379> SLAVEOF 192.168.10.10 6379
OK

查看同步狀態：

redis 127.0.0.1:6379> INFO
redis_version:2.4.17
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
gcc_version:4.4.5
process_id:13003
run_id:9b8b398fc63a26d160bf58df90cf437acce1d364
uptime_in_seconds:2652
uptime_in_days:0
lru_clock:654284
used_cpu_sys:30.01
used_cpu_user:2.12
used_cpu_sys_children:1.76
used_cpu_user_children:1.42
connected_clients:2
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:33056288
used_memory_human:31.52M
used_memory_rss:34766848
used_memory_peak:33064400
used_memory_peak_human:31.53M
mem_fragmentation_ratio:1.05
mem_allocator:jemalloc-3.0.0
loading:0
aof_enabled:1
changes_since_last_save:0
bgsave_in_progress:0
last_save_time:1348719252
bgrewriteaof_in_progress:1
total_connections_received:6
total_commands_processed:250313
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:12217
vm_enabled:0
role:slave
aof_current_size:17908619
aof_base_size:16787337
aof_pending_rewrite:0
aof_buffer_length:0
aof_pending_bio_fsync:0
master_host:10.6.1.143
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_priority:100
db1:keys=250000,expires=0

master_link_status顯示爲up，同步狀態正常。

 

在這次恢復的過程當中，同時複製了AOF與RDB文件，那麼究竟是哪個文件完成了數據的恢復呢？
實際上，當Redis服務器掛掉時，重啓時將按照如下優先級恢復數據到內存：
a）若是隻配置AOF,重啓時加載AOF文件恢復數據；
b）若是同時 配置了RDB和AOF,啓動是隻加載AOF文件恢復數據;
c）若是隻配置RDB,啓動是將加載dump文件恢復數據。

也就是說，AOF的優先級要高於RDB，這也很好理解，由於AOF自己對數據的完整性保障要高於RDB。

在這次的案例中，經過在Slave上啓用了AOF與RDB來保障了數據，並恢復了Master。但在實際的線上環境中，可能因爲數據都設置有過時時間，採用AOF的方式會不太實用，過於頻繁的寫操做會使AOF文件增加到異常的龐大，大大超過了咱們實際的數據量，這也會致使在進行數據恢復時耗用大量的時間。所以，能夠在Slave上僅開啓Snapshot來進行本地化，同時能夠考慮將save中的頻率調高一些或者調用一個計劃任務來進行按期bgsave的快照存儲，來儘量的保障本地化數據的完整性。在這樣的架構下，若是僅僅是Master掛掉，Slave完整，數據恢復可達到100%。若是Master與Slave同時掛掉的話，數據的恢復也能夠達到一個可接受的程度。