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参数来定义快照的周期。下面是默认的快照设置：
| 1 2 3 |
|
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
| 1 2 3 4 5 |
|
AOF的完全持久化方式同时也带来了另一个问题，持久化文件会变得越来越大。比如我们调用INCR test命令100次，文件中就必须保存全部的100条命令，但其实99条都是多余的。因为要恢复数据库的状态其实文件中保存一条SET test 100就够了。为了压缩AOF的持久化文件，Redis提供了bgrewriteaof命令。收到此命令后Redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件，以此来实现控制AOF文件的增长。由于是模拟快照的过程，因此在重写AOF文件时并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件。对应的设置参数为:
# vim /opt/redis/etc/redis_6379.conf
| 1 2 3 |
|
到底选择什么呢？下面是来自官方的建议：
通常，如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。
如果你可以接受灾难带来的几分钟的数据丢失，那么你可以仅使用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
| 1 2 3 4 5 |
|
接着，修改Slave上的如下配置：
# vim /opt/redis/etc/redis_6379.conf
| 1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
分别启动Master与Slave
| 1 |
|
启动完成后在Master中确认未启动Snapshot参数
| 1 2 3 |
|
然后通过以下脚本在Master中生成25万条数据：
# cat redis-cli-generate.temp.sh
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
接着执行该脚本
| 1 2 |
|
在数据的生成过程中，可以很清楚的看到Master上仅在第一次做Slave同步时创建了dump.rdb文件，之后就通过增量传输命令的方式给Slave了。
dump.rdb文件没有再增大。
| 1 2 3 |
|
而Slave上则可以看到dump.rdb文件和AOF文件在不断的增大，并且AOF文件的增长速度明显大于dump.rdb文件。
| 1 2 3 4 |
|
等待数据插入完成以后，首先确认当前的数据量。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 |
|
当前的数据量为25万条key，占用内存31.52M。然后直接Kill掉Master的Redis进程，模拟灾难。
| 1 |
|
接着到Slave中查看状态：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 |
|
可以看到master_link_status的状态已经是down了，Master已经不可访问了。而此时，Slave依然运行良好，并且保留有AOF与RDB文件。
下面将通过Slave上保存好的AOF与RDB文件来恢复Master上的数据。首先，将Slave上的同步状态取消，避免主库在未完成数据恢复前就重启，进而直接覆盖掉从库上的数据，导致所有的数据丢失。
| 1 2 |
|
确认一下已经没有了master相关的配置信息：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
|
在Slave上复制数据文件：
| 1 2 3 |
|
将data.tar上传到Master上，尝试恢复数据:可以看到Master目录下有一个初始化Slave的数据文件，很小，将其删除。
| 1 2 3 4 5 |
|
然后解压缩数据文件：
| 1 2 3 4 5 |
|
启动Master上的Redis
| 1 |
|
查看数据是否恢复：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
|
可以看到25万条数据已经完整恢复到了Master上。此时，可以放心的恢复Slave的同步设置了。
| 1 2 |
|
查看同步状态：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 |
|
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同时挂掉的话，数据的恢复也可以达到一个可接受的程度。