环境:
系统:centos 6.4
redis:3.2.0
机器ip: 192.168.10.160 , 192.168.10.161
redis的持久化有两种 , RDB和AOF , 这两种方式都有他们的特点, 可以根据特点在不同的应用场景使用
RDB原理和场景:
说到rdb的原理,首先要说到这个的触发条件 , 一种是手动触发 , 一种是自动触发
自动触发 的条件是在 配置文件 中配置的 ,
save 900 1 #900s的时间内如果有一个key有变化,就会触发rdb
save 300 10 #300s的时间内如果有10个key有变化
save 60 10000 #60s的时间内如果有10000个key有变化
可以通过 save "" 来禁用
手动触发 是通过在客户端命令行执行 save 或者 bgsave 命令触发的
这两个命令的区别在于 是否会阻塞 当前的客户端请求, save会阻塞客户端请求 , 而bgsave不会阻塞客户端请求,
save是占用当前的主进程将所有的redis数据快照到 rdb 文件中
bgsave是主进程fork一个子进程 , 然后通过 copy - on - write 来讲数据快照到rdb文件中
但是bgsave有一个缺陷 , 因为是使用的 copy - on - write 技术 , 所以 RDB模式需要Redis服务所占内存的1倍的内存 ,如果数据量太大而内存太小的话,
就会导致 数据不会完整的快照到rdb文件中 , 所以rdb技术只是适合备份 , 如果是需要可靠性的话,就需要 AOF 来支持了,下面会介绍 AOF技术
bgsave的工作流程:
- Redis调用fork()。于是我们有了父子两个进程。
- 子进程开始将数据集写入一个临时RDB文件。
- 当子进程完成了新RDB文件,替换掉旧文件。
rdb除了备份以外 , 另一个重要的应用场景就是 主从同步 了 , 关于redis的主从同步,我的下一篇文章会详细说明
AOF的原理和场景:
aof的方式是类似于 mysql的binlog , 如果大家对于mysql比较熟悉的话,可能会理解的很快 , 和mysql 的binlog 的区别就是 , binlog是可以用于进行mysql主从同步的,
但是aof只是redis用于持久化的方式 .
aof的原理就是用户在客户端的操作命令都会记录到aof文件中 , 触发的条件在配置文件中进行配置 ,
appendonly yes //启用aof持久化方式
# appendfsync always //收到写命令就立即写入磁盘, 最慢 , 但是能够保证完全的持久化
appendfsync everysec //每分钟写入磁盘一次, 在性能和持久化之间做了很好的折中 (默认配置, 很好)
#appendfsync no //完全依赖os, 性能最好 , 持久化没有保证
aof主要用户对数据需要高可靠性的场景.
但是记录每次用户的操作记录 , 可能造成的后果是 出现很多的无用指令 , 就是可以被优化的 , 所以 aof 又有着两个配置 ,对aof文件进行重写 ,
#当aof文件达到64m的时候,会自动 重写 aof文件 ,缩小文件大小
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
这段配置的意思是 当aof的文件到达 64m 的时候, 对aof文件进行重写 , 使得aof文件变得更小 , 以后每增长 100%(64m , 128m , 192m ... ) 的时候,都会触发这个优化动作;
但是aof的这个重写操作的原理是 rewrite会像replication一样,fork出一个子进程,创建一个临时文件,遍历数据库,将每个key、value对输出到临时文件。 也就是说 ,
还是 copy-on-write 的问题 ...
每当Redis需要转储数据集到磁盘时,会发生:
- Redis调用fork()。于是我们有了父子两个进程。
- 子进程开始将数据集写入一个临时RDB文件。
- 当子进程完成了新RDB文件,替换掉旧文件。