redis持久化机制【十三】

一、Redis提供了哪些持久化机制：

　　redis的高性能是因为其所有数据都存在了内存中，为了使redis在重启之后数据仍然不丢失，需要将数据同步到硬盘中，这一过程就是持久化。

　　redis支持两种方式的持久化，一种是RDB，另一种是AOF。可以单独使用其中一种或者结合使用。

1). RDB持久化：(Redis asynchronously dumps the dataset )
　　该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。
2). AOF持久化:( Append Only File)
　　该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。
3). 无持久化：
　　我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的memcached了。
4). 同时应用AOF和RDB。

　　优先装载AOF(数据更全，有更好的持久化保证吗，RDB有可能丢失一部分数据)

二、RDB机制的优势和劣势：

RDB存在哪些优势呢？
1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。
4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB又存在哪些劣势呢？
1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

三、AOF机制的优势和劣势：

AOF的优势有哪些呢？
1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。
2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF的劣势有哪些呢？
1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。
2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

四、其它：

1. Snapshotting:
缺省情况下，Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

2. Dump快照的机制：
1). Redis先fork子进程。
2). 子进程将快照数据写入到临时RDB文件中。
3). 当子进程完成数据写入操作后，再用临时文件替换老的文件。

3. AOF文件：
上面已经多次讲过，RDB的快照定时dump机制无法保证很好的数据持久性。如果我们的应用确实非常关注此点，我们可以考虑使用Redis中的AOF机制。对于Redis服务器而言，其缺省的机制是RDB，如果需要使用AOF，则需要修改配置文件中的以下条目：
将appendonly no改为appendonly yes
从现在起，Redis在每一次接收到数据修改的命令之后，都会将其追加到AOF文件中。在Redis下一次重新启动时，需要加载AOF文件中的信息来构建最新的数据到内存中。

4. AOF的配置：
在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。

5. 如何修复坏损的AOF文件：
1). 将现有已经坏损的AOF文件额外拷贝出来一份。
2). 执行"redis-check-aof --fix <filename>"命令来修复坏损的AOF文件。
3). 用修复后的AOF文件重新启动Redis服务器。

6. Redis的数据备份：

(也可以调用save或者gbsave将数据保存到.rdb文件中参考:http://www.runoob.com/redis/redis-backup.html)
　　在Redis中我们可以通过copy的方式在线备份正在运行的Redis数据文件。这是因为RDB文件一旦被生成之后就不会再被修改。Redis每次都是将最新的数据dump到一个临时文件中，之后在利用rename函数原子性的将临时文件改名为原有的数据文件名。因此我们可以说，在任意时刻copy数据文件都是安全的和一致的。鉴于此，我们就可以通过创建cron job的方式定时备份Redis的数据文件，并将备份文件copy到安全的磁盘介质中。

---------------------持久化过程实施----------------------

0.编辑redis.conf 将redis的启动设置为后台启动(守护进程)

root@qiaozhi:/usr/local/redis# vim redis.conf

测试:开启redis服务并测试进程是否有redis(设置为守护进程后在开启之后写其他命令不会影响守护进程)

root@qiaozhi:/usr/local/redis# ./bin/redis-server redis.conf

3601:C 07 Nov 06:41:19.801 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

3601:C 07 Nov 06:41:19.802 # Redis version=4.0.2, bits=32, commit=00000000, modified=0, pid=3601, just started

3601:C 07 Nov 06:41:19.802 # Configuration loaded

root@qiaozhi:/usr/local/redis# ps -ef|grep redis

root      3600  2854  0 06:41 pts/1    00:00:00 ./bin/redis-cli

root      3602     1  0 06:41 ?        00:00:00 ./bin/redis-server 127.0.0.1:6379

root      3609  3518  0 06:41 pts/0    00:00:00 grep --color=auto redis

root@qiaozhi:/usr/local/redis#

杀掉进程重新开启进程测试:

root@qiaozhi:/home/qiaozhi# ps -ef|grep redis

root      3602     1  0 06:41 ?        00:00:01 ./bin/redis-server 127.0.0.1:6379

root      3639  2854  0 06:47 pts/1    00:00:00 ./bin/redis-cli

root      3677  3660  0 06:51 pts/0    00:00:00 grep --color=auto redis

root@qiaozhi:/home/qiaozhi# kill -9 3602

root@qiaozhi:/home/qiaozhi# ps -ef|grep redis

root      3639  2854  0 06:47 pts/1    00:00:00 ./bin/redis-cli

root      3680  3660  0 06:51 pts/0    00:00:00 grep --color=auto redis

root@qiaozhi:/home/qiaozhi# cd /usr/local/redis

root@qiaozhi:/usr/local/redis# ./bin/redis-server redis.conf

3683:C 07 Nov 06:52:03.260 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

3683:C 07 Nov 06:52:03.261 # Redis version=4.0.2, bits=32, commit=00000000, modified=0, pid=3683, just started

3683:C 07 Nov 06:52:03.261 # Configuration loaded

root@qiaozhi:/usr/local/redis#

1.RDB持久化测试　

(1)修改配置文件RDB持久化频率

默认配置:

解释:将60 10000改为60 100

指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合

    save <seconds> <changes>

    Redis默认配置文件中提供了三个条件：

    save 900 1

    save 300 10

    save 60 100

    分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有100个更改。

(2)修改rdb文件的生成目录:

默认配置:

将rdb文件的生成目录改为/var/redis目录下(var目录用于存放系统经常变化的文件)

(3)重启redis服务进行测试:

重启：（由于缺少/var/redis目录而报错）

root@qiaozhi:/usr/local/redis# ./bin/redis-server redis.conf 

*** FATAL CONFIG FILE ERROR ***

Reading the configuration file, at line 253

>>> 'dbfilename /var/redis/dump.rdb'

dbfilename can't be a path, just a filename

删除redis目录下的dump.rdb并且创建/var/redis/目录后重启

root@qiaozhi:/usr/local/redis# ls

bin  dump.rdb  redis.conf

root@qiaozhi:/usr/local/redis# rm dump.rdb

root@qiaozhi:/usr/local/redis# ls

bin  redis.conf

root@qiaozhi:/usr/local/redis# mkdir /var/redis

root@qiaozhi:/usr/local/redis# ./bin/redis-server redis.conf

3839:C 07 Nov 07:18:40.944 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

3839:C 07 Nov 07:18:40.945 # Redis version=4.0.2, bits=32, commit=00000000, modified=0, pid=3839, just started

3839:C 07 Nov 07:18:40.945 # Configuration loaded

(4)客户端测试是否有key

127.0.0.1:6379> keys *

(empty list or set)

(5)测试RDB持久化

redis性能检测工具执行2000次命令

root@qiaozhi:/usr/local/redis# ./bin/redis-benchmark -n 2000

　　2.客户端测试是否有key

127.0.0.1:6379> keys *

1) "mylist"

2) "myset:__rand_int__"

3) "counter:__rand_int__"

4) "key:__rand_int__"

　　3.关闭服务器重启

root@qiaozhi:/usr/local/redis# kill -

root@qiaozhi:/usr/local/redis# ./bin/redis-server redis.conf

:C  Nov ::02.418 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

:C  Nov ::02.418 # Redis version=4.0., bits=, commit=, modified=, pid=, just started

:C  Nov ::02.419 # Configuration loaded

　　4.客户端查看是否有数据(服务器重启之后仍然有数据证明被持久化)

127.0.0.1:6379> keys *

1) "mylist"

2) "key:__rand_int__"

3) "counter:__rand_int__"

4) "myset:__rand_int__"

2.AOF持久化测试

首先清空数据库:

127.0.0.1:6379> flushall

OK

127.0.0.1:6379> keys *

(empty list or set)

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always #每次有数据修改发生时都会写入AOF文件。

appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no #从不同步。高效但是数据不会被持久化。

　(1)开启AOF持久化

默认配置:

修改配置开启AOF

(2)修改同步方式(默认就是每秒记一次)

(3) 重写机制:(也就是将aof文件重新整理一下)

　　达到64M之后每增长百分之百重写一次

(4)测试AOF持久化操作

　　重启redis服务并查看/var/redis目录(aof文件的生成位置与上面RDB持久化的文件生成位置一个目录)

root@qiaozhi:/usr/local/redis# ps -ef | grep redis

root      3639  2854  0 06:47 pts/1    00:00:00 ./bin/redis-cli

root      4089     1  0 07:57 ?        00:00:00 ./bin/redis-server 127.0.0.1:6379

root      4137  3763  0 08:01 pts/0    00:00:00 grep --color=auto redis

root@qiaozhi:/usr/local/redis# kill -9 4089

root@qiaozhi:/usr/local/redis# ./bin/redis-server redis.conf

4139:C 07 Nov 08:02:16.404 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

4139:C 07 Nov 08:02:16.404 # Redis version=4.0.2, bits=32, commit=00000000, modified=0, pid=4139, just started

4139:C 07 Nov 08:02:16.404 # Configuration loaded

root@qiaozhi:/usr/local/redis# ls /var/redis/

appendonly.aof  dump.rdb

　　　　此时:appendonly.aof文件是空的。

　　2.客户端执行两次redis操作:

127.0.0.1:> set a test

OK

127.0.0.1:> lpush lkey1 aaa bbb ccc

(integer)

　　3.服务器端重新查看appendonly.aof文件

root@qiaozhi:/usr/local/redis# less /var/redis/appendonly.aof

*2

$6

SELECT

$1

0

*3

$3

set

$1

a

$4

test

*5

$5

lpush

$5

lkey1

$3

aaa

$3

bbb

$3

ccc

　　解释: *2 *3 * 5分别代表这条命令占据的行数

*2: select 0 使用默认的redis数据库

*3: set a test

*5 lpush lkey1 aaa bbb ccc

也就是redis会根据上面的aof文件重新执行脚本进行数据的恢复。

　　(4)服务器端重新启动redis服务

root@qiaozhi:/usr/local/redis# ps -ef | grep redis

root      3639  2854  0 06:47 pts/1    00:00:00 ./bin/redis-cli

root      4140     1  0 08:02 ?        00:00:01 ./bin/redis-server 127.0.0.1:6379

root      4195  3763  0 08:10 pts/0    00:00:00 grep --color=auto redis

root@qiaozhi:/usr/local/redis# kill -9 4140

root@qiaozhi:/usr/local/redis# ./bin/redis-server redis.conf

4197:C 07 Nov 08:10:35.648 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

4197:C 07 Nov 08:10:35.649 # Redis version=4.0.2, bits=32, commit=00000000, modified=0, pid=4197, just started

4197:C 07 Nov 08:10:35.649 # Configuration loaded

　　(5)客户端进行查看数据(数据仍然存在说明进行了数据的持久化操作)

not connected> keys *

1) "lkey1"

2) "a"

(5)测试AOF文件的重写(对AOF文件进行压缩，对数据进行处理)

　　客户端多次操作redis

127.0.0.1:6379> set int 1

OK

127.0.0.1:6379> incrby int 1

(integer) 2

127.0.0.1:6379> incrby int 1

(integer) 3

127.0.0.1:6379> incrby int 1

(integer) 4

127.0.0.1:6379> incrby int 1

(integer) 5

127.0.0.1:6379> incrby int 1

(integer) 6

127.0.0.1:6379> incrby int 1

(integer) 7

127.0.0.1:6379> incrby int 1

(integer) 8

127.0.0.1:6379> incrby int 1

(integer) 9

127.0.0.1:6379> incrby int 1

(integer) 10

127.0.0.1:6379> incrby int 1

(integer) 11

127.0.0.1:6379> incrby int 1

(integer) 12

127.0.0.1:6379> incrby int 1

(integer) 13

127.0.0.1:6379> incrby int 1

(integer) 14

127.0.0.1:6379> incrby int 1

(integer) 15

127.0.0.1:6379> incrby int 1

(integer) 16

127.0.0.1:6379> incrby int 1

(integer) 17

127.0.0.1:6379> incrby int 1

(integer) 18

127.0.0.1:6379> incrby int 1

(integer) 19

127.0.0.1:6379> incrby int 1

(integer) 20

127.0.0.1:6379> incrby int 1

(integer) 21

127.0.0.1:6379> incrby int 1

(integer) 22

127.0.0.1:6379> incrby int 1

(integer) 23

127.0.0.1:6379> incrby int 1

(integer) 24

127.0.0.1:6379> incrby int 1

(integer) 25

127.0.0.1:6379> incrby int 1

(integer) 26

127.0.0.1:6379> get a

"test"

127.0.0.1:6379> get int

"26"

　服务器端查看appendonly.aof内容:

root@qiaozhi:/usr/local/redis# more /var/redis/appendonly.aof

*2

$6

SELECT

$1

0

*3

$3

set

$1

a

$4

test

*5

$5

lpush

$5

lkey1

$3

aaa

$3

bbb

$3

ccc

*2

$6

SELECT

$1

0

*3

$3

set

$3

int

$1

1

*3

$6

incrby

$3

int

$1

1

*3

$6

incrby

$3

int

$1

1

*3

$6

incrby

$3

int

$1

1

*3

$6

incrby

$3

int

$1

1

*3

$6

incrby

$3

int

$1

.............

　　服务器端查看appendonly.aof大小:

（2）客户端重写AOF文件:(整理AOF文件，只保留AOF的结果，多次increby 变为结果)

127.0.0.1:6379> bgrewriteaof

Background append only file rewriting started

127.0.0.1:6379>

(3)服务端重新查看AOF文件大小与内容

大小:

内容:(操作已经进行合并)

root@qiaozhi:/usr/local/redis# more /var/redis/appendonly.aof

*2

$6

SELECT

$1

0

*3

$3

SET

$3

int

$2

37

*5

$5

RPUSH

$5

lkey1

$3

ccc

$3

bbb

$3

aaa

*3

$3

SET

$1

a

$4

test

　　注意:

　　　　如果需要将redis数据库从一台服务器复制到另一台服务器，可以将aof文件和rdb文件进行拷贝，复制到另一台机器的redis工作目录下面，默认优先加载aof文件。