文章目录
一、持久化
1.持久化简介
1.1 什么是持久化
持久化是指将数据保存到持久介质（如硬盘、数据库）中，使其在程序关闭或系统重启后仍然存在，不会因为程序的结束而丢失。在计算机领域，持久化通常用于保存应用程序的数据，以便在下次使用时能够快速恢复并继续使用。常见的持久化方式包括文件存储、数据库存储等。
1.2 持久化过程保存什么
持久化过程保存的内容取决于具体应用程序或系统的需求，但通常包括以下内容：
- 数据库中的数据：持久化技术常用于将应用程序中的数据保存到数据库中，以便在应用程序重新启动或崩溃后恢复数据。
- 文件系统中的文件：应用程序可能需要将用户数据或其他文件保存到文件系统中，以便在应用程序重新启动或崩溃后恢复数据。
- 应用程序的配置信息：应用程序可能需要将其设置和配置信息保存到文件或数据库中，以便在下次启动时恢复这些设置。
- 缓存中的数据：持久化技术可以用于将缓存中的数据保存到磁盘中，以便在应用程序重新启动或崩溃后恢复数据。
- 状态信息：应用程序可能需要保存其状态信息，以便在应用程序重新启动或崩溃后恢复状态。
- 日志和审计信息：应用程序可能需要将其日志和审计信息保存到文件或数据库中，以便在后续审计和故障排除时使用。
数据快照和过程日志是两种不同的数据记录方式。
- 数据快照是在某个时间点对系统中的数据进行拍摄和记录，记录下系统中的数据状态。这种记录方式可以作为系统备份的一种形式，也可以用于系统还原和故障排除。例如在数据库中进行数据备份时，可以使用数据快照来记录某个时间点的数据状态。
- 过程日志则是在系统运行过程中记录下各种操作和事件。这种记录方式可以帮助开发者和管理员追踪系统运行过程中的错误和异常，以便于进行故障排除和性能优化。例如在服务器上运行的应用程序会记录下各种操作和事件到日志文件中，以便于管理员进行监控和分析。
总结一下：
- 第一种：将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据。
- 第二种：将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程。
2.RDB
2.1 save指令
手动执行一次保存操作
save
save指令相关配置
设置本地数据库文件名，默认值为 dump.rdb，通常设置为dump-端口号.rdb
dbfilename filename
设置存储.rdb文件的路径，通常设置成存储空间较大的目录中，目录名称data
dir path
设置存储至本地数据库时是否压缩数据，默认yes，设置为no，节省 CPU 运行时间，但存储文件变大
rdbcompression yes|no
设置读写文件过程是否进行RDB格式校验，默认yes，设置为no，节约读写10%时间消耗，单存在数据损坏的风险
rdbchecksum yes|no
save指令工作原理
需要注意一个问题，来看一下，现在有四个客户端各自要执行一个指令，把这些指令发送到redis服务器后，他们执行有一个先后顺序问题，假定就是按照1234的顺序放过去的话，那会是什么样的？
记得redis是个单线程的工作模式，它会创建一个任务队列，所有的命令都会进到这个队列里边，在这儿排队执行，执行完一个消失一个，当所有的命令都执行完了，OK，结果达到了。
但是如果现在我们执行的时候save指令保存的数据量很大会是什么现象呢？
他会非常耗时，以至于影响到它在执行的时候，后面的指令都要等，所以说这种模式是不友好的，这是save指令对应的一个问题，当cpu执行的时候会阻塞redis服务器，直到他执行完毕，所以说我们不建议大家在线上环境用save指令。
2.2 bgsave指令
之前我们讲到了当save指令的数据量过大时，单线程执行方式造成效率过低，那应该如何处理？
此时我们可以使用：bgsave指令，bg其实是background的意思，后台执行的意思
手动启动后台保存操作，但不是立即执行
bgsave
bgsave指令相关配置
后台存储过程中如果出现错误现象，是否停止保存操作，默认yes
stop-writes-on-bgsave-error yes|no
其 他
dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no
bgsave指令工作原理
当执行bgsave的时候，客户端发出bgsave指令给到redis服务器。注意，这个时候服务器马上回一个结果告诉客户端后台已经开始了，与此同时它会创建一个子进程，使用Linux的fork函数创建一个子进程，让这个子进程去执行save相关的操作，此时我们可以想一下，我们主进程一直在处理指令，而子进程在执行后台的保存，它会不会干扰到主进程的执行吗？
答案是不会，所以说他才是主流方案。子进程开始执行之后，它就会创建啊RDB文件把它存起来，操作完以后他会把这个结果返回，也就是说bgsave的过程分成两个过程，第一个是服务端拿到指令直接告诉客户端开始执行了；另外一个过程是一个子进程在完成后台的保存操作，操作完以后回一个消息。
2.3 save配置自动执行
设置自动持久化的条件，满足限定时间范围内key的变化数量达到指定数量即进行持久化
save second changes
参数
second：监控时间范围
changes：监控key的变化量
范例：
save 900 1
save 300 10
save 60 10000
其他相关配置：
dbfilename filename
dir path
rdbcompression yes|no
rdbchecksum yes|no
stop-writes-on-bgsave-error yes|no
save配置工作原理
2.4 RDB三种启动方式对比
| 方式 | save指令 | bgsave指令 |
|---|---|---|
| 读写 | 同步 | 异步 |
| 阻塞客户端指令 | 是 | 否 |
| 额外内存消耗 | 否 | 是 |
| 启动新进程 | 否 | 是 |
RDB特殊启动形式
服务器运行过程中重启
debug reload
关闭服务器时指定保存数据
shutdown save
全量复制（在主从复制中详细讲解）
RDB优点：
- RDB是一个紧凑压缩的二进制文件，存储效率较高
- RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
- RDB恢复数据的速度要比AOF快很多
- 应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。
RDB缺点
- RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
- bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
- Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象
3.AOF
为什么要有AOF,这得从RDB的存储的弊端说起：
- 存储数据量较大，效率较低，基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
- 大数据量下的IO性能较低
- 基于fork创建子进程，内存产生额外消耗
- 宕机带来的数据丢失风险
那解决的思路是什么呢？
- 不写全数据，仅记录部分数据
- 降低区分数据是否改变的难度，改记录数据为记录操作过程
- 对所有操作均进行记录，排除丢失数据的风险
3.1 AOF概念
AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令 达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化
AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式
AOF写数据过程
启动AOF相关配置
开启AOF持久化功能，默认no，即不开启状态
appendonly yes|no
AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口号.aof
appendfilename filename
AOF持久化文件保存路径，与RDB持久化文件保持一致即可
dir
AOF写数据策略，默认为everysec
appendfsync always|everysec|no
3.2 AOF执行策略
AOF写数据三种策略(appendfsync)
-
always(每次）：每次写入操作均同步到AOF文件中数据零误差，性能较低，不建议使用。
-
everysec（每秒）：每秒将缓冲区中的指令同步到AOF文件中，在系统突然宕机的情况下丢失1秒内的数据 数据准确性较高，性能较高，建议使用，也是默认配置
-
no（系统控制）：由操作系统控制每次同步到AOF文件的周期，整体过程不可控
3.3 AOF重写
场景：AOF写数据遇到的问题，如果连续执行如下指令该如何处理
什么叫AOF重写？
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重 写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。
AOF重写作用
- 降低磁盘占用量，提高磁盘利用率
- 提高持久化效率，降低持久化写时间，提高IO性能
- 降低数据恢复用时，提高数据恢复效率
AOF重写规则
-
进程内具有时效性的数据，并且数据已超时将不再写入文件
-
非写入类的无效指令将被忽略，只保留最终数据的写入命令
如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
如select指令虽然不更改数据，但是更改了数据的存储位置，此类命令同样需要记录
-
对同一数据的多条写命令合并为一条命令
如lpushlist1 a、lpush list1 b、lpush list1 c可以转化为：lpush list1 a b c。
为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素
AOF重写方式
- 手动重写
bgrewriteaof
手动重写原理分析：
- 自动重写
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage
自动重写触发条件设置
auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percent
自动重写触发比对参数（ 运行指令info Persistence获取具体信息 ）
aof_current_size
aof_base_size
自动重写触发条件公式：
3.4 AOF工作流程及重写流程
4.RDB与AOF区别
4.1 RDB与AOF对比（优缺点）
| 持久化方式 | RDB | AOF |
|---|---|---|
| 占用存储空间 | 小（数据级：压缩） | 大（指令级：重写） |
| 存储速度 | 慢 | 快 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 会丢失数据 | 依据策略决定 |
| 资源消耗 | 高/重量级 | 低/轻量级 |
| 启动优先级 | 低 | 高 |
4.2 RDB与AOF应用场景
RDB与AOF的选择之惑
- 对数据非常敏感，建议使用默认的AOF持久化方案
AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，当出现问题时，最多丢失0-1秒内的数据。
注意：由于AOF文件存储体积较大，且恢复速度较慢
- 数据呈现阶段有效性，建议使用RDB持久化方案
数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用RDB方案
注意：利用RDB实现紧凑的数据持久化会使Redis降的很低，慎重总结：
综合比对
- RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
- 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
- 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
- 灾难恢复选用RDB
- 双保险策略，同时开启 RDB和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量