redis持久化

Redis持久化原理：

Redis支持两种持久化：RDB和AOF模式
一、名词解释：
RDB：持久化可以在指定的时间间隔内生成数据集的时间点快照点快照（point-in-time snapshot)。
snapshot，二进制格式：按事先定制的策略，周期性地将数据保存到磁盘：数据文件默认为dump.rdb;
客户端也可显式使用SAVA或BGSAVE命令启动快照保存机制；
SAVE：同步，在主线程中保存快照；此时会阻塞所有客户端请求；

BGSAVE：异步，不会阻塞客户端请求；
AOF：持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。记录每一次写操作至指定的文件尾部实现持久化；当redis重启时，可通过重新执行文件中的命令在内存重建数据库；
BGREWRITEAOF：AOF文件重写；不会读取正在使用的AOF文件，而通过将内存中的数据以命令的方式保存到临时文件中，完成之后替换原来的AOF文件；

AOF文件中的命令全部以redis协议的格式来保存，新命令会被追加到文件的尾部。redis还可以在后台对AOF文件进行重写（rewrite）

使得AOF文件的体积不会超出保存数据集状态所需的实际大小。

RDB和AOF的优先级：
如果同时开启RDB和AOF模式，AOF的优先级要比RDB高；
Redis还可以同时使用RDB和AOF持久化。在这种情况下，当redis重启时，它会优先使用AOF文件来还原数据集。
因为AOF文件保存的数据集通常比RDB文件所保存的数据集更完整。

AOF的方式有点像ORCAL的逻辑备库！
AOF redis还会在后台对数据进行重写，比如set key1，set key2，其实set key1没用，这样做可以把set key1删掉。这样保存下来的数据集就很小了可以压缩了！
你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

二、RDB&AOF优缺点
RDB的优缺点：
优点：
1、紧凑易于备份，他就一个文件。

2、RDB可以最大化redis性能、父进程无需做任何操作只需要for一个子进程即可
3、恢复比AOF快
缺点：
1、数据完整性：如果非常注重数据的完整性，那么RDB就不行，虽然他是一个point-in-tie的快照方式，但是在快照的过程中，redis重启了，那么在快照中的这些数据将会丢失；
2、数据非常庞大后，非常耗CPU和时间，那么redis将可能down掉1秒钟甚至更长。

AOF的优缺点：
优点：
1、使用AOF持久化会让redis变得非常耐久，AOF默认的每一秒追加一次也可以修改他的方式，每执行一次命令追加一次，所以你最多丢失1秒钟的数据。
2、AOF文件是一个只进行追加操作的日志文件（append only log）。
3、redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写。
缺点：
1、对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积。
2、根据所使用的fsync策略，AOF的速度可能会慢于RDB。

Rdis持久化设置：

默认Redis是开启的RDB模式的持久化的看下面配置文件：

########################### SNAPSHOTTING  ########################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

===================================================
上面3个save是或的关系

# save <seconds> <changes>  333格式！
解释：
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed

900 sec内有1个Key发生了改变就做一次快照
或 300 sec内有10个keys发生了改变做一次快照
或 60 sec内有10000 keys发生了改变做一次快照

快照原理：
forker出一个进程，是当前进程的一个副本相当于子进程，不会影响你当前运行的进程！当子进程写的时候会有一个临时
的文件，当子进程写完之后会把这个临时的文件move替换老的文件，所以这个rdb的文件任何时间都是一个完整的可用的
副本！你写的时候不会影响RDB这个文件，因为forker出的子进程正在写的是一个临时文件！
但是如果故障了，你这个保存的时间是你开始快照那一刻那个时间，你快照到快照完毕那一段时间的数据就丢失了。

如果想禁用持久化把这三行删了就行了
save 900 1
save 300 10
save 60 10000
1、快照保存在哪里呢？
# The filename where to dump the DB
dbfilename dump.rdb #如果你启用了多个快照名称，可以使用端口来定义；比如：dump_6379.rdb

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./ #不仅仅是RDB模式下的DB存放在这个目录，AOF模式下也是存放在这个目录的，建议存放在指定的目录。

#比如 dir /data/redis

#比如我上面指定了：
# The filename where to dump the DB
dbfilename dump_6379.rdb
# Note that you must specify a directory here,not a file name.
dir /data/redis/

2、手动在redis中保存

127.0.0.1:6379> SET key 1
OK
127.0.0.1:6379> SAVE
OK
127.0.0.1:6379> quit
# ll /u01/redis/   查看文件目录下面有没有修改
-rw-r--r--. 1 root root 399 Mar 25 15:55 dump.rdb   #当前时间创建
在设置一个key看下：
127.0.0.1:6379> set key 2
OK
127.0.0.1:6379> SAVE
OK
127.0.0.1:6379> quit
# ll /u01/redis/
-rw-r--r--. 1 root root 399 Mar 25 15:59 dump.rdb
127.0.0.1:6379> BGSAVE
Background saving started

SAVE和BGSAVE有什么区别：SAVE是阻塞的当你直接执行SAVE的时候他就不干活了，BGSAVE是在后台执行。
forker一个子进程来进行SAVE。

SAVE的使用场景仅限于：当redis需要迁移的时候，redis没有数据写入并且可以停的时候使用！

测试添加一个：key然后停掉看看！不保存：
目前的key是：
127.0.0.1:6379> KEYS *
1) "key"
2) "hello"
127.0.0.1:6379> SET key3 haha
OK

# kill -9 `pgrep -f redis` 杀掉进程
127.0.0.1:6379> KEYS *  #重启登录之后发现设置的key丢失了
1) "hello"
2) "key"
#所以当redis异常挂掉之后，没有SAVE数据！

3、启动AOF后

给这个文件追加，把所有的命令都写到一个文件里面，你执行一个我写一个。恢复的话在执行一遍不就行了吗！非常简
单(但是恢复相对RDB模式会慢，他相当于重新把AOF库里的记录重新往内存中写一遍)可以RDB和AOF同时使用！优点
都占用了！但是也得根据业务来定！

开启方法：修改配置文件
appendonly yes  #改成yes
appendfilename "appendonly.aof" #文件名

工作原理：
forker 一个子进程写到临时文件，写完之后就给父进程发一个信号，开始写到写完的这个过程还会有子进程给父进程发信
号。先保存在内存里，但是他有个好的功能，重写，他会定时对aof进行更新，这样文件就会非常小！

测试：（他会根据redis可识别的方式写入文件，不过大概人也能看懂）

127.0.0.1:6379> SET sichuan dazhou
OK
127.0.0.1:6379> SET beijing beijing
OK
127.0.0.1:6379> SET magedu peixunjigou
OK
127.0.0.1:6379> SET cengdu sichuan
OK
127.0.0.1:6379> KEYS *
1) "magedu"
2) "beijing"
3) "cengdu"
4) "sichuan"

# cat /u01/redis/appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
SET
$7
sichuan
$6
dazhou
*3
$3
SET
$7
beijing
$7
beijing
*3
$3
SET
$6
magedu
$11
peixunjigou
*3
$3
SET
$6
cengdu
$7
sichuan