redis专题九：redis持久化（上）
作者：互联网
一、持久化简介
面对写入时候，可能会出现一些意外的情况，比方说断电，这个时候就需要恢复数据。
所谓持久化，就是利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的机制。
持久化的目的：防止数据意外丢失，确保数据的安全性。
保存数据一般有两种形式：
- 数据快照（RDB）
- 将数据操作步骤记录下来，不是直接的数据，类似日志（AOF）
二、RDB
2.1 RDB启动的方式
2.1.1 save 命令及工作原理
手动执行一次保存操作。当前快照保存在*.rdb文件中。
save相关配置：
| 配置 | 说明 |
| dbfilename dump.rdb | 可以设置本地数据库文件名，默认dump.rdb |
| dir | 存储.rdb文件的路径 |
| rdbcompression yes | 设置存储至本地数据库时是否需要压缩数据，默认yes，采用LRF压缩 |
| rdbchecksum yes | 设置是否需要进行RDB文件格式校验，该校验过程在读写文件过程都会进行， 通常设置默认开启，否则可能有数据损坏风险 |
save指令的工作原理：
redis是单线程工作的，当有一堆指令过来的时候，按照序列执行。
假如执行到save指令的时候，执行时间很长，那么会阻塞当前Redis服务器，直到当前RDB过程完成为止，又可能会造成长时间的阻塞，一般不建议线上使用。
2.1.2 bgsave命令及工作原理
问题：数据量过大的时候，单线程执行方式效率过低如何处理？
解决：bgsave 指令：手动启动后台保存操作，但不是立即执行
bgsave的工作原理：客户端发送指令给redis后，redis返回启动后台保存开始，然后自己调用fork函数生成子进程来完成这个保存操作，保存成功后返回消息给redis。
bgsave是对save阻塞做出的优化，redis内部所有涉及到RDB操作都采用bgsave的方式来完成。
bgsave还有一个配置需要关注下：
stop-writes-on-bgsave-error yes -------意思是后台存储过程中如果出现错误现象，是否停止保存操作；通常建议开启。
2.1.3 自动执行--save配置
问题：前两种方式都是通过手工执行命令的方式，那能不能自动执行呢？如果可以，多久执行一次呢？因为不知道数据产生了多少变化。
解决：conf文件配置：save seconds changes
作用：满足限定时间范围内key的变化数量达到指定数量即进行持久化。如果指定时间没有达到指令数量超时了，会重新计时，这里也是快照的思想。
参数：seconds : 监控时间范围 changes：监控key变化量
举例：save 1000 1 1000秒有一个变化就保存
save 60 1000 一分钟有1000个变化就保存
save配置的工作原理：
- save 配置在判断计数的时候，不进行数据比对的意思是就算对同一个key set了两次相同的值，也会被认为是两次，影响数量是2而不是1。
- save配置启动执行的是bgsave的操作。
- save配置需要根据实际业务来，频率过高或者过低都容易出现性能问题，结果可能是灾难性的。
2.1.4 几种方式的对比
由于save配置后台使用的也是bgsave，因此我们对比save和bgsave即可。
| 方式 | save | bgsave |
| 读写 | 同步 | 异步 |
| 阻塞客户端指令 | 是 | 否 |
| 额外消耗内存 | 否 | 是 |
| 启动新进程 | 否 | 是 |
2.1.5 RDB的优缺点
优点：
- RDB是一个紧凑压缩的二进制文件，存储效率较高
- RDB内部存储的是redis在某个时间节点的数据快照，非常适合于数据备份，全量复制的场景
- RDB恢复数据的速度比AOF快很多
- 应用：服务器每X个小时执行bgsave备份，并将RDB文件拷贝到远程服务器中，用于灾难恢复
缺点：
- RDB无论是指令执行还是配置执行，都无法做到实时持久化，具有较大的可能性丢失数据
- bgsave指令每次都要fork操作创建子进程，要牺牲一些性能
- Redis众多版本中关于RDB文件格式可能不统一，有可能出现各个版本服务之间数据无法兼容的现象
这一篇就先到这里，下一篇来说AOF。
标签：专题,持久,bgsave,redis,保存,RDB,save,数据 来源： https://blog.csdn.net/sinat_26445485/article/details/118438630