Redis的持久化策略
RDB
RDB持久化是指在指定的时间间隔内将redis内存中的数据集快照写入磁盘，实现原理是redis服务在指定的时间间隔内先fork一个子进程，由子进程将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储，生成dump.rdb文件存放在磁盘中。
默认开启，会按照配置的指定时间将内存中的数据快照到磁盘中，创建一个dump.rdb文件，Redis启动时再恢复到内存中。
RDB文件默认存储在: /data 目录中。
root@3f8f9d9b4353:/data# ls -lh
total 4.0K
-rw-r--r--. 1 redis redis 92 Nov 25 13:00 dump.rdb
RDB工作机制
- Redis提供了RDB持久化能力，这个功能可以将Redis在内存中的数据库状态保持在磁盘里面，避免数据意外丢失。
- RDB持久化机制可以手动执行，也可以根据服务器配置选定定期执行操作，该功能可以将某一个时间点的数据快照进行保存到一个RDB文件中。
RDB优势和劣势
| 优势 | 劣势 |
|---|---|
| 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。 | 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。 |
| 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。 | 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。 |
| 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。 | |
| 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。 |
RDB常用参数
-
SAVE：由主进程进行快照，会阻塞其他请求。
-
BGSAVE：通过fork子进程进行快照，不会阻塞其他请求。
AOF
AOF 持久化功能则提供了一种更为可靠的持久化方式。 每当 Redis 接受到会修改数据集的命令时，就会把命令追加到 AOF 文件里，当你重启 Redis 时，AOF 文件里的命令会被重新执行一次，重建数据。AOF默认是关闭的。
因为AOF采用追加的方式，所以文件会越来越大，针对这个问题，新增了重写机制，就是当日志文件大到一定程度的时候，会fork出一条新进程来遍历进程内存中的数据，每条记录对应一条set语句，写到临时文件中，然后再替换到旧的日志文件（类似rdb的操作方式）。默认触发是当aof文件大小是上次重写后大小的一倍且文件大于64M时触发。
AOF优缺点
| 优点 | 缺点 |
|---|---|
| 默认是每秒fsync一次。这样最多丢失1秒数据 | 在相同的数据集下，AOF文件的大小一般会比RDB文件大。 |
| AOF日志文件是一个纯追加的文件。就算服务器突然Crash，也不会出现日志的定位或者损坏问题 | 在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，而在禁止fsync的情况下速度可以达到RDB的水平。 |
| 当AOF文件太大时，Redis会自动在后台进行重写。重写很安全，因为重写是在一个新的文件上进行，同时Redis会继续往旧的文件追加数据。 | |
| AOF把操作命令以简单易懂的格式一条接一条的保存在文件里，很容易导出来用于恢复数据。 |
持久化配置
RDB
前提：
禁止aof： appendonly no，
修改备份时间: save 30 5
在第一个30s内添加数据
127.0.0.1:6379> set a 1
OK
127.0.0.1:6379> set b 2
OK
127.0.0.1:6379> set c 3
OK
127.0.0.1:6379> set d 4
OK
127.0.0.1:6379> set e 5
第二个30s内添加数据
127.0.0.1:6379> set xx 1
OK
127.0.0.1:6379> set yy 2
OK
127.0.0.1:6379> set cc 3
终止redis服务
[root@localhost ~]# ps -ef|grep redis-server
polkitd 4465 4443 0 21:27 pts/0 00:00:00 redis-server 0.0.0.0:6379
root 7237 125687 0 21:28 pts/2 00:00:00 grep --color=auto redis-server
[root@localhost ~]# kill -9 4465
重新启动redis
查看数据是否完整。
AOF
混合方式存储
aof-use-rdb-preamble yes
执行rewrite
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
日志
29:C 08 Aug 2023 22:00:22.948 * AOF rewrite: 2 MB of memory used by copy-on-write
1:M 08 Aug 2023 22:00:22.975 * Background AOF rewrite terminated with success
1:M 08 Aug 2023 22:00:22.975 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
1:M 08 Aug 2023 22:00:22.975 * Background AOF rewrite finished successfully
重新启动redis
1:M 08 Aug 2023 22:04:30.016 * Module 'bf' loaded from /usr/local/etc/redis/redisbloom.so
1:M 08 Aug 2023 22:04:30.016 * Reading RDB preamble from AOF file...
1:M 08 Aug 2023 22:04:30.016 * Loading RDB produced by version 6.2.6
1:M 08 Aug 2023 22:04:30.016 * RDB age 248 seconds
1:M 08 Aug 2023 22:04:30.016 * RDB memory usage when created 0.85 Mb
1:M 08 Aug 2023 22:04:30.016 * RDB has an AOF tail
1:M 08 Aug 2023 22:04:30.016 # Done loading RDB, keys loaded: 12, keys expired: 0.
1:M 08 Aug 2023 22:04:30.016 * Reading the remaining AOF tail...
1:M 08 Aug 2023 22:04:30.016 * DB loaded from append only file: 0.000 seconds
1:M 08 Aug 2023 22:04:30.016 * Ready to accept connections
