Redis持久化机制 AOF、RDB

Redis持久化机制（保证Redis挂掉后再重启数据可以进行恢复）

Redis支持两种持久化操作。

一种是持久化快照(snapshotting,RDB)

一种是只追加文件(append-only file,AOF)

 

1、快照 snapshotting 持久化(RDB） 缺点：两次持久化时间太长。

Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本，Redis创建快照后，可以对快照进行备份，可以将快照复制到其他服务器从而具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性能），

还可以将快照留在原地以便重启服务器的时候使用。

快照持久化Redis默认采用持久化方式，在redis.conf配置文件中默认有以下配置：

save 900 1 #同下 

save 300 10 #在300秒后，如果有10个key变化，自动触发BGSAVE命令创建快照。                                           主进程进行save。

bgsave开始fork主进程得到子进程，子进程共享主进程的内存数据。完成fork后读取内存数据写入RDB文件。   子进程避免主进程阻塞。

 

这个时候就要用到 写时复制，即当请求需要对键值C进行操作时，主线程会把新数据或修改后的数据写到一个新的物理内存地址上（键值对C'），并修改主线程自己的页表映射。

所以，子进程读到的类似于原始数据的一个副本，而主线程也可以正常进行修改。

 

 

 

 

 

 

 

（linux系统中用户态是无法直接操作物理内存，操作系统会分配一个虚拟内存，来映射物理内存）

 

2、AOF（append-only file）持久化  优点：数据更完善。

与快照持久化相比，AOF持久化实时性更好，是主流持久化方案。默认redis是没有开启的AOF。

在redis.conf中配置appendonly yes

开启AOF持久化以后，执行一条会更改Redis中的数据命令，Redis会将该命令写入到内存缓存server.aof_buf中

然后根据appendsync配置决定什么时候同步到硬盘的AOF文件中。

AOF文件的保存位置和RDB文件位置相同，都是通过dir参数设置，文件默认名是appendonly.aof。

 三种模式：每一种都是先写入到aof_buf 区，在写入命令的时候就直接写入到buf区。然后根据1、2、3种模式来进行刷盘，always

是每次写完都进行刷盘，fsync，everysec是一秒刷盘一次，可能造成丢失一秒数据，no是让操作系统什么时候刷盘。

 

 every sec是默认。

 bgrewriteaof,可以让Aof执行重写功能，达到最少命令的效果。  

 

 

 

Redis bigkey

如果一个key对应的value所占的内存比较大，那么这个key可以看做bigkey，

一般来说：具体String类型的value超过10kb,复合类型的value包含元素超过5000个。

复合类型（不一定包含的元素越多，占用的内存就越多）

bigkey有什么危害？

除了会消耗更多的内存空间，bigkey对性能也有比较大的影响。

1、发现bigkey？

redis-cli -p 6379 --bigkeys 来查找

2、分析RDB文件

前提是要持久化了RDB文件。