redis之持久化

什么是 redis 持久化？持久化方式和优缺点

redis 持久化就是把内存中的数据写到磁盘里，防止服务器宕机后内存数据丢失。
redis提供了两种持久化方式：RDB（默认）和 AOF

RDB 配置方式

# 基本语法：save [seconds] [changes]
# 在 seconds 秒内发生了 changes 次数的数据修改，就进行一次快照保存
# 快照保存策略可以叠加，例如：
#     save 60 100
#     save 10 50
# 表示：
#     60秒内产生了100次修改或者10秒内产生了50次修改，就快照保存一次

• RDB 的优点：

1. 对性能影响小。redis会fork出来一个子进程进行快照保存，几乎不影响redis处理客户端请求。
2. 使用RDB文件进行数据恢复比使用AOF文件要快很多。

• RDB 的缺点：

1. 快照是定时生成的，必然会损失一些数据
2. 集群非常大且CPU不够强时，fork子进程耗时比较长的话，影响这个时间段内对外提供服务

AOF 配置方式

AOF 的持久化方式，会把每一个写操作都记录到一个日志文件里，重启时，会按照顺序执行所有的写操作，保证数据恢复到最新。
AOF 默认是关闭的

# 开启 AOF 持久化
# appendonly yes
# 配置 appendonly 的 fsync 方式
# appendfsync no 表示：不进行 fsycn，将 flush 文件的时机交给操作系统，速度最快
# appendfsync always 表示：每有一次写操作都进行一次 fsycn 操作，数据安全性最高，但速度最慢
# appendfsync everysec 表示：交给后台进程每秒 fsync 一次，属于折中方案

AOF rewrite

不断的记录写操作的 AOF 日志，会造成 AOF 文件过大，进而使用 AOF 文件进行数据恢复时，耗时过长。使用 AOF rewrite 可以让 AOF 只保留使得数据恢复到最新的最小写操作集。

# 在每次 appendfsync 时，如果 appendfsync 后的文件大小基于 appendfsync 前的文件大小增长够 100%，就进行一次 AOF rewrite。
auto-aof-rewrite-percentage 100
# 如果 appendfsync 后的文件大小基于 appendfsync 前的文件大小没有增长够 10mb，就不进行 AOF rewrite
auto-aof-rewrite-min-size 10mb

AOF 优点

1. 最安全。使用 appendfsync always，原则上任务写操作都不会丢失。
2. AOF 文件断电也不会损坏，可以使用 redis-check-aof 进行修复。
3. AOF 文件易读、可修改。只要 AOF 没有 rewrite 可以手动删除错误的写操作，然后恢复数据。

AOF 缺点

1. AOF 文件比 RDB 文件大
2. AOF 持久化比 RDB 持久化对性能损耗大
3. AOF 恢复数据比 RDB 恢复数据慢