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檔案。對應的設定參數為:
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上的如下配置：
#save 900 1 #禁用Snapshot
#save 300 10
#save 60 10000
appendonly no #禁用AOF
接着，修改Slave上的如下配置：
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同時挂掉的話，資料的恢複也可以達到一個可接受的程度。
*************** 當你發現自己的才華撐不起野心時，就請安靜下來學習吧！***************