Redis持久化

Redis持久化

redis是一个内存数据库，当redis服务器重启，获取电脑重启，数据会丢失，我们可以将redis内存中的数据持久化保存到硬盘的文件中。

redis提供两种持久化方式:

        RDB：快照，通过从服务器保存和持久化

        AOF：日志，操作生成相关日志,并通过日志来恢复数据。couchDB对于数据内容,不修改,只追加,则文件本身就是日志,不会丢失数据.

注意：redis默认开启了RDB持久化

firewall-cmd --query-port=6379/tcp
如果返回no则端口没有开启，yes代表开启

firewall-cmd --add-port=6379/tcp --permanent

查看防火墙状态

systemctl status firewalld

暂时关闭防火墙

systemctl stop firewalld

永久关闭防火墙

systemctl disable firewalld

使用redis.conf 文件启动

修改内存大小  配置文件设置maxmemory 1024mb 或者在客户端config set maxmemory  800mb

修改redis 淘汰策略 配置文件设置maxmemory-policy XXX 默认的策略是内存满了所有申请内存的指令都会报错

1、RDB全称redis database backup file(redis 数据备份文件)持久化

进入redis-cli

执行：save #有redis主线程同步执行RDB，会阻塞所有命令

            bgsave #开启子线程异步执行RDB，避免主线程受影响

redis 停机自动执行一次RDB

    在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里,Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

注：fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程，在每次redis服务器启动的时候，会自动把dump.rdb这个文件的键值对 全部读取到内存

步骤一：编辑redis.conf配置文件

RDB快照相关参数：
    save 900 1    #刷新快照到硬盘中，必须满足两者要求才会触发，即900秒之后至少1个关键字发生变化。
    save 300 10  #必须是300秒之后至少10个关键字发生变化。
    save 60 10000 #必须是60秒之后至少10000个关键字发生变化。
    上面三个参数屏闭后，rdb方式就关闭了
    
    stop-writes-on-bgsave-error yes    #后台存储错误停止写。
    rdbcompression yes    #使用LZF压缩rdb文件。
    rdbchecksum yes    #存储和加载rdb文件时校验。
    dbfilename dump.rdb    #设置rdb文件名。
    dir ./    #设置工作目录，rdb文件会写入该目录。

步骤二：重启redis查看数据是否存在

• 先删除dump.rdb

• 使用客户端连接并添加数据

• 杀掉redis进程       pkill -9 redis

• 启动redis查看数据是否存在

RDB的缺陷:在2个保存点之间断电，将会丢失1-N分钟的数据出于对持久化的更精细要求,redis增添了aof方式 append only file

2、AOF日志持久化

进入 redis-cli

config set appendonly yes
或者进入redis.conf 修改 appendonly = yes 默认是no

AOF日志原理

思想：内存每写一条，就备份一条，时间间隔是1秒钟，缺点：文件大，写操作频繁。

• 以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，

• 只许追加文件但不可以改写文件，redis启动之初会读取该文件(aof文件)重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

• aof保存的是appendonly.aof文件

AOF日志相关参数:
    appendonly no # 是否打开aof日志功能  no:不开启   yes:开启日志
    appendfsync always   # 每1个命令,都立即同步到aof. 安全,速度慢
                everysec # 折衷方案,每秒写1次
                no      # 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快
    no-appendfsync-on-rewrite  no # 正在导出rdb快照的过程中,要不要停止同步aof

配置开启AOF日志

配置存储方案

打印日志文件内容

more /usr/local/bin/appendonly.aof

因为没有操作所以没有日志信息

启动redis服务端并启动客户端连接并创建key

查看日志

3、AOF重写

思考：如果对同一个key进行多次操作，在aof日志中怎样表现操作记录，一条还是n条？

案例 ：创建age并改变五次值

日志会将每一步操作都记录，如果要对一个key操作多次，在数据上的表现只有一个但在日志中会有n条记录。当数据丢失需要找回数据的时候怎样找到正确的值？

aof重写是将内存中的key和value逆化为redis命令重新保存到日志中，就好像是将所执行的操作做的总结。

aof重写相关参数:
    no-appendfsync-on-rewrite  no # 正在导出rdb快照的过程中,要不要停止同步aof
    auto-aof-rewrite-percentage 100 #aof文件大小比起上次重写时的大小,增长率100%时,重写
    auto-aof-rewrite-min-size 64mb #aof文件,至少超过64M时,重写

问: 在dump rdb过程中,aof如果停止同步,会不会丢失?

答: 不会,所有的操作缓存在内存的队列里, dump完成后,统一操作.

问: aof重写是指什么?

答: aof重写是指把内存中的数据,逆化成命令,写入到.aof日志里.以解决 aof日志过大的问题.

问: 如果rdb文件,和aof文件都存在,优先用谁来恢复数据?

答: aof

问: 2种是否可以同时用?

答: 可以,而且推荐这么做

问: 恢复时rdb和aof哪个恢复的快

答: rdb快,因为其是数据的内存映射,直接载入到内存,而aof是命令,需要逐条执行

问题思考:在使用rdb做持久化时，我们关掉了redis服务，然后重新打开，保存的数据还在。但在做aof的时候我们将redis服务关闭后再打开数据就没有了。在上面不是配置过rdb持久化吗，为什么没起作用?
答：当rdb中有数据，并开启了AOF选项，重启redis服务后会产生一个空的aof文件，当rdb和aof文件都存在，会以aof文件来恢复数据。

4、持久化总结

官网建议

1）、RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储

2）、AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大

3）、只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.

4）、同时开启两种持久化方式

在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。

5）、性能建议

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。AOF好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite是将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。如果不Enable AOF ，仅靠Master-Slave Replication实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构