Redis持久化

Redis学习笔记 持久化

Redis持久化方式

1. 快照

将某个时刻的数据持久化到硬盘中。用户可以对快照进行备份。支持复制到其他服务器。

1.1 创建快照

• bgsave 创建一个快照。Redis会创建一个子进程来负责将快照写入硬盘。父进程继续接受请求。
• save Redis在快照创建完毕前不会接受任何请求。
• shutdown命令用于停止redis服务的时候会执行一次save命令。停止所有请求。
• sync命令进行Redis服务器之间的数据同步的时候。如果主服务器并没有正在进行bgsave或者不是刚刚结束bgsave命令时会执行bgsave命令。

1.2 快照配置

save 60 1000 60秒内有1000次写操作则自动触发bgsave
stop-writes-on-bgsave-error-no 当创建快照失败时是否停止写操作
rdbcompression yes 是否对快照进行压缩
dbfilename dump.rdb 快照名称
dr ./ 快照文件存储的路径

1.3 快照缺陷

• 快照是某一个时间点的内存数据备份。如果在服务器崩溃则会丢失上一次快照到崩溃时的所有变更数据。
• 快照适合即使丢失一部分少量的数据也不会对整个应用造成问题的场景。

《Redis实战》中提到的对日志进行聚合计算。没有看懂到底是什么意思。

• 当大数据处理时，Redis占用的内存会很大，bgsave创建子进程会耗费一定的时间，这个创建的过程则会导致redis停顿。停顿的时间随着Redis占用内存越大而越久。相比较于创建子进程带来的停顿，save并不会因为要创建子进程而去争抢资源导致停顿。故save会较bgsave的速度更快。

2. AOF(append-only file)

将写操作的命令追加到备份文件中。等到需要恢复时（重启）从头到尾执行一遍备份文件中的写命令即可。

2.1 AOF文件重写

随着Redis不断的运行。aof文件会变得越来越大。占用硬盘同时在重启时根据aof重新执行写命令时耗时长。

bgrewriteaof 等同bgsave，会启动子进程来重写aof文件。父进程继续接受请求。

2.2 AOF配置

appendonly yes 是否启用AOF模式
appendfsync everrysec 追加的频率。always每次写操作都同步。everysec每秒执行一次同步，可以同步多条写操作。no 由操作系统来决定何时进行同步。
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100 当aof文件比上一次重写时大了一倍则进行aof文件重写
auto-aof-rewrite-min-size 64mb 当aof文件的大小大于64mb时进行aof文件重写
dr ./ aof文件存储路径

2.3 AOF缺陷

• bgrewriteaof命令创建子进程也会由于redis占用的内存越大而创建子进程的时间越长从而导致redis停顿。
• 对aof文件进行重写时会涉及对旧的aof文件进行删除，如果文件很大很有可能导致操作系统的挂起。

持久化的意义

• 数据重用。redis中很多的数据都是一些经过长时间计算得到的。这样持久化到硬盘中就不必再次计算可以方便下次使用。
• 安全。将数据备份到硬盘防止因系统崩溃而丢失数据。Redis运行时数据都是存储在内存中，而一旦系统奔溃内存中的数据时很大程度会丢失。