redis系列(二)-redis持久化

1.Redis持久化两种方式：

• RDB：在指定的时间间隔能对你的数据进行快照存储。
• AOF：记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据。

2.redis配置文件

进入redis/bin，打开redis.conf文件，找到如下配置行：

2.1RDB的持久化配置

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#   save ""

# 时间策略
save 900 1
save 300 10
save 60 10000

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

# The filename where to dump the DB RDB文件名，默认为dump.rdb。
dbfilename dump.rdb

# The working directory.文件存放的目录，AOF文件同样存放在此目录下。默认为当前工作目录。
dir ./

配置其实非常简单，这里说一下持久化的时间策略具体是什么意思。

save 900 1 表示900s内如果有1条是写入命令，就触发产生一次快照，可以理解为就进行一次备份
save 300 10 表示300s内有10条写入，就产生快照

stop-writes-on-bgsave-error yes 这个配置也是非常重要的一项配置，这是当备份进程出错时，主进程就停止接受新的写入操作，是为了保护持久化的数据一致性问题。如果自己的业务有完善的监控系统，可以禁止此项配置， 否则请开启。

当然如果你想要禁用RDB配置，也是非常容易的，只需要在save的最后一行写上：save “”

2.1.1优点

RDB文件是一个很简洁的单文件，它保存了某个时间点的Redis数据，很适合用于做备份。你可以设定一个时间点对RDB文件进行归档，这样就能在需要的时候很轻易的把数据恢复到不同的版本。
基于上面所描述的特性，RDB很适合用于灾备。单文件很方便就能传输到远程的服务器上。
RDB的性能很好，需要进行持久化时，主进程会fork一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作。
比起AOF，在数据量比较大的情况下，RDB的启动速度更快。

2.1.2缺点

RDB容易造成数据的丢失。假设每5分钟保存一次快照，如果Redis因为某些原因不能正常工作，那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。
RDB使用fork()产生子进程进行数据的持久化，如果数据比较大的话可能就会花费点时间，造成Redis停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候，停止服务的时间甚至会到1秒。

2.2AOF的持久化配置

快照并不是很可靠。如果你的电脑突然宕机了，或者电源断了，又或者不小心杀掉了进程，那么最新的数据就会丢失。而AOF文件则提供了一种更为可靠的持久化方式。每当Redis接受到会修改数据集的命令时，就会把命令追加到AOF文件里，当你重启Redis时，AOF里的命令会被重新执行一次，重建数据。

# 是否开启aof
appendonly yes

# 文件名称
appendfilename "appendonly.aof"

# 同步方式
appendfsync everysec

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof时如果有错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

AOF持久化策略(默认每秒)：

appendfsync always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好)

appendfsync everysec (异步操作，每秒记录，如果一秒钟内宕机，有数据丢失)

appendfsync no （将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的）

2.2.1 优点

比RDB可靠。你可以制定不同的fsync策略：不进行fsync、每秒fsync一次和每次查询进行fsync。默认是每秒fsync一次。这意味着你最多丢失一秒钟的数据。
AOF日志文件是一个纯追加的文件。就算是遇到突然停电的情况，也不会出现日志的定位或者损坏问题。甚至如果因为某些原因（例如磁盘满了）命令只写了一半到日志文件里，我们也可以用redis-check-aof这个工具很简单的进行修复。
当AOF文件太大时，Redis会自动在后台进行重写。重写很安全，因为重写是在一个新的文件上进行，同时Redis会继续往旧的文件追加数据。新文件上会写入能重建当前数据集的最小操作命令的集合。当新文件重写完，Redis会把新旧文件进行切换，然后开始把数据写到新文件上。
AOF把操作命令以简单易懂的格式一条接一条的保存在文件里，很容易导出来用于恢复数据。例如我们不小心用FLUSHALL命令把所有数据刷掉了，只要文件没有被重写，我们可以把服务停掉，把最后那条命令删掉，然后重启服务，这样就能把被刷掉的数据恢复回来。

2.2.2缺点

在相同的数据集下，AOF文件的大小一般会比RDB文件大。
在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，而在禁止fsync的情况下速度可以达到RDB的水平。
在过去曾经发现一些很罕见的BUG导致使用AOF重建的数据跟原数据不一致的问题

2.3 RDB与AOF的选择：

做备份：当数据量大，且对恢复速度有要求，并且数据的一致性要求不高的话，可以只使用RDB

只做缓存：不用开启任何的持久化方式

两者都开启的建议：RDB数据不实时，同时使用两者时服务器只会找AOF文件，可不可以只使用AOF?建议不要，因为RDB更适合备份数据库(AOF在不断变化，不好备份)，快速重启，而且不会又AOF可能潜在的BUG,留作万一的手段。

3.备份

建议的备份方法：
创建一个定时任务，每小时和每天创建一个快照，保存在不同的文件夹里。
定时任务运行时，把太旧的文件进行删除。例如只保留48小时的按小时创建的快照和一到两个月的按天创建的快照。
每天确保一次把快照文件传输到数据中心外的地方进行保存，至少不能保存在Redis服务所在的服务器。

项目中有时候会出现项目上线了，发现数据有错误，把缓存数据污染了，此时可以选择备份数据，比如项目上线前某个时间的备份数据进行数据恢复。