RDB持久化
RDB进行Redis的持久化，是将Redis在内存中的二进制数据进行压测保存到文件，在启动Redis时候，Redis会检测是否存在RDB文件，如果存在就会对文件进行分析和恢复。
两种触发RDB备份的操作
- SAVE：通过SAVE命令触发Redis进行RDB备份，此时服务器进程会处理备份请求，不会在处理任何其他的命令请求。
- BGSAVE：通过新建子进程来进行备份，Redis服务器会进行处理客户端的其他命令请求。
配置RDB
如果我们没有在配置文件中显式去配置，Redis会有一个默认的RDB配置。
save 900 1 //900秒内发生1次更新
save 300 10 //300秒内发生10次更新
save 60 10000 //60秒内发生10000次更新
三个条件满足任意一个，BGSAVE命令就会被Redis执行。
计数与计时
redisServer由dirty属性以及lastsave属性。
- dirty：每次备份开始会被置为0，每一次发生更新该属性会加1。
- lastsave：每次备份开始都会记录当前时间，通过该属性可以计算出距离上次备份经过了多长时间。
redis服务器每100毫秒进行一次判断是否应该进行RDB备份，就是通过dirty和lastsave配合配置进行的判断。
AOF持久化
与RDB把内存中二进制数据保存的方式不同，AOF是把更新数据库的命令保存下来。
基本原理
每一次发生更新命令时，redis会把命令放到aof_buf中，每次在执行完成命令之后，会判断是否达到备份条件，如果达到就把aof_buf中的数据保存到AOF文件中。
AOP配置
appendfsync always //每次执行完成更新命令，都会被命令写到AOF文件中
appendfsync everysec //每秒一次，把aof_buf中的命令写道AOF文件中
appendfsync no //由redis执行决定何时同步
AOF的载入还原
如果Redis服务器同时配置了RDB和AOF两种持久化策略，会优先使用AOF进行数据恢复。使用AOF文件进行数据恢复的方式与RDB不同，开始备份时，会创建一个不带网络连接的伪客户端，该客户端来读取AOF中的命令，并一条一条的发送给Redis服务器进行执行。
AOF重写
随着服务器的运行，AOF文件会越来越大，这个时候Redis会对AOF进行重写。进行重写并不是像字面上的意思那样，对AOF文件进行解析重写，Redis在进行AOF重写时，实际上是把数据库中的每一个键值对进行分析，分析成为Redis命令写到新的AOF文件中，完成之后再用新的AOF文件替换旧的AOF文件。
后台AOF
Redis进行AOF的时候，其实也是在后台开启了一个子进程进行AOF的备份，此时在子进程进行AOF备份时，主进程同样可以处理其他命令，这样就会出现在这期间新发生的更新操作没办法记录到AOF的情况，导致数据不一致的情况。为了解决这个问题，在发生AOF重写时，主进程在处理更新请求时，不仅会把命令写道aof_buf中，同时会写到AOF重写缓冲区中。当子进程完成AOF重写时，会发送一个信号给主进程，主进程触发信号处理函数，将AOF重写缓冲区中的所有内容写到新的AOF文件中。在信号处理函数执行期间，主进程会阻塞，不在处理其他命令。
无论时RDB备份还是AOF重写都是在后台fork出一个子进程来完成具体操作，这样的好处是，子进程使用的是主进程的数据副本，不会影响主进程的正常使用，需要注意AOF重写时数据一致性的问题。
标签：AOF,备份,Redis,命令,RDB,重写 来源： https://blog.csdn.net/solo_jm/article/details/118637726
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。