本篇文章给大家带来的内容是介绍redis的持久化和主从复制机制，有一定的参考价值，有需要的朋友可以参考一下，希望对你有所帮助。
Redis持久化
Redis 提供了多种不同级别的持久化方式：
RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）
AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行本文来源gao($daima.com搞@代@#码(网5这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
你甚至可以关闭持久化功能，让数据只在服务器运行时存在。
RDB(Redis DataBase)
Rdb:在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的 snapshot 快照，它恢复时就是将快照文件直接读到内存里。
Redis 会单独的创建(fork) 一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束了，再用这个临时文件替换上次持久化还的文件。整个过程总，主进程是不进行任何 IO 操作，这就确保了极高的性能，如果需要进行大规模的数据恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方法要比 AOF 方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失。
Fork 的作用是复制一个与当前进程一样的进程，新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
隐患：若当前的进程的数据量庞大，那么 fork 之后数据量*2,此时就会造成服务器压力大，运行性能降低。
Rdb 保存的是 dump.rdb 文件
在测试：执行 flushAll 命令, 使用 shutDown 直接关闭进程时，第二次打开时 redis 会自动读取 dump.rdb 文件，但是恢复时，全为空。(此时的原因：在关闭时刻，redis 系统会保存空的 dump.rdb 替换原来的缓存文件。所以第二次打开的 redis系统时候，自动读取的是空值文件)
RDB save 操作
Rdb 是整个内存的压缩的 snapshot，RDB 的数据结构，可以配置符合快照触发条件，默认的是 1 分钟内改动 1 万次，或者 5 分钟改动 10 次，或者是 15 分钟改动一次；
Save 禁用：如果想禁用 RDB 持久化的策略，只要不设置任何 save 指令，或者是给 save 传入一个空字符串参数也可以。
—–> save 指令：即刻保存操作对象
如何触发 RDB 快照
Save：save 时只管保存，其他不管，全部阻塞。
Bgsave：redis 会在后台进行快照操作，快照操作的同时还可以响应客户端的请求，可以通过 lastsave 命令获取最后一次成功执行快照的时间。
执行 fluhall 命令，也会产生 dump.rdb 文件，但里面是空的。
如何恢复:
将备份文件(dump.rdb)移动到 redis 安装目录并启动服务即可
Config get dir 命令可获取目录
转载请注明原文链接：Redis的持久化和主从复制机制介绍
