Redis持久化深入理解
用过Redis的都知道，Redis有两种持久化方式：RDB和AOF，他们的区别大家应该都清楚，所以今天主要想分享一下这两种持久化方式的底层原理以及实现。
如果让你手写一个持久化(架构级)的功能，你没有思路的话，那希望这个文章可以给你灵感。
1.RDB持久化
1.1创建
简单回顾下RDB文件的创建。
有两种创建方式：
save.阻塞进程去处理(期间不处理别的请求)
bgsave.派生一个子进程去处理
1.2载入
在redis服务启动时，如果检测到RDB文件，会进行自动载入。
如果RDB文件和AOF都存在，优先载入谁？
如果开启了AOF，则会优先AOF
1.3save的底层实现
save9001
save30010
save6010000
这是redis.conf配置文件中关于RDBsave时机的配置，它映射在redisServer结构体的saveparams字段中：
structredisServer{
....
//保存了redis.conf配置的属性
structsaveparam*saveparams;
//记录上一次save的时间
time_tlastsave;
//修改计数器
longlongdirty;
...
};
那来看看它怎么保存的：
structsaveparam{
//秒数
time_tseconds;
//修改次数
intchanges;
};
redis自己有一个定时任务每100毫秒执行一次，其中有一个任务就是检查save条件是否满足，如何判断的呢？就是用lastsave与saveparam.seconds比较时间是否满足，dirty与changes比较修改次数是否满足。
那bgsave如何实现呢，new一个子线程，然后拷贝个数据副本，然后和save一样处理。
好了，到这里，用Java写一个这应该是没问题了，那RDB的文件结构如何设计呢？我们来看看redis的设计。
1.4RDB文件结构
REDIS+数据库版本号+数据类型+数据+EOF(表示数据结束)(377)+检验和
我们知道java中Class文件结构很复杂，因为它包含了常量、接口、类、父类、字段等面向对象的信息，而RDB的就比较简单了，因为它只需要存放数据即可。
和class结构一样，它的开头也是文件标识REDIS+版本号标识.
[root@izuf6i2jk9azj2te13kjx8zredis-4.0.9]#od-cdump.rdb
0000000REDIS0008372tredis
0000020-ver0054.0.9372nredi
0000040s-bits300@372005ctime302
0000060231;017]372bused-mem302310
0000100pr0372faof-preambl
0000120e30003760373(00006k-7599
0000140006v-75990022cpt:2543550
0000160005t0agetOne4303L220^303
00002000372543550005sr0%com.fan
0000220t.core.response.
0000240S005erverR240016030222224e250:
0000260035323?0020003I0006statusL
00003000004dat0310022Ljava/l
0000320ang/Object;L0003ms
0000340g340005032fString;xp00
00003600310y0036340005y037pojo.C
0000400ompetitionZ276231334b025
...
0140540a004java377v006number024
01405600020000060000010002000300040
014060000500060016004list001027027000
014062002400000600362002363002364002365002366
0140640002367377377-022036]367332257_
分析：
REDIS:RDB文件标志
0008：版本号
372:结束符
redis
0000020-ver0054.0.9:redis-version4.0.9
redi
0000040s-bits300@:redis的位数64或32
ctime3020000060231;017]:时间戳
used-mem3023100000100pr0:redis使用内存的大小
374：RDB_OPCODE_EXPIRETIME_MS(带有过期时间标识)
0:表示字符串
最后8字节为校验和
更详细的可以查看http://redisbook.com/preview/rdb/rdb_struct.html
手写过Jedis的朋友都熟悉RESP协议，RDB的数据段和它的排版方式很相似。比如：003msg005hello377就表示键值对：msg(3个长度):hello(5个长度)
AOF
AOF以拼接和重写命令的方式来实现。
#是否开启aof
appendonlyyes
#文件名称
appendfilename"appendonly.aof"
#同步方式
##每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
#appendfsyncalways
##每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，系统默认
appendfsynceverysec
##完全依赖os，性能最好,持久化没保证
#appendfsyncno
#aof重写期间是否同步
no-appendfsync-on-rewriteno
#重写触发配置
auto-aof-rewrite-percentage100
auto-aof-rewrite-min-size64mb
#加载aof时如果有错如何处理
aof-load-truncatedyes
#文件重写策略
aof-rewrite-incremental-fsyncyes
这一段配置中，大家着重理解同步方式的配置。redis默认采用的每秒一次写入AOF文件的策略。
实现原理
structredisServer{
//...
//存放AOF缓冲
sdsaof_buf;
//...
};
当有新的命令进来，redis就会将其(协议化后)追加到aof_buf的末尾。
同理，redis的事件循环也会监听AOF的配置，如果满足配置文件中的同步方式appendfsynceverysec等，就会将aof_buf中的内容保存到AOF文件里。
为什么要进行AOF重写
我们知道，redis对AOF有重写机制，用来控制AOF文件的大小。
AOF体积过大不利于存储。
AOF体积过大，使用AOF数据还原的时间更长。
AOF重写多个键值对的数据一定是使用一条数据完成吗
发生在重写列表、哈希表、集合、有序集合可能会带有多个元素的键时。
不是，如果它的值超过64项，则会用多条命令来完成。(避免客户端输入缓冲区溢出)
AOF谁来执行
Redis不希望AOF重写造成服务器阻塞，所以用子进程(带有数据副本)去处理。
AOF期间有新的数据进来会导致AOF文件与当前数据不一致吗
不会。为了解决这个问题，Reids设置了AOF重写缓冲区(创建子进程后开启)，当Redis执行命令时，redis会同时将这个信息发送给aof_buf和AOF重写缓冲区。
扩展
过期键的删除策略
定时删除。过期键较多的情况下，大量的CPU用于删除键而影响了客户端的请求。
惰性删除。只有过期键被访问才删除，可能会导致过期键过多，造成内存浪费和溢出。
定期删除。限制时长和频率对过期键进行删除，难点在于时长和频率难以确定。
Redis的过期键删除策略
Redis采用的是惰性删除和定期删除，配合这两种策略来取得CPU和内存的平衡。
RDB和AOF文件中会包含过期键吗
不包含。
在生成RDB和AOF文件时，程序会对键进行检查，已过期的键不保存到文件中。
如果您觉得本文的内容对您的学习有所帮助：
关键字：
html