Redis大部分應(yīng)用場景是純緩存服務(wù)，請求后端有Primary Storage的組件,如MySQL,HBase;請求Redis的鍵未命中润梯，會從primary Storage中獲取數(shù)據(jù)返回，同時更新Redis緩存轩猩。如果少量數(shù)據(jù)丟失，相當于請求"緩沖未命中"； 一般對業(yè)務(wù)的影響是無感知的庭瑰。但現(xiàn)在Redis用作存儲的業(yè)務(wù)場景變多，數(shù)據(jù)丟失對業(yè)務(wù)是致命的影響抢埋。

下面簡單討論幾個Redis常見數(shù)據(jù)"丟失"現(xiàn)象弹灭，以及怎么規(guī)避；

數(shù)據(jù)丟失的影響

- Redis存儲的應(yīng)用場景揪垄，數(shù)據(jù)丟失是不能接受的;

- 因為Redis的持久化特性穷吮，數(shù)據(jù)還原很難保證一致性，因rdb全備和aof重寫備份饥努，RPO不能像MySQL這樣保證恢復到故障操作的前一個事務(wù)捡鱼。

- 緩存的應(yīng)用場景，如果大量緩存數(shù)據(jù)丟失酷愧，往往導致后端存儲組件”打死“堰汉，應(yīng)用程序雪崩的情況。

常見Redis數(shù)據(jù)丟失的情況

- 程序bug或人為誤操作伟墙。

- 因客戶端緩沖區(qū)內(nèi)存使用過大，導致大量鍵被LRU淘汰滴铅。

- 主庫故障后自動重啟戳葵，可能導致數(shù)據(jù)丟失。

- 網(wǎng)絡(luò)分區(qū)的問題汉匙，可能導致短時間的寫入數(shù)據(jù)丟失拱烁。

- 主從復制數(shù)據(jù)不一致，發(fā)生故障切換后噩翠，出現(xiàn)數(shù)據(jù)丟失戏自。

- 大量過期鍵，同時被淘汰清理伤锚。

程序bug或人為誤操作

- 程序bug誤刪除數(shù)據(jù)擅笔；

- DBA/RD誤操作執(zhí)行flushall/flushdb這類命令。

這類問題的預防和監(jiān)控

- 重命名危險命令：keys(程度大批量誤刪除屯援，很多通過keys獲取鍵后再刪除)猛们，flushall，flushdb

- 細化幾個重要的監(jiān)控項：

- 實例當前的鍵個數(shù)(dbsize/info), 當大量鍵丟失時狞洋，可通過此項歷史監(jiān)控圖弯淘，定位發(fā)生的時間范圍。

- 各類刪除命令的執(zhí)行數(shù)監(jiān)控：cmdtats_flushall, cmdstats_flushdb,cmdstat_del吉懊。

- 對應(yīng)時間范圍庐橙，確認具體是什么操作假勿。

因客戶端緩沖區(qū)內(nèi)存使用過大，導致大量鍵被LRU淘汰

因客戶端緩沖區(qū)的內(nèi)存大小很難限制,它們消耗的內(nèi)存數(shù)會計算在used_memory內(nèi)态鳖；如果使用不當转培，導致緩沖區(qū)內(nèi)存使用過大，達到maxmemory限制郁惜；（緩存場景）會導致大量的鍵被淘汰堡距，最壞會把所有鍵清理，緩沖無鍵可淘汰兆蕉，寫入失敗羽戒。相當于整個緩沖失效，對業(yè)務(wù)影響較大虎韵。

這類問題的預防和監(jiān)控：

- 業(yè)務(wù)容量規(guī)劃時把緩沖正常消耗計算在內(nèi)易稠，合理高大maxmemory的限制；

每個實例最好可預留幾百M(大小根據(jù)客戶端連接數(shù)和key的使用有關(guān)包蓝，根據(jù)大小集群合理調(diào)整)驶社。

- 對輸出緩沖區(qū)設(shè)置合理limit；如normal設(shè)置10MB, SLAVE設(shè)置1GB等测萎。 如果復制因slave線程輸出緩沖區(qū)反復同步亡电，需臨時調(diào)大slave client-output-buffer，要同時調(diào)大maxmemory限制硅瞧。

- 主要監(jiān)控

- 監(jiān)控內(nèi)存使用大小 used_memory份乒。

- 監(jiān)控兩個buffer的使用量client_longest_output_list和client_biggest_input_buf。

- 監(jiān)控鍵的LRU驅(qū)逐數(shù)量：evicted_keys腕唧。

主庫故障后自動重啟或辖，可能導致數(shù)據(jù)全部丟失

這種故障發(fā)生，極有可能數(shù)據(jù)全部丟失枣接。

問題發(fā)生的現(xiàn)象：時間點T1,主庫故障關(guān)閉了颂暇，因設(shè)置有自動重啟的守護程序，時間點T2主庫被重新拉起但惶，因(T2-T1)時間間隔過小耳鸯，未達到Redis集群或哨兵的主從切換判斷時長；這樣從庫發(fā)現(xiàn)主庫runid變了或斷開過膀曾，會全量同步主庫rdb清理片拍，并清理自己的數(shù)據(jù)。而為保障性能,Redis主庫往往不做數(shù)據(jù)持久化設(shè)置妓肢，那么時間點T2啟動的主庫捌省，很有可能是個空實例（或很久前的rdb文件）。這種問題發(fā)生時間間隔碉钠，一般小于1分鐘纲缓，可能監(jiān)控告警無法感知到卷拘。

這類總是的預防和監(jiān)控：

- 強烈反對Redis粗暴地設(shè)置自動重啟。

- 這種監(jiān)控鍵個數(shù)的變化祝高，緩存命中率栗弟，同時ELK類型準實時監(jiān)控redis日志變化并告警。

建議：數(shù)據(jù)庫這類重“狀態(tài)性”服務(wù)工闺，不建議程序暴力自動重啟乍赫！

網(wǎng)絡(luò)分區(qū)的問題，可能導致短時間的寫入數(shù)據(jù)丟失

這種問題出現(xiàn)丟失數(shù)據(jù)都很少陆蟆，網(wǎng)絡(luò)分區(qū)時雷厂，Redis集群或哨兵在判斷故障切換的時間窗口，這段時間寫入到原主庫的數(shù)據(jù)叠殷，5秒~15秒的寫入量改鲫。

主從復制數(shù)據(jù)不一致，發(fā)生故障切換后林束，出現(xiàn)數(shù)據(jù)丟失

主從數(shù)據(jù)出現(xiàn)不一致像棘，發(fā)生故障切換，從庫提升為主后壶冒，導致數(shù)據(jù)丟失的情況缕题。

大量過期鍵，同時被淘汰清理

這類情況不是真正的“數(shù)據(jù)丟失”胖腾，只是定期主動清理Redis堆積的過期鍵避除，會導致Redis的鍵個數(shù)(dbsize)出現(xiàn)陡降(最大能達20%）。業(yè)務(wù)方常誤以為有數(shù)據(jù)丟失胸嘁。

這時可通過監(jiān)控過期鍵淘汰的數(shù)量：expireed_keys的增長量，與dbsize鍵總數(shù)減少數(shù)據(jù)量是否相等凉逛。

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

Redis的數(shù)據(jù)回寫機制

Redis的數(shù)據(jù)回寫機制分同步和異步兩種性宏，

- 同步回寫即SAVE命令，主進程直接向磁盤回寫數(shù)據(jù)状飞。在數(shù)據(jù)大的情況下會導致系統(tǒng)假死很長時間毫胜，所以一般不是推薦的。

- 異步回寫即BGSAVE命令诬辈，主進程fork后酵使，復制自身并通過這個新的進程回寫磁盤，回寫結(jié)束后新進程自行關(guān)閉焙糟。由于這樣做不需要主進程阻塞口渔，系統(tǒng)不會假死，一般默認會采用這個方法穿撮。

個人感覺方法２采用fork主進程的方式很拙劣缺脉，但似乎是唯一的方法痪欲。內(nèi)存中的熱數(shù)據(jù)隨時可能修改，要在磁盤上保存某個時間的內(nèi)存鏡像必須要凍結(jié)攻礼。凍結(jié)就會導致假死业踢。fork一個新的進程之后等于復制了當時的一個內(nèi)存鏡像，這樣主進程上就不需要凍結(jié)礁扮，只要子進程上操作就可以了知举。

在小內(nèi)存的進程上做一個fork,不需要太多資源，但當這個進程的內(nèi)存空間以Ｇ為單位時太伊，fork就成為一件很恐怖的操作雇锡。何況在16G內(nèi)存的主機上fork 14G內(nèi)存的進程呢？肯定會報內(nèi)存無法分配的倦畅。更可氣的是遮糖，越是改動頻繁的主機上fork也越頻繁，fork操作本身的代價恐怕也不會比假死好多少叠赐。

找到原因之后欲账，直接修改/etc/sysctl.conf內(nèi)核參數(shù)vm.overcommit_memory= 1

然后執(zhí)行sysctl -p

Linux內(nèi)核會根據(jù)參數(shù)vm.overcommit_memory參數(shù)的設(shè)置決定是否放行。

- 如果 vm.overcommit_memory = 1芭概，直接放行

- vm.overcommit_memory = 0：則比較 此次請求分配的虛擬內(nèi)存大小和系統(tǒng)當前空閑的物理內(nèi)存加上swap赛不，決定是否放行。

- vm.overcommit_memory= 2：則會比較進程所有已分配的虛擬內(nèi)存加上此次請求分配的虛擬內(nèi)存和系統(tǒng)當前的空閑物理內(nèi)存加上swap罢洲，決定是否放行踢故。

Redis持久化實踐及災(zāi)難恢復模擬

1）對Redis持久化的探討與理解

目前Redis持久化的方式有兩種： RDB 和 AOF

首先，我們應(yīng)該明確持久化的數(shù)據(jù)有什么用惹苗，答案是用于重啟后的數(shù)據(jù)恢復殿较。Redis是一個內(nèi)存數(shù)據(jù)庫，無論是RDB還是AOF桩蓉，都只是其保證數(shù)據(jù)恢復的措施淋纲。所以Redis在利用RDB和AOF進行恢復的時候私恬，都會讀取RDB或AOF文件兄猩，重新加載到內(nèi)存中。RDB就是Snapshot快照存儲操漠，是默認的持久化方式业汰』锴裕可理解為半持久化模式，即按照一定的策略周期性的將數(shù)據(jù)保存到磁盤样漆。對應(yīng)產(chǎn)生的數(shù)據(jù)文件為dump.rdb为障，通過配置文件中的save參數(shù)來定義快照的周期。下面是默認的快照設(shè)置：

save9001#當有一條Keys數(shù)據(jù)被改變時，900秒刷新到Disk一次

save30010#當有10條Keys數(shù)據(jù)被改變時产场，300秒刷新到Disk一次

save6010000#當有10000條Keys數(shù)據(jù)被改變時鹅髓，60秒刷新到Disk一次

同時，Redis的RDB文件也是Redis主從同步內(nèi)部實現(xiàn)中的一環(huán)京景。第一次Slave向Master同步的實現(xiàn)是：Slave向Master發(fā)出同步請求窿冯，Master先dump出rdb文件，然后將rdb文件全量傳輸給slave确徙，然后Master把緩存的命令轉(zhuǎn)發(fā)給Slave醒串，初次同步完成。第二次以及以后的同步實現(xiàn)是：Master將變量的快照直接實時依次發(fā)送給各個Slave鄙皇。但不管什么原因?qū)е耂lave和Master斷開重連都會重復以上兩個步驟的過程芜赌。Redis的主從復制是建立在內(nèi)存快照的持久化基礎(chǔ)上的，只要有Slave就一定會有內(nèi)存快照發(fā)生伴逸。Redis的RDB文件不會壞掉缠沈，因為其寫操作是在一個新進程中進行的。當生成一個新的RDB文件時错蝴，Redis生成的子進程會先將數(shù)據(jù)寫到一個臨時文件中洲愤，然后通過原子性rename系統(tǒng)調(diào)用將臨時文件重命名為RDB文件。

可以很明顯的看到顷锰，RDB有它的不足柬赐，就是一旦數(shù)據(jù)庫出現(xiàn)問題，那么我們的RDB文件中保存的數(shù)據(jù)并不是全新的官紫。從上次RDB文件生成到Redis停機這段時間的數(shù)據(jù)全部丟掉了肛宋。

AOF(Append-Only File)比RDB方式有更好的持久化性。

由于在使用AOF持久化方式時束世，Redis會將每一個收到的寫命令都通過Write函數(shù)追加到文件中酝陈，類似于MySQL的binlog。當Redis重啟是會通過重新執(zhí)行文件中保存的寫命令來在內(nèi)存中重建整個數(shù)據(jù)庫的內(nèi)容毁涉。對應(yīng)的設(shè)置參數(shù)為：

# 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的完全持久化方式同時也帶來了另一個問題渗常，持久化文件會變得越來越大。比如我們調(diào)用INCR test命令100次汗盘，文件中就必須保存全部的100條命令皱碘，但其實99條都是多余的。因為要恢復數(shù)據(jù)庫的狀態(tài)其實文件中保存一條SET test 100就夠了隐孽。為了壓縮AOF的持久化文件癌椿，Redis提供了bgrewriteaof命令。收到此命令后Redis將使用與快照類似的方式將內(nèi)存中的數(shù)據(jù)以命令的方式保存到臨時文件中菱阵，最后替換原來的文件踢俄，以此來實現(xiàn)控制AOF文件的增長。由于是模擬快照的過程晴及，因此在重寫AOF文件時并沒有讀取舊的AOF文件都办，而是將整個內(nèi)存中的數(shù)據(jù)庫內(nèi)容用命令的方式重寫了一個新的AOF文件。對應(yīng)的設(shè)置參數(shù)為:

# vim /opt/redis/etc/redis_6379.conf

no-appendfsync-on-rewrite yes#在日志重寫時虑稼，不進行命令追加操作琳钉，而只是將其放在緩沖區(qū)里，避免與命令的追加造成DISK IO上的沖突动雹。

auto-aof-rewrite-percentage100#當前AOF文件大小是上次日志重寫得到AOF文件大小的二倍時槽卫，自動啟動新的日志重寫過程。

auto-aof-rewrite-min-size64mb#當前AOF文件啟動新的日志重寫過程的最小值胰蝠，避免剛剛啟動Reids時由于文件尺寸較小導致頻繁的重寫歼培。

在數(shù)據(jù)恢復方面：到底選擇什么呢？下面是來自官方的建議：

通常茸塞，如果你要想提供很高的數(shù)據(jù)保障性躲庄，那么建議你同時使用兩種持久化方式。

如果你可以接受災(zāi)難帶來的幾分鐘的數(shù)據(jù)丟失钾虐，那么你可以僅使用RDB噪窘。

很多用戶僅使用了AOF，但是我們建議效扫，既然RDB可以時不時的給數(shù)據(jù)做個完整的快照倔监，并且提供更快的重啟，所以最好還是也使用RDB菌仁。

因此浩习，希望可以在未來（長遠計劃）統(tǒng)一AOF和RDB成一種持久化模式。

RDB的啟動時間會更短济丘，原因有兩個：

- RDB文件中每一條數(shù)據(jù)只有一條記錄谱秽，不會像AOF日志那樣可能有一條數(shù)據(jù)的多次操作記錄洽蛀。所以每條數(shù)據(jù)只需要寫一次就行了。

- RDB文件的存儲格式和Redis數(shù)據(jù)在內(nèi)存中的編碼格式是一致的疟赊，不需要再進行數(shù)據(jù)編碼工作郊供，所以在CPU消耗上要遠小于AOF日志的加載。

2）災(zāi)難恢復模擬

既然持久化的數(shù)據(jù)的作用是用于重啟后的數(shù)據(jù)恢復近哟，那么我們就非常有必要進行一次這樣的災(zāi)難恢復模擬了驮审。據(jù)稱如果數(shù)據(jù)要做持久化又想保證穩(wěn)定性，則建議留空一半的物理內(nèi)存椅挣。因為在進行快照的時候头岔，fork出來進行dump操作的子進程會占用與父進程一樣的內(nèi)存，真正的copy-on-write鼠证，對性能的影響和內(nèi)存的耗用都是比較大的峡竣。目前，通常的設(shè)計思路是利用Replication機制來彌補aof量九、snapshot性能上的不足适掰，達到了數(shù)據(jù)可持久化。即Master上Snapshot和AOF都不做荠列，來保證Master的讀寫性能类浪，而Slave上則同時開啟Snapshot和AOF來進行持久化，保證數(shù)據(jù)的安全性肌似。首先费就，修改Master上的如下配置：

# vim /opt/redis/etc/redis_6379.conf

#save 900 1 #禁用Snapshot

#save 300 10

#save 60 10000

appendonlyno#禁用AOF

接著，修改Slave上的如下配置：

# vim /opt/redis/etc/redis_6379.conf

save9001#啟用Snapshot

save30010

save6010000

appendonly yes#啟用AOF

appendfilename appendonly.aof#AOF文件的名稱

# appendfsync always

appendfsync everysec#每秒鐘強制寫入磁盤一次

# appendfsync no

no-appendfsync-on-rewrite yes#在日志重寫時川队，不進行命令追加操作

auto-aof-rewrite-percentage100#自動啟動新的日志重寫過程

auto-aof-rewrite-min-size64mb#啟動新的日志重寫過程的最小值

分別啟動Master與Slave

# /etc/init.d/redis start

啟動完成后在Master中確認未啟動Snapshot參數(shù)

redis 127.0.0.1:6379> CONFIG GET save

1) "save"

2) ""

然后通過以下腳本在Master中生成25萬條數(shù)據(jù)：

# 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"`

$REDISCLIvm_instance:$ID:instance_name"$INSTANCE_NAME"

$REDISCLIvm_instance:$ID:uuid"$UUID"

$REDISCLIvm_instance:$ID:private_ip_address"$PRIVATE_IP_ADDRESS"

$REDISCLIvm_instance:$ID:created"$CREATED"

$REDISCLIvm_instance:$INSTANCE_NAME:id"$ID"

ID=$(($ID+1))

done

接著執(zhí)行該腳本

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

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

在數(shù)據(jù)的生成過程中力细，可以很清楚的看到Master上僅在第一次做Slave同步時創(chuàng)建了dump.rdb文件，之后就通過增量傳輸命令的方式給Slave了固额。

dump.rdb文件沒有再增大眠蚂。

#ls-lh

total4.0K

-rw-r--r--1rootroot10Sep27 00:40dump.rdb

而Slave上則可以看到dump.rdb文件和AOF文件在不斷的增大，并且AOF文件的增長速度明顯大于dump.rdb文件斗躏。

#ls-lh

total24M

-rw-r--r--1rootroot15MSep27 12:06appendonly.aof

-rw-r--r--1rootroot9.2MSep27 12:06dump.rdb

等待數(shù)據(jù)插入完成以后逝慧，首先確認當前的數(shù)據(jù)量。

redis127.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

當前的數(shù)據(jù)量為25萬條key啄糙，占用內(nèi)存31.52M笛臣。然后直接Kill掉Master的Redis進程，模擬災(zāi)難隧饼。

# killall -9 redis-server

接著到Slave中查看狀態(tài)：

redis127.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的狀態(tài)已經(jīng)是down了沈堡，Master已經(jīng)不可訪問了。而此時桑李，Slave依然運行良好踱蛀，并且保留有AOF與RDB文件。下面將通過Slave上保存好的AOF與RDB文件來恢復Master上的數(shù)據(jù)贵白。首先率拒，將Slave上的同步狀態(tài)取消，避免主庫在未完成數(shù)據(jù)恢復前就重啟禁荒，進而直接覆蓋掉從庫上的數(shù)據(jù)猬膨，導致所有的數(shù)據(jù)丟失。

redis127.0.0.1:6379>SLAVEOFNOONE

OK

確認一下已經(jīng)沒有了master相關(guān)的配置信息：

redis127.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上復制數(shù)據(jù)文件：

# tar cvf /home/kevin/data.tar *

appendonly.aof

dump.rdb

將data.tar上傳到Master上呛伴，嘗試恢復數(shù)據(jù):可以看到Master目錄下有一個初始化Slave的數(shù)據(jù)文件勃痴，很小，將其刪除热康。

#ls-l

total4

-rw-r--r--1rootroot10Sep27 00:40dump.rdb

#rm-fdump.rdb

然后解壓縮數(shù)據(jù)文件：

# tar xf /home/kevin/data.tar

# ls -lh

total29M

-rw-r--r--1root root18M Sep2701:22appendonly.aof

-rw-r--r--1root root12M Sep2701:22dump.rdb

啟動Master上的Redis

# /etc/init.d/redis start

查看數(shù)據(jù)是否恢復：

redis127.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萬條數(shù)據(jù)已經(jīng)完整恢復到了Master上沛申。此時，可以放心的恢復Slave的同步設(shè)置了姐军。

redis 127.0.0.1:6379> SLAVEOF 192.168.10.10 6379

OK

查看同步狀態(tài)：

redis127.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

在此次恢復的過程中铁材，同時復制了AOF與RDB文件，那么到底是哪一個文件完成了數(shù)據(jù)的恢復呢奕锌？master_link_status顯示為up著觉，同步狀態(tài)正常。

實際上惊暴，當Redis服務(wù)器掛掉時饼丘，重啟時將按照以下優(yōu)先級恢復數(shù)據(jù)到內(nèi)存：

a）如果只配置AOF,重啟時加載AOF文件恢復數(shù)據(jù)；

b）如果同時 配置了RDB和AOF,啟動是只加載AOF文件恢復數(shù)據(jù);

c）如果只配置RDB,啟動是將加載dump文件恢復數(shù)據(jù)辽话。

也就是說肄鸽，AOF的優(yōu)先級要高于RDB，這也很好理解屡穗，因為AOF本身對數(shù)據(jù)的完整性保障要高于RDB贴捡。

在此次的案例中，通過在Slave上啟用了AOF與RDB來保障了數(shù)據(jù)村砂，并恢復了Master烂斋。但在實際的線上環(huán)境中，可能由于數(shù)據(jù)都設(shè)置有過期時間础废，采用AOF的方式會不太實用汛骂，過于頻繁的寫操作會使AOF文件增長到異常的龐大，大大超過了我們實際的數(shù)據(jù)量评腺，這也會導致在進行數(shù)據(jù)恢復時耗用大量的時間帘瞭。因此，可以在Slave上僅開啟Snapshot來進行本地化蒿讥，同時可以考慮將save中的頻率調(diào)高一些或者調(diào)用一個計劃任務(wù)來進行定期bgsave的快照存儲蝶念，來盡可能的保障本地化數(shù)據(jù)的完整性抛腕。在這樣的架構(gòu)下，如果僅僅是Master掛掉媒殉，Slave完整担敌，數(shù)據(jù)恢復可達到100%。如果Master與Slave同時掛掉的話廷蓉，數(shù)據(jù)的恢復也可以達到一個可接受的程度全封。

***************當你發(fā)現(xiàn)自己的才華撐不起野心時，就請安靜下來學習吧***************