Redis 持久化

默认情况下，redis 工作时所有数据都是存储于内存中的，不论是否有磁盘上的持久化数据，都是工作于内存当中，redis 本身就是一个内存的数据库，如果 redis 崩溃或断电导致所有数据丢失，所以 redis 提供了持久化功能来保证数据的可靠性， redis 持久化有两种实现：RDB 和 AOF

1、RDB 持久化

RDB 持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是 fork 一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

RDB 持久化是默认启动的持久化机制；按事先定制的策略，周期性地将数据保存至磁盘，数据文件默认为 dump.rdb。

RDB 持久化有两种方式：

• 借助于配置文件所定义的 save 和策略进行保存。
• 客户端使用 SAVE 或 BGSAVE 命令启动快照保存机制。

SAVE 命令: 同步保存，在客户端使用 save 保存快照时，是在 redis 主线程中保存快照；因为 redis 的主线程是用于处理请求的，所以此时会阻塞所有客户端请求，每次的保存快照都是把内存中的数据完整的保存一份，并非是增量的，如果内存中的数据比较大，而还有大量的写操作请求时，此方式会引起大量的 I/O，会导致 redis性能下降。

BGSAVE 命令：异步方式，将立即返回结果，但自动在后台保持操作，所以 BGSAVE命令启动以后，前台不会被占用，客户端的请求是不会被阻塞（主进程不会被阻塞）。如果是在配置文件中定义的 save，那么 redis 在持久化的时候，则会开启另外的进程去处理，不会阻塞 redis 的主进程redis 的 RDB 持久化不足之处则是，一旦数据出现问题，由于 RDB 的数据不是最新的，所以基于 RDB 恢复过来的数据一定会有一部分数据丢失，也就是 RDB 保存之后的修改的数据会丢失。

---

a. RDB 优点

① 采用 RDB 方式，那么你的整个 Redis 数据库将只包含一个文件，这对于文件备份而言是非常方便的，因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。

② 性能最大化。对于 Redis 的服务进程而言，在开始持久化时，它唯一需要做的只是 fork 出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行 IO 操作了。

③ 相比于 AOF 机制，如果数据集很大，RDB 的启动效率会更高。

b. RDB 缺点

① 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么 RDB 将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

② 由于 RDB 是通过 fork 子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是 1 秒钟。

c. 配置RDB相关参数

# 创建 RDB 文件路径
mkdir -p /usr/local/redis/data 
vim /usr/local/redis/etc/redis.conf
#-----------------配置文件--------------------------------------------------------
# 在进行快照备份时，一旦发生错误的话是否停止写操作
stop-writes-on-bgsave-error yes 
# RDB 文件是否使用压缩，压缩会消耗 CPU 
rdbcompression yes 

#是否对 RDB 文件做校验码检测，此项定义在 redis 启动时加载 RDB 文件是否对文件检查校验码，
#在 redis 生成 RDB 文件是会生成校验信息，在 redis 再次启动或装载 RDB 文件时，
#是否检测校验信息，如果检测的情况下会消耗时间，会导致 redis 启动时慢，
#但是能够判断 RDB 文件是否产生错误
rdbchecksum yes 

# 定义 RDB 文件的名称
dbfilename dump.rdb 
# 定义 RDB 文件存放的目录路径
dir /usr/local/redis/data 
#-----------------配置文件--------------------------------------------------------

#关闭 redis，这里注意，设置完密码后关闭 redis 需要携带密码
redis-cli -a 123456 shutdown 
redis-server /usr/local/redis/etc/redis.conf 
redis-cli -a 123456 
127.0.0.1:6379> config get dir

2、AOF 持久化

AOF：Append Only File，持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。AOF 类似于 MySQL 的二进制日志，记录每一次 redis 的写操作命令，以顺序 IO 方式附加在指定文件的尾部，是使用追加方式实现的，这也叫做一种附加日志类型的持久化机制，由于每一次的操作都记录，则会随着时间增长而增大文件的容量， AOF 不像 RDB，RDB 是保存数据集的本身。

a. AOF 优点

① AOF 机制可以带来更高的数据安全性，即数据持久性。Redis 中提供了 3 中同步策略，即每秒同步、每修改同步和不同步。事实上，对于每秒同步，一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，即每次发生的数据变化都会被立即记录到磁盘中。至于无同步，无需多言，我想大家都能正确的理解它。

② 由于 AOF 机制对日志文件的写入操作采用的是 append 模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在 Redis 下一次启动之前，我们可以通过 redis-check-aof 工具来帮助我们解决数据一致性的问题。

③ 如果日志过大，Redis 可以自动启用 rewrite 机制。即 Redis 以 append 模式不断的将修改数据写入到老的磁盘文件中，同时 Redis 还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行 rewrite 切换时可以更好的保证数据安全性。

④ AOF 包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

b. AOF 缺点

① 对于相同数量的数据集而言，AOF 文件通常要大于 RDB 文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

② 根据同步策略的不同，AOF 在运行效率上往往会慢于 RDB。

c. 配置AOF相关参数

vim /usr/local/redis/etc/redis.conf
#--------------------------------配置文件Start-----------------------------------------
# 定义是否开启 AOF 功能，默认为关闭，启用修改为 yes
appendonly no

# 定义 AOF 文件
appendfilename "appendonly.aof" 

# 表示每次收到写命令时，立即写到磁盘上的 AOF 文件，
# 虽然是最好的持久化功能，但是每次有写命令时都会有磁盘的 I/O 操作，容易影响redis 的性能
appendfsync always 

# 表示每秒钟写一次，不管每秒钟收到多少个写请求都往磁盘中的 AOF 文件中写一次
appendfsync everysec

# 表示 append 功能不会触发写操作，所有的写操作都是提交给 OS，由 OS 自行决定是如何写的
appendfsync no 

# 当此项为 yes 时，表示在重写时，对于新的写操作不做同步，而暂存在内存中
no-appendfsync-on-rewrite no

# 表示当前 AOF文件的大小是上次重写 AOF文件的二倍时，则自动日志重写过程
auto-aof-rewrite-percentage 100

# 定义 AOF 文件重写过程的条件，最少为定义大小则触发重写过程
auto-aof-rewrite-min-size 64mb 
#--------------------------------配置文件End-----------------------------------------

注意：持久本身不能取代备份；还应该制定备份策略，对 redis 数据库定期进行备份；

d. RDB 与 AOF 同时启用注意事项

① BGSAVE 和 BGREWRITEAOF 不会同时执行，为了避免对磁盘的 I/O 影响过大， 在某一时刻只允许一者执行； 如果 BGSAVE 在执行当中，而用户手动执行 BGREWRITEAOF 时，redis 会立即返回 OK，但是 redis 不会同时执行，会等 BGSAVE 执行完成，再执行 BGREWRITEAOF。

② 在 Redis 服务器启动用于恢复数据时，会优先使用 AOF

③ 数据恢复：每次 redis 重启都会去读取相对应的文件，如果误删除可以用备份文件直接替换 原来的文件，dump.rdb 或者 appendonly.aof。