redis-持久化

标签：安全   记录   操作系统   破坏   停止   同步   影响   两种   filename   

redis-持久化

? redis是一个内存数据库，数据是保存在内存中的，内存中的数据变化是很快的，比如服务器出现宕机或者重启，redis应用挂了，那么数据就丢失了，这个是很严重的问题。redis提供了两种持有化的方式来解决这个问题，RDB(Redis DateBase)和AOF(Append Only File)。

RDB持久化

? RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储在硬盘中，Redis对数据进行快照的方式可分为自动快照和手动快照两部分。

自动快照

自动快照是用户在redis.conf文件中配置save m n 定时触发的，这个配置的条件是可以同时存在多个的，比如在配置文件中默认定义了3个save配置

save 900 1
save 300 10
save 60 10000

比如 save 900 1 表示的是15分钟有一个或者一个以上的键被修改则生成快照，同理save 300 10 表示5分钟内有10个或者10以上的键被修改则生成快照。

手动快照

顾名思义手动快照就是通过手动输入命令来进行快照生成，主要通过save和bgsave来手动让Redis进行数据集保存操作。

save

当执行save命令时，redis同步的进行快照操作，在快照执行的过程中会阻塞所有来自客户端的请求。如果数据库中数据比较多的时候，最好不要使用save命令来执行，因为时同步操作，会影响用户体验

bgsave

bgsave命令可以在后台异步地进行快照操作，快照的同时服务器还可以继续响应客户端的请求。执行完bgsave命令，redis会立即返回ok表示执行快照开始，同时可以通过lastsave命令来查询快照是否完成，返回的是时间戳。如果需要手动执行快照操作，推荐使用bgsave命令来执行。

快照原理

Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作:

• Redis 调用forks. 同时拥有父进程和子进程。
• 子进程将数据集写入到一个临时 RDB 文件中。
• 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

RDB配置

#只要满足以下的条件就会进行自动生成快照
#15分钟有一个或者一个以上的键被修改，则执行
save 900 1 
save 300 10
save 60 10000

#禁用RDB
save ""

#当备份进程出错时，主进程是否停止写操作
stop-writes-on-bgsave-error yes

#是否压缩rdb文件 推荐no 相对于硬盘成本cpu资源更贵
rdbcompression no

AOF持久化

AOF(Append-Only-File)持久化的记录redis执行的每一条命令，通过append将执行的命令追加保存到AOF文件中。

AOF配置

# 默认关闭AOF，若要开启将no改为yes
appendonly no

# append文件的名字
appendfilename "appendonly.aof"

# 每隔一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec

# 当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。
auto-aof-rewrite-percentage 100

# 当AOF文件大小大于该配置项时自动开启重写
auto-aof-rewrite-min-size 64mb

AOF持久化原理

• 将指令写到AOF缓冲区
• 从AOF缓冲区append到AOF文件
• 从AOF文件保存到磁盘中

AOF写入缓冲区的方式

AOF写入缓冲区的方式有三种，通过appendfsync配置来修改，默认时everysec,每个一秒同步一次

always：每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全

everysec：每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒钟的数据

no:将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

AOF工作原理

• Redis 执行 fork() ，现在同时拥有父进程和子进程。
• 子进程开始将新 AOF 文件的内容写入到临时文件。
• 对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾,这样样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
• 当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
• 搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。

AOF文件恢复

服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会被破坏。

• 为现有的 AOF 文件创建一个备份。

• 使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复:

  $ redis-check-aof –fix

• （可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。

• 重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

RDB和AOF优缺点

RDB优缺点

• 优点：与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些
• 缺点：服务器宕机，会丢失上一次RDB快照之后的持久化数据

AOF优缺点：

• 优点：与RDB相比较，AOF通过append来追加文件，速度要比RDB快，同时对服务器性能消耗小，如果发生服务器宕机，丢失的数据也只是一秒的数据
• 缺点：AOF的文件体积要大于RDB文件的体积，redis重启的恢复速度要比RDB慢

混合持久化

对于两种持有的化方式来说，从两者的优缺点来看，存在一定的互补性，一般推荐两种持久化的方式同时使用，使用两种同时持久化的方式只要修改redis.conf文件中的配置即可

aof-use-rdb-preamble yes

持久化方案的建议

如果Redis只是用来做缓存服务器，比如数据库查询数据后缓存，那可以不用考虑持久化，因为缓存服务失效还能再从数据库获取恢复。

如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失，那么可以仅使用RDB。

通常的设计思路是利用主从复制机制来弥补持久化时性能上的影响。即Master上RDB、AOF都不做，保证Master的读写性能，而Slave上则同时开启RDB和AOF（或4.0以上版本的混合持久化方式）来进行持久化，保证数据的安全性。

参考：

redis-持久化

标签：安全   记录   操作系统   破坏   停止   同步   影响   两种   filename   

原文地址：https://www.cnblogs.com/JackQiang/p/13384616.html