【每日一题】Redis 持久化机制
前些天发现了一个巨牛的人工智能学习网站，通俗易懂，风趣幽默，忍不住分享一下给大家。点击跳转到网站。
众所周知，Redis 是一个基于内存的键值存储系统，它使用内存存储数据，以提供快速读写访问。然而，内存存储的数据是容易丢失的，这就意味着如果Redis一旦奔溃或者重启，所有数据都将丢失。为了解决这个问题，Redis引入了持久化机制，它允许Redis将内存中的数据异步或同步地写入磁盘中，以便在Redis重启时能够从磁盘中恢复数据。Redis支持两种持久化机制：RDB和AOF。
RDB
RDB（Redis DataBase） 可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot），以二进制的方式写入磁盘。它是Redis默认的持久化方式。
使用RDB持久化方式会生成一个名为 dump.rdb 的文件，文件名是可以通过配置文件修改的。
# The filename where to dump the DB
dbfilename dump.rdb
RDB持久化分为两种方式：手动触发和自动触发。
手动触发
手动触发是指手动执行 save 、bgsave、flushall 命令
- save ：使 Redis 处于阻塞状态，直到 RDB 持久化完成，才会响应其他客户端发来的命令，所以在生产环境一定要慎用。
- bgsave ：Redis会fork出一个子进程执行持久化生成dump.rdb 文件，主进程只在fork过程中有短暂的阻塞，子进程创建之后，主进程就可以响应客户端请求了。
- flushall ：该命令会删除Redis的所有数据并清空dump.rdb文件，相当于删库，如果没有dump.rdb文件会生成一个空的dump.rdb文件。
自动触发
自动触发包括通过配置文件save参数自动触发的。
- save：配置自动执行RDB持久化的条件，格式为
save，表示save 900 1和save 300 10、save 60 10000，即900秒内有至少1个key被修改或300秒内有至少10个key被修改或10000秒内60至少60个key被修改时执行RDB持久化。save参数配置最终是通过bgsave命令执行的。
优缺点
RDB优点：
-
紧凑：RDB文件采用二进制格式，所以它比AOF文件更紧凑，可以节省磁盘空间和网络带宽。
-
更适合备份和恢复：RDB文件非常适合进行备份和恢复操作，因为它只是一个完整的数据快照，可以很方便地将Redis实例从一个环境迁移到另一个环境中。
-
性能高：相对于AOF，RDB更加高效。因为它只需要在指定的时间间隔内进行一次数据快照，对Redis服务器的性能影响较小。
RDB缺点：
-
容易丢失数据：如果Redis在进行RDB持久化之前崩溃，将会丢失最后一次持久化之后的所有数据。
-
可能无法恢复：RDB文件只包含一个时间点的数据快照，如果Redis在快照之后发生故障，就无法恢复从快照到故障之间的数据。
-
由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。会占用cpu
AOF
AOF（Append-Only File） 是一种将写命令追加到文件中的持久化方式。在AOF持久化模式下，Redis会将所有接收到的写命令追加到文件末尾。当Redis重启时，它会通过重新执行文件中的所有命令来重新构建数据集。AOF文件是一个文本文件，因此可以轻松地查看和修改。AOF类似于MySQL的binlog。该持久化方式也是目前主流的方式。
AOF默认是不开启的，如果要开启可在配置文件中开启并指定文件名
# 开启aof持久化模式
appendonly yes
# aof文件名
appendfilename "appendonly.aof"
AOF持久化也分为手动触发和自动触发：
手动触发
可以使用BGREWRITEAOF命令手动触发持久化机制。
BGREWRITEAOF：Redis在后台异步进行AOF重写操作，即将AOF文件重写为一个新的、更加紧凑的AOF文件，不会阻塞Redis服务器进程。
自动触发
自动触发需要在配置文件中配置参数，一般有配置BGREWRITEAOF命令参数和写入策略两种方式。
BGREWRITEAOF命令参数
BGREWRITEAOF命令也可以通过在配置文件中配置参数从而达到自动触发AOF重写：
通过auto-aof-rewrite-percentage和auto-aof-rewrite-min-size参数配置AOF文件重写触发条件，当AOF文件大小达到auto-aof-rewrite-min-size并且AOF文件增长率超过了auto-aof-rewrite-percentage时，Redis会自动启动AOF重写操作。默认配置为auto-aof-rewrite-percentage 100和auto-aof-rewrite-min-size 64mb，也就是说当AOF文件大小达到原先文件的2倍，并且超过64mb将对AOF文件进行重写。
写入策略
通过在配置文件中配置AOF的写入策略来触发的写入。AOF的写入策略有以下3种：
- always： 每次执行写命令时都立即将命令同步到磁盘，这种方式数据最可靠，但写入性能最差。
- everysec： 每秒钟同步一次，性能和数据可靠性折中。AOF 默认使用的策略
- no： 完全依赖操作系统进行同步，性能最好，但数据可靠性最差
在配置文件中可按如下方式配置：
appendfsync everysec
优缺点
AOF优点：
-
数据更可靠：AOF记录了所有的写命令，因此即使Redis在执行写操作时崩溃，也可以通过 redis-check-aof 工具解决数据一致性问题。
-
更精确的数据恢复：AOF文件比RDB文件更详细和精确，它记录了每一个写操作，包括写操作的时间和参数等信息，这样就可以更加精确地恢复数据。
-
AOF机制的rewrite模式：可以定期对AOF文件进行重写，以达到压缩的目的。
AOF缺点：
-
AOF文件更大：AOF文件比RDB文件更大，因为它需要记录所有的写命令。这不仅占用更多的磁盘空间，也需要更多的网络带宽进行传输。
-
性能稍差：由于AOF文件需要记录所有的写命令，所以它的写入性能相对于RDB要差一些。同时，如果AOF文件过大，重写AOF文件也会占用比较长的时间。
该如何选择？
RDB:存储数据结果，关注点在数据。
AOF:存储操作过程，关注点在数据的操作过程
这两种持久化方式应该选择哪个呢？官方给出的答案是这样的：
翻译过来就是：
如果你想要达到PostgreSQL所能提供的数据安全程度，那么你应该同时使用这两种持久性方法。
如果您非常关心你的数据，但仍然可以忍受灾难发生时几分钟的数据丢失，那么你可以只使用RDB。
有许多用户单独使用AOF，但我们不鼓励这样做，因为不时地使用RDB快照对于进行数据库备份、快速重启以及在AOF引擎中出现错误时是一个很好的主意。
当同时启用RDB和AOF方式时，Redis会优先启用AOF恢复数据，以保证数据的完整性。
Redis 4.0引入了RDB和AOF混合持久化机制，即在使用AOF持久化的同时，定期生成RDB快照备份。这种混合持久化的方式综合了RDB和AOF的优点，既可以保证数据的实时持久化，也可以提供快速的数据恢复和备份。
在RDB和AOF混合持久化模式下，Redis会定期生成RDB快照备份，并将这个过程记录到AOF文件中。这意味着即使在Redis意外崩溃的情况下，也可以使用AOF文件进行数据恢复，同时也可以使用最新的RDB快照进行快速恢复。
Redis 4.0才引入的混合持久化机制，不过现在用Redis 3.0的比较多，具体使用哪种持久化方式可以在应对不同的应用场景时，根据需要进行灵活选择和配置。
总结
最后再将两种持久化机制做一个对比：
| RDB | AOF | |
|---|---|---|
| 性能 | 快 | 慢 |
| 恢复速度 | 快 | 慢 |
| 启动优先级 | 低 | 高 |
| 数据完整性 | 丢数据 | 根据策略决定 |
| 同样数据集文件大小 | 小 | 大 |