首页 > 代码库 > redis学习三 redis持久化

redis学习三 redis持久化

 

1,快照持久化

     1简介

     redis可以通过创建快照来获得某个时间点上的内存内容的数据副本,有了副本之后,就可以将副本发送到其他redis服务器上从而创建相同数据的从服务器,同时快照留在原地以便重启redis的时候实现数据恢复。

     2配置 

     save 60 1000  快照生成策略  如果服务器距离上一次成功生成快照已经超过六十秒,并且期间执行了至少1000次写操作。
     stop-writes-on-bgsave-error yes 创建快照文件失败后是否继续执行写命令
     rdbcompression yes   是否对快照文件进行压缩
     dbfilename dump.rdb  快照文件名称
     dir /opt/redis-2.8.13/dmp/  持久化文件保存的路径

     3快照文件生成的时机

     1,向redis发送bgsave命令,redis会调用fork来创建一个子进程,子进程负责创建快照,父进程继续处理命令请求。
     2,向redis发送save命令,父进程停止响应其他命令,开始进行快照创建,save命令通常不用,一般在没有足够内存执行bgsave的时候或者让客户端等待也没关系的时候使用。
     3,根据用户设置的save 策略配置信息,进行执行。如果配置多个,只要满足一个就执行。
     4,redis接收到shutdown或者标准term命令的时候,会触发save命令,创建快照。
     5,当从服务器链接到主服务器并且发送sync命令来同步数据的时候,并且这个时候主服务器没有在执行bgsave或者不是刚刚执行完bgsave的话,就创建个快照,以供复制使用。
     当内存数据量不那么大的时候,使用快照持久化比较不错。但是如果数据量达到了十几个G以上的那种,执行一个bgsave会特别慢,save的话会快点,但是也会耗费比较多时间,并且快照文件也比较大。这个时候就需要使用AOF持久化了。

2,AOF持久化

     1简介

     简单来说,AOF持久化会将执行的写命令写到AOF文件末尾来记录所有的变化。redis只要从头到尾执行一次AOF文件的命令,就可以进行数据恢复了。

     2,配置

     appendonly yes  是否打开AOF持久化
     appendfilename "appendonly.aof"  持久化文件名称
     # appendfsync always  每次redis写命令都进行持久化,这样会严重降低redis速度,但是数据基本不丢失
     appendfsync everysec     每秒进行一次,丢失数据也是一秒内的
     # appendfsync no     让操作系统自己决定什么时候执行
     no-appendfsync-on-rewrite no
     auto-aof-rewrite-percentage 100  当aof文件比上次重写之后体积大了至少100%,进行重写
     auto-aof-rewrite-min-size 64mb     当体积岛屿64M的时候重写
     上面这两个条件同时符合的时候才重写。
     dir /opt/redis-2.8.13/dmp/  持久化文件保存的路径

     3,AOF文件重写

     AOF文件由于会不断的追加写入命令,因此体积会越来越大,这时向redis发送bgrewriteaof命令,可以重写aof,将其中的冗余命令删除掉,减小体积,也是主进程fork出一个子进程来处理。针对这个命令也可以配置一下让redis自己维护执行。

3,数据恢复

     当redis服务器挂掉时,重启时将按照以下优先级恢复数据到内存:
     如果只配置AOF,重启时加载AOF文件恢复数据;(将rdb的配置信息都注释掉就关闭了rdb,只要不主动发送bgsave命令就不持久化了)
     如果同时 配置了RBD和AOF,启动是只加载AOF文件恢复数据;
     如果只配置RBD,启动是讲加载dump文件恢复数据。

redis学习三 redis持久化