redis 虽然是一个内存级别的缓存程序,即 redis 是使用内存进行数据的缓存的,但是其可以将内存
的数据按照一定的策略保存到硬盘上,从而实现数据持久保存的目的,redis 支持两种不同方式的数据
持久化保存机制,分别是 RDB 和 AOF

RDB 模式:
RDB:基于时间的快照,只保留当前最新的一次快照,特点是执行速度比较快,缺点是可能会丢失从
上次快照到当前快照未完成之间的数据。

RDB 实现的具体过程 Redis 从主进程先 fork 出一个子进程,使用写时复制机制(子进程把内存数据拷贝出来到临时文件,不影响主进程往内存里写入数据)
子进程将内存的数据保存为一个临时文件,比如 dump.rdb.temp,当数据保存完成之后再将上一次保存的 RDB 文件替换掉,然后关闭子进程,这样可以保存每一次做 RDB 快照的时候保存的数据都是完整的,因为直接替换 RDB文件的时候可能会出现突然断电等问题而导致 RDB 文件还没有保存完整就突然关机停止保存而导致数据丢失的情况,可以手动将每次生成的 RDB 文件进程备份,这样可以最大化保存历史数据。

redis持久化_第1张图片

AOF 模式:
AOF:按照操作顺序依次将操作添加到指定的日志文件当中,特点是数据安全性相对较高,缺点是即使
有些操作是重复的也会全部记录。
AOF 和 RDB 一样使用了写时复制机制,AOF 默认为每秒钟 fsync 一次,即将执行的命令保存到 AOF 文
件当中,这样即使 redis 服务器发生故障的话顶多也就丢失 1 秒钟之内的数据,也可以设置不同的 fsync
策略,或者设置每次执行命令的时候执行 fsync,fsync 会在后台执行线程,所以主线程可以继续处理
用户的正常请求而不受到写入 AOF 文件的 IO 影响

appendonly no #是否开启 AOF 日志记录,默认 redis 使用的是 rdb 方式持久化,这种方式在许多应用中已
经足够用了。但是 redis 如果中途宕机,会导致可能有几分钟的数据丢失,根据 save 来策略进行持久化,
Append Only File 是另一种持久化方式,可以提供更好的持久化特性。Redis 会把每次写入的数据在接收后
都写入 appendonly.aof 文件,每次启动时 Redis 都会先把这个文件的数据读入内存里,先忽略 RDB 文件。

appendfilename "appendonly.aof" #AOF 文件名

appendfsync everysec #aof 持久化策略的配置,no 表示不执行 fsync,由操作系统保证数据同步到磁
盘,always 表示每次写入都执行 fsync,以保证数据同步到磁盘,everysec 表示每秒执行一次 fsync,可能会
导致丢失这 1s 数据。

no-appendfsync-on-rewrite no 在 aof rewrite 期间,是否对 aof 新记录的 append 暂缓使用文件同步策
略,主要考虑磁盘 IO 开支和请求阻塞时间。默认为 no,表示"不暂缓",新的 aof 记录仍然会被立即同步,
Linux 的默认 fsync 策略是 30 秒,如果为 yes 可能丢失 30 秒数据,但由于 yes 性能较好而且会避免出
现阻塞因此比较推荐。

auto-aof-rewrite-percentage 100 # 当 Aof log 增长超过指定百分比例时,重写 log file, 设置为 0 表示
不自动重写 Aof 日志,重写是为了使 aof 体积保持最小,而确保保存最完整的数据。
auto-aof-rewrite-min-size 64mb #触发 aof rewrite 的最小文件大小

aof-load-truncated yes #是否加载由于其他原因导致的末尾异常的 AOF 文件(主进程被 kill/断电等)
aof-use-rdb-preamble yes #redis4.0 新增 RDB-AOF 混合持久化格式,在开启了这个功能之后,AOF 重写
产生的文件将同时包含 RDB 格式的内容和 AOF 格式的内容,其中 RDB 格式的内容用于记录已有的数
据,而 AOF 格式的内存则用于记录最近发生了变化的数据,这样 Redis 就可以同时兼有 RDB 持久化和
AOF 持久化的优点(既能够快速地生成重写文件,也能够在出现问题时,快速地载入数据)。