redis 数据恢复过程

redis数据淘汰原理

redis过期数据删除策略

redis server事件模型

redis cluster mget 引发的讨论

redis 3.x windows 集群搭建

redis 命令执行过程

redis string底层数据结构

redis list底层数据结构

redis hash底层数据结构

redis set底层数据结构

redis zset底层数据结构

redis 客户端管理

redis 主从同步-slave端

redis 主从同步-master端

redis 主从超时检测

redis aof持久化

redis rdb持久化

redis 数据恢复过程

redis TTL实现原理

redis cluster集群建立

redis cluster集群选主

 redis的数据载入主要是指redis重启时候恢复数据的过程，恢复的数据总共有两种：

 整个aof文件载入的过程其实是非常简单，整体步骤如下：

 aof保存的命令行格式类似"*3\r\n 5\r\nmykey\r\n 字符开始标记字符串长度，知道字符串长度就可以解析出命令字符串了。

 整个rdb文件载入的过程其实是非常简单，不过和aof有些许差别：

rdb文件的数据恢复直接写入内存而不是通过伪装命令行执行命令生成的

rdb文件的读取过程和aof不一样，rdb文件存储按照type+key+value的格式存储所以读取也是这样读取的

整体恢复步骤如下：

描述: 当我们需要备份或迁移Redis集群时可以采用以下方案。

第三方redis集群数据迁移工具项目参考( https://github.com/alibaba/RedisShake )

描述:在系统删除了配置文件后以及用户账号后恢复方法流程，实际环境中建议利用rdb文件进行重新部署。

2.Kubernetes中单实例异常数据迁移恢复实践

方案1.利用其他kubernetes集群进行恢复原k8s集群的redis数据。

命令执行示例:

Tips : 从上述恢复结果可以看出以aof方式恢复的数据比rdb恢复的数据完整，但所加载的时间会随着数据增大会使得AOF方式耗时比rdb耗时更多。

方案2.利用宿主机安装编译redis源码，进行恢复原k8s集群的redis数据

方案3.利用Kubernetes部署的Redis集群，进行恢复原k8s集群的redis数据

Tips : 若id没发生变化，直接重启下该从节点就能解决。

Redis数据的导出和导入：dump和load方式

https://www.jianshu.com/p/03da3b9774d8

内存快照(将内存中的数据在某一时刻的状态记录至磁盘中) 。现实可以理解为拍照。

想象下如果100个人(数据)在拍照，那首先想到的问题这100个人给谁拍照？拍照的同时如果有人"动"了怎么办？基于这些场景繁衍以下问题：

全量快照 ,一次性记录所有数据，保证数据的完整性

Redis 两个命令生成 RDB 文件， save 和 bgsave。

save：在主线程中执行，导致阻塞；

bgsave：创建一个子进程，用于写入 RDB 文件，避免主线程阻塞。(Redis默认配置项使用bgsave)。

采用bgsave因为Redis会fock一个子进程处理，所以读肯定没问题，修改是怎么处理的呢？

Redis借助 *** 作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写 *** 作。具体流程：

主线程 fork 出 bgsave 子进程后，bgsave 子进程实际是复制了主线程的页表。这些页表中，就保存了在执行 bgsave 命令时，主线程的所有数据块在内存中的物理地址。这样一来，bgsave 子进程生成 RDB 时，就可以根据页表读取这些数据，再写入磁盘中。如果此时，主线程接收到了新写或修改 *** 作，那么，主线程会使用写时复制机制。具体来说，写时复制就是指，主线程在有写 *** 作时，才会把这个新写或修改后的数据写入到一个新的物理地址中，并修改自己的页表映射。

如图：

bgsave 子进程复制主线程的页表以后，假如主线程需要修改虚页 7 里的数据，那么，主线程就需要新分配一个物理页（假设是物理页 53），然后把修改后的虚页 7 里的数据写到物理页 53 上，而虚页 7 里原来的数据仍然保存在物理页 33 上。这个时候，虚页 7 到物理页 33 的映射关系，仍然保留在 bgsave 子进程中。所以，bgsave 子进程可以无误地把虚页 7 的原始数据写入 RDB 文件。

一、频繁将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞争有限的磁盘带宽，前一个快照还没有做完，后一个又开始做了，容易造成恶性循环。

二、bgsave 子进程需要通过 fork *** 作从主线程创建出来。虽然，子进程在创建后不会再阻塞主线程，但是，fork 这个创建过程本身会阻塞主线程，而且主线程的内存越大，阻塞时间越长。

快照的恢复速度快，频率无法把控，频率太低，宕机，丢失数据比较多。频率太高，产生额外开销。

混合使用 AOF 日志和内存快照 ，内存快照以一定的频率执行，在两次快照之间， 使用 AOF 日志记录 这期间的所有命令 *** 作。

---