Redis>redis的持久化

由于redis是一个内存数据库，所有的数据都是保存在内存当中的，内存当中的数据极易丢失，所以redis的数据持久化就显得尤为重要，在redis当中，提供了两种数据持久化的方式，分别为RDB以及AOF，且redis默认开启的数据持久化方式为RDB方式，接下来我们就分别来看下两种方式的配置吧

1、RDB持久化方案介绍之RDB方案介绍

1.1 RDB方案介绍

Redis会定期保存数据快照至一个rbd文件中，并在启动时自动加载rdb文件，恢复之前保存的数据。可以在配置文件中配置Redis进行快照保存的时机：

save [seconds] [changes]

意为在[seconds]秒内如果发生了[changes]次数据修改，则进行一次RDB快照保存，例如

save 60 100

会让Redis每60秒检查一次数据变更情况，如果发生了100次或以上的数据变更，则进行RDB快照保存。可以配置多条save指令，让Redis执行多级的快照保存策略。Redis默认开启RDB快照。

redis.conf文件中默认设置

手动触发保存快照：

SAVE或者BGSAVE命令手动触发RDB快照保存。SAVE 和 BGSAVE 两个命令都会调用 rdbSave 函数，但它们调用的方式各有不同：

• SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
• BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求。

1.2 RDB方案优点

• 1、对性能影响最小。如前文所述，Redis在保存RDB快照时会fork出子进程进行，几乎不影响Redis处理客户端请求的效率。

• 2、每次快照会生成一个完整的数据快照文件，所以可以辅以其他手段保存多个时间点的快照（例如把每天0点的快照备份至其他存储媒介中），作为非常可靠的灾难恢复手段。

• 3、使用RDB文件进行数据恢复比使用AOF要快很多

1.3 RDB方案缺点

• 1、快照是定期生成的，所以在Redis crash时或多或少会丢失一部分数据。

• 2、如果数据集非常大且CPU不够强（比如单核CPU），Redis在fork子进程时可能会消耗相对较长的时间，影响Redis对外提供服务的能力。

1.4 RDB方案配置

修改redis的配置文件

cd /export/servers/redis-3.2.8/

vim redis.conf
save 900 1
save 300 10
save 60 10000
save 5 1

添加一个redis的值后，把当前redis的服务进程关掉
ps -ef | grep redis

杀死进程：kill -9 62342
重新启动redis服务

src/redis-server redis.conf  

src/redis-cli  -h node01

会发现之前添加的数据依然存在!!!

RDB小结：

redis持久化指将redis内存中的数据写入磁盘，进行有永久性存储，防止数据丢失。

方式1、RDB：
		自动触发方式：在redis.conf配置文件中添加“  save  N  M”,N表示触发的时间,M表示对redis进行操作的次数，当两个同时达到以后，才会触发数据持久化。 
		
人为触发方式：  save     bgsave
			Save:在进行对数据进行持久化时，会将数据的读写请求阻塞，这是读写操作无法完成
			Bgsave: 在进行对数据进行持久化时，不会将数据的读写请求阻塞，这是读写操作正常执行
			
配置RDB自动持久化流程
1、配置redis.conf配置文件，添加 save  N  M 
2、重启redis服务，添加新数据至少M条，N秒过后，重启redis服务
3、重启后查看上次关机时的数据是否存在

优点：对性能的影响小，是可到的备份数据的手段。
缺点：确定可能造成部分数据丢失，N  M  不好配置。

注意:每次生成新的dump.rdb都会覆盖掉之前的老的快照

2、AOF持久化方案

2.1 AOF方案介绍：

采用AOF持久方式时，Redis会把每一个写请求都记录在一个日志文件里。在Redis重启时，会把AOF文件中记录的所有写操作顺序执行一遍，确保数据恢复到最新。AOF默认是关闭的，如要开启，进行如下配置：

appendonly yes

AOF提供了三种fsync配置，always/everysec/no，通过配置项[appendfsync]指定：

appendfsync no：不进行fsync，将flush文件的时机交给OS（操作系统）决定，速度最快

appendfsync always：每写入一条日志就进行一次fsync操作，数据安全性最高，但速度最慢

appendfsync everysec：折中的做法，交由后台线程每秒fsync一次

随着AOF不断地记录写操作日志，因为所有的操作都会记录，所以必定会出现一些无用的日志。大量无用的日志会让AOF文件过大，也会让数据恢复的时间过长。不过Redis提供了AOF rewrite功能，可以重写AOF文件，只保留能够把数据恢复到最新状态的最小写操作集。

AOF rewrite可以通过BGREWRITEAOF命令触发，也可以配置Redis定期自动进行：

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

上面两行配置的含义是，Redis在每次AOF rewrite时，会记录完成rewrite后的AOF日志大小，当AOF日志大小在该基础上增长了100%后，自动进行AOF rewrite。同时如果增长的大小没有达到64mb，则不会进行rewrite。

2.2 AOF优点：

• 1、最安全，在启用appendfsync always时，任何已写入的数据都不会丢失，使用在启用appendfsync everysec也至多只会丢失1秒的数据

• 2、AOF文件在发生断电等问题时也不会损坏，即使出现了某条日志只写入了一半的情况，也可以使用redis-check-aof工具轻松修复。

• 3、AOF文件易读，可修改，在进行了某些错误的数据清除操作后，只要AOF文件没有rewrite，就可以把AOF文件备份出来，把错误的命令删除，然后恢复数据。

2.3 AOF的缺点：

• 1、AOF文件通常比RDB文件更大

• 2、性能消耗比RDB高

• 3、数据恢复速度比RDB慢

2.4 AOF方案配置

cd /export/servers/redis-3.2.8
vim redis.conf

appendonly yes
# appendfsync always
appendfsync everysec
# appendfsync no

在redis中的新添加的数据在断开服务之后，依然存在

AOF小结

方式2、AOF
	appendfsync no： 表示由OS决定何时触发数据存储。数据存储速度最快，但丢失数据风险较高。
	appendfsync always：表示每条数据都进行一次存储，数据丢失的风险最低，但存储的速度比较慢。
	appendfsync everysec：表示每秒存储一次。

	配置：修改redis.conf配置文件，将appendonly  no改成appendonly  yes。
		启动redis 设置新数据，重启redis查看数据是否存在，若在表示成功，反之不成功。

	缺点：AOF比RDB数据文件大，性能消耗及RDB高，恢复数据的速度慢。

IT行业数据读取写入性能优化 终极解决方案（人生精华）
读写分离

1、基于一台服务器内的多个磁盘，1、2、3磁盘只负责数据的写入，4、5、6只负责数据读取

2、多个服务器，1、2、3服务器只负责数据写入，4、5、6只负责数据的读取。