redis持久化和主从复制原理

rdb快照(snapshot)

1. 默认情况下,redis会将内存数据快照保存在dump.rdb的二进制文件中.自己可以设置rdb文件的刷新频率(redis.conf中配置):
   比如:redis在满足60秒内有1000个改动时,会自动保存一次
   eg: save 60 1000
2. 手动生成rdb文件,进入redis客户端手动执行save或bgsave命令,每次执行都会生成当前完整的rdb文件,并覆盖旧的rdb文件.
   save是同步命令,bgsave是异步命令(redis会从主进程fork一个子进程去生成文件)

优点: 文件体积小,服务宕机数据恢复速度快
缺点: 数据容易丢失(在修改没达到对应配置参数条件时服务宕机,之前的数据会丢失)

aof(append-only file)

3. redis1.1开始新增的一种持久化方式,将每一条修改的指令记录进appendonly.aof文件.
4. aof的相关配置参数(redis.conf文件):
   #appendonly yes — 开启aof持久化
   #appendfsync always — 每次有新的命令就追加到aof文件,安全但比较慢
   #appendonly everysec — 每秒fsync一次,故障时只会丢失一秒钟的数据,速度快(推荐,也是默认的)
   #appendonly no — 从不fsync,将数据讲给系统来处理,更快也更不安全
   #auto-aof-rewrite-min-size 64mb — aof文件至少达到64m才会自动重写,如果文件太小,恢复速度本来就快,没有重写的必要.
   #auto-aof-rewrite-percentage 100 — 文件自上次重写增长了百分百就触发重写.
   为什么重写:redis在不影响结果的情况下做的优化,去掉一些冗余的指令.

混合持久化

1. 设置#aof-use-rdb-preamble yes开启混合持久化.
2. 开启混合持久化之后,aof在重写时,不再是简单把内存数据转换成resp命令写入aof文件,而是将重写这一刻之前的内存做rdb快照,并且将rdb快照内容和增量的aof修改命令都放在aof文件中,新的文件重写完成之前不叫appendonly.aof,在重写完成之后,再原子的更换成appendonly.aof.在redis重启之后,会先加载rdb内容,然后在重放aof日志,重启的效率比较高.

redis主从复制原理