Redis从入门到入土——Redis持久化方案以及主从复制

Redis入门第四天：主要介绍了Redis的持久化方案（RDB、AOF）以及Redis的主从复制

Redis

系列文章

Redis第一天

Redis第二天

Redis第三天

Redis第四天

Redis第五天

Redis 持久化方案

导读

Redis是一个内存数据库，为了保证数据的持久化，提供了两种方案

• RDB方式（默认）做镜像全量持久化
• AOF方式做增量持久化

​ RDB会消耗较长时间，不够实时，并且在停机的时候会导致大量丢失数据，所以需要AOF来配合使用。在redis实例重启时，会使用RDB持久化文件重新构建内存，再使用AOF重放近期的操作指令来实现完整恢复重启以前的状态

​ 不过Redis本身的机制是 AOF持久化开启且存在AOF文件时，优先加载AOF文件；AOF关闭或者AOF文件不存在时，加载RDB文件；加载AOF/RDB文件后，Redis启动成功； AOF/RDB文件存在错误时，Redis启动失败并打印错误信息

RDB方式

• RDB是Redis的默认采用的持久化方式

• RDB方式是通过快照完成的，当符合一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。

• 原理：

• • fork和cow
• • • fork是指redis通过子进程来进行RDB操作
    • cow指的是copy on write，子进程创建后，父进程共享数据段，父进程及时提供读写服务，写脏的页面数据会主键和子进程分离开来。

RDB触发条件

• 符合自定义配置的快照规则
• 执行save或者bgsave命令
• 执行flushall命令
• 执行主从复制操作

在redis.conf设置自定义快照规则

• RDB持久化条件

• • 格式：save
  • 实例：
• • • save 900 1：表示900秒内至少1个键更改则进行快照

• 配置dir指定rdb快照文件的位置

# Note that you must specify a directory here, not a file name.
dir ./

• 配置dbfilename指定rdb快照文件的名称

# The filename where to dump the DB
dbfilename dump.rdb

说明

• Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存
• 根据数量量大小与结构和服务器性能不同，这个时间也不同。

快照的实现原理

快照过程

• redis使用fork函数复制一份当前进程的副本（子进程）
• 父进程继续接受并处理客户端发来的命令，而子进程开始将内存中的数据写入到硬盘中的临时文件
• 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此，一次快照操作完成。

注意

• redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是任何时候RDB文件都是完整的
• 这就使得我们可以通过定时备份RDB文件来实现redis数据库的备份，RDB是经过压缩的二进制文件，占用的空间会小于内存中的数据，这便于传输

RDB优缺点

缺点

​ 使用RDB方式实现持久化，一旦redis异常退出，就会丢失最后一次快照以后更改的所有数据。

​ 如果数据相对比较重要，希望将损失降到最小，则可以使用AOF方式进行持久化

优点

• RDB可以最大化redis的性能：父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会去处理接下来所有的保存工作，父进程无须执行任何磁盘I/O操作。但是在数据集比较大的时候，fork可能比较耗时，造成服务器在一段时间内停止处理客户端的请求

AOF方式

介绍

• 默认不开启
• 开启AOF持久化后，每执行一条会更改Redis中的数据命令，Redis就会将该命令写入到硬盘中的AOF文件，这一过程会降低Redis的性能，但是大部分情况下都是可用接收的，另外使用较快的硬盘可以提高AOF的性能

配置redis.conf

• 设置appendpnly参数为yes

appendonly yes

• AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的

dir ./

• 默认文件名是appendonly.aof,可以通过appendfilename参数修改

appendfilename appendonly.aof

AOF重写原理（优化AOF文件）

• Redis可以在AOF文件体积变得过大时，自动地对AOF进行重写
• 重写后的新AOF文件包含了回复当前数据集所需的最小命令集合
• 整个重写操作是绝对安全的，因为Redis在创建新的AOF文件的过程中，会继续将命令追加到现有的AOF文件里面，即使重写过程中发生停机，现有的AOF文件也不会丢失。而一旦新AOF文件创建完毕，Redis就会从旧AOF文件切换到新AOF文件，并开始对新AOF文件进行追加操作
• AOF文件有序地保证了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析(parse)也很轻松。

参数说明

• #auto-aof-rewrite-percentage 100：表示当前aof文件大小超过上次aof文件大小的百分之多少的时候会进行重写。如果之前没有重写过，以启动时aof文件大小为基准。
• #auto-aof-rewrite-min-size 64mb：表示限制允许重写最小aof文件大小，也就是文件大小小于64mb的时候，不需要进行优化
• appendfsync always：每次执行写入都会进行同步，这个是最安全但是效率比较低
• appendfsync everysec：每一秒执行
• appendfsync no：不主动进行同步操作，由于操作系统去执行，这个是最快但是最不安全的方式

同步磁盘数据

• Redis每次更新数据的时候，aof机制都会将命令记录到aof文件，但是实际上由于操作系统的缓存机制，数据并没有实时写入到硬盘，而是进入硬盘缓存。再通过硬盘缓存机制去刷新到保存文件中

AOF文件损坏后如何修复

• Redis在重启时会拒绝载入这个AOF文件，从而确保数据的一致性不会被破坏

• 当发生时可以选择以下的方式来修复出错的AOF文件

• • 为现有的AOF文件创建一个备份
  • 使用Redis附带的redis-check-aof程序，对原来的AOF文件进行修复
  • 重启Redis文件服务器，等待服务器载入修复后的AOF文件，并进行数据恢复

RDB和AOF优缺点

RDB

• 优点：

• • 会生成多个数据文件，每个数据文件分别代表某一时刻Redis里面的数据。完整的数据运维设置定时任务，定时同步到远端的服务器
  • RDB对Redis性能的影响小，因为在同步数据时只是fork了一个子进程去做持久化，在数据恢复的时候的速度也是比AOF快

• 缺点：

• • RDB都是快照文件，都是默认五分钟或者更近才生产一次，而AOF则最多丢失一秒的数据
  • RDB在生成数据快照的时候，如果文件很大，客户端会暂停，在秒杀的时候fork一个子进程去生成一个大快照容易出现问题

AOF

• 优点：

• • AOF是一秒一次去通过一个后台的线程fsync操作，最多丢失一秒的数据
  • AOF在对日志文件进行操作的时候是使用append-only的方式去写的，只是追加的方式写数据，少了很多磁盘寻址的开销，写入速度惊人，文件也不容易被破坏
  • AOF的日志是通过一个叫非常刻度的方式记录的，这样的特性就适合做灾难性数据误删除的紧急恢复

• 缺点

• • AOF比RDB文件大
  • AOF开启后，Redis支持写的QPS会比RDB支持写的要低，因为每秒要异步去刷新一次日志fsync，

如何选择RDB和AOF

• 一般来说，如果对数据的安全性要求非常高，应该同时使用这两种持久化功能，单独使用RDB会丢失很多数据、单独使用AOF数据恢复没有RDB快，出现问题的时候第一时间用RDB恢复，然后AOF做数据补全
• 如果可以承受数分钟的数据丢失，那么只使用RDB持久化
• 有很多用户都只使用AOF持久化，但并不推荐这种方式：因为定时生成RDB快照(snapshot)非常便于进行数据库备份，并且RDB恢复数据集的速度也要比AOF恢复的速度要快
• 两种持久化策略可以同时使用，也可以使用其中一种。如果同时使用的话，那么Redis启动时，会优先使用AOF文件来还原数据。

Redis的主从复制

什么是主从复制

​ 持久化保证了即使redis服务重启也不会丢失数据，因为redis服务重启后将硬盘上持久化的数据恢复到内存中，但是当redis服务器的硬盘损坏了，可能导致数据丢失，不过通过redis的主从复制机制，就可以避免这种单点故障

• 说明：

• • 主Redis中的数据有两个副本（replication）即从redis1和从redis2，即使一台redis服务器宕机，其他两台也可以继续提供服务
  • 主redis和从redis，在数据上保持实时同步，当主redis写入数据时通过主从复制机制来复制到两个从redis上
  • 只有一个主redis但是可以有多个从redis
  • 主从复制不会阻塞master，在同步数据时，master可以继续处理client请求

主从配置

主Redis配置

​ 无特殊配置

从Redis配置

• 修改从服务器上的redis.conf文件

# slaveof  
slaveof 192.168.31.200 6379

• 对应主服务器的ip和端口号

实现原理

• slave第一次或者重连到master发送一个SYNC命令。

• master收到SYNC后

• • 执行bgsave（rdb的快照文件）
  • master会把新收到的修改命令存入到缓冲区

缺点：没有办法对master进行动态选举

Redis的同步机制

​ 可以使用主从同步和从从同步，第一次同步时，主节点做一次bgsave，并同意将后续修改操作记录到内存buffer，待完成后将RDB文件全量同步到复制节点，复制节点接受完成后将RDB镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。后续的增量数据通过AOF日志同步即可，有点类似数据库的binlog。

最后

• 如果觉得看完有收获，希望能给我点个赞，这将会是我更新的最大动力，感谢各位的支持
• 欢迎各位关注我的公众号【java冢狐】，专注于java和计算机基础知识，保证让你看完有所收获，不信你打我
• 如果看完有不同的意见或者建议，欢迎多多评论一起交流。感谢各位的支持以及厚爱。