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同时挂掉的话，数据的恢复也能够达到一个可接受的程度。