1. 什么是Redis持久化？
持久化是把事务的瞬时状态转化到持久状态。
数据持久化，狭隘的理解为把存储在内存中的数据进行一定的编码存储到持久化介质(例如磁带，磁盘，nand flash)的过程
1.1 Rerdis 有哪几种持久化？
RDB 形式持久化
AOF 形式持久化
RDB+AOF混合形式持久化
官网介绍： http://redis.io/topics/persistence
1.2 什么场景需要Redis持久化？
1.数据并非核心,允许丢失部分:
2.或者兜底溯源数据库根本满足不了业务的性能需求:
3.或者直接利用redis服务本身高可用来达到数据不丢失: 成本太高
4.低成本的离线数据分析
2. RDB持久化
2.1 RDB是什么？
1.RDB属于redis内存数据的snapshots，即某时刻快照
2.RDB采用紧凑型二进制保存
2.2 启用RDB
- RDB 配置
- dbfilename dump.rdb
配置rdb的文件名- save <seconds> <changes>
表示经过多少 second 后，如果至少多少个变更的key，那么就会执行rdb snapshots一次
例如：save 900 1- stop-write-on-bgsave-error yes
当rdb快照失败的时候，那么后续的变更key的请求都会返回错误(-MISCONF Errors)，即请求失败。
默认配置是yes，即如果开启了rdb，那么还是建议启用这个配置。如果本身rdb并不重要，丢失一段时间没关系，那么可以关闭。- rdbcompression yes
当rdb快照过程中，遇上key或者value是字符串，并且长度大于等于20的时候就会采用lzf进行压缩，并带上RDB_ENC_LZF标识，以便解析，建议配置。
好处是：节省了大量的存储空间，在对rdb进行备份，迁移时节省时间
坏处是：消耗了部分cpu，不管是rdb save过程还是load过程，所以相对分析时间会长一些。- rdbchecksum yes
启用该配置，会在生成rdb快照过程中，对所有的数据进行crc64计算，以便rdb解析时能够检验，判断rdb是否有被修改;
这其中会消耗部分cpu算力，影响性能。如果都是rdb不公开，可以不设置。
# rdb持久化策略
save 900 1
save 300 10
save 60 10000
# 启用压缩
rdbcompression yes
# 启用校验
rdbchecksum yes
# 保存的文件位置
dbfilename "redis-6379.rdb"
2.3 可以使用以下的指令主动进行rdb持久化
- RDB持久化过程
redis-cli -h 127.0.0.1 -p 6379 save
[root@192 conf]# redis-cli -h 127.0.0.1 -p 6379 save
OK
2.4 查看rdb文件内容
od -A x -t x1c -v redis-6379.rdb
[root@192 conf]# od -A x -t x1c -v redis-6379.rdb
000000 52 45 44 49 53 30 30 30 39 fa 09 72 65 64 69 73
R E D I S 0 0 0 9 372 \t r e d i s
000010 2d 76 65 72 06 35 2e 30 2e 31 34 fa 0a 72 65 64
- v e r 006 5 . 0 . 1 4 372 \n r e d
000020 69 73 2d 62 69 74 73 c0 40 fa 05 63 74 69 6d 65
i s - b i t s 300 @ 372 005 c t i m e
000030 c2 c5 77 28 63 fa 08 75 73 65 64 2d 6d 65 6d c2
302 305 w ( c 372 \b u s e d - m e m 302
000040 78 06 0d 00 fa 0c 61 6f 66 2d 70 72 65 61 6d 62
x 006 \r \0 372 \f a o f - p r e a m b
000050 6c 65 c0 00 fe 00 fb 01 00 00 07 6d 79 72 65 64
l e 300 \0 376 \0 373 001 \0 \0 \a m y r e d
000060 69 73 05 68 65 6c 6c 6f ff 74 f2 37 e6 d7 1f 8c
i s 005 h e l l o 377 t 362 7 346 327 037 214
000070 35
5
000071
3. AOF持久化
3.1 AOF是什么
AOF主要是记录每一个对数据有更改(删除,新增，update)的命令，通过不同的策略将他们一一持久化到文件。
后续如果有其他redis server根据这个备份启动的时候,会读取aof文件，读取里面的命令就像收到用户命令请求一样执行命令,重构整个数据集。
3.2 启用AOF
- AOF持久化配置
- appendonly no
更改为yes则为开启AOF持久化- appendfilename "appendonly.aof"
这里指定了持久化文件的名称- aof fsync模式
a. appendtsync always
总是每次写入都强制刷盘，同步刷盘会影响整个系统的运行，影响性能,但是可靠性最好
b. appendfsync everysec
每秒强制刷盘默认是这个,影响适中,并且即使发生故障,也是秒级丢失
c. appendtsync no
让操作系统自己控制刷盘，影响由系统控制，需要结合系统配置，丢失不可控- no-appendfsync-on-rewrite no
在aof 整理重写的时候不进行刷盘。重写是避免aof文件不断增大，在符合一定条件情况下，根据某个时刻的redis数据集进行类似快照，但是快照格式是以aof的格式，而不是rdb格式- 哪种条件下进行重写:
auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
- 根据上一次的rewrite后的aof大小，判断当前的aof大小是否是增长了1倍
- 最小rewrite的aof文件大小
- 同时满足才会进行rewrite
- aof-load-truncated yes
在进行aof加载重放的时候有问题是否不退出(尽可能多的load数据，截取aof文件最后一个正常的位置并给出log提示)- aof-use-rdb-preamble yes
是否使用在rewrite全量数据的时候使用rdb格式
# 启用aof持久化
appendonly yes
# 持久化的文件名
appendfilename "appendonly-6379.aof"
# 持久化机制
appendfsync everysec
3.3 tips 关于spop如何持久化的问题
因为AOF是存的指令，那么对于一些随机的存储的指令，是如何记录的呢？ 比如 spop指令。其实在存储起来的时候，是使用 srem 指令来替代的，那么这样就能在恢复数据的时候保持一致性。
3.4 如何查看aof 文件？
可以直接打开文件进行查看，但是看到的内容可能会比较难阅读，大致的内容如下
[root@192 conf]# cat appendonly-6379.aof
*2
$6
SELECT
$1
0
*3
$4
sadd
$5
hello
$8
necodeng
*3
$4
sadd
$5
hello
$4
neco
*3
$4
SREM
$5
hello
$8
necodeng
更方便的方式 aof-selector
aof-selector
- 下载并且解压和重命名
# 下载
wget https://github.com/hongliuliao/aof-selector/archive/refs/heads/master.zip
# 解压
unzip master.zip
# 重命名
mv aof-selector-master aof-seletcor
- 编译
# 进入指定目录
cd aof-selector
# 编译，这里如果有报错找不到g++，那么请按照下方的内容进行安装g++相关的内容
make
- 安装g++
yum install gcc-c++
- 查看指定的指令的内容，如下方为查看set指令相关的内容
cat ./appendonly-6379.aof | /etc/softwares/aof-selector/output/bin/aof-selector -w 0 -i SET
运行结果如下
...
SET key:000000008690 xxx
SET key:000000007726 xxx
SET key:000000001304 xxx
SET key:000000006182 xxx
...
3.5 AOF持久化过程
4. 混合持久化
4.1 为什么需要混合持久化?
4.2 什么是混合持久化
如果觉得有收获就点个赞吧，更多知识，请点击关注查看我的主页信息哦~
