Redis入门第四天：主要介绍了Redis的持久化方案（RDB、AOF）以及Redis的主从复制
Redis
Redis 持久化方案
导读
Redis是一个内存数据库，为了保证数据的持久化，提供了两种方案
- RDB方式（默认）
- AOF方式
RDB方式
- RDB是Redis的默认采用的持久化方式
- RDB方式是通过快照完成的，当复核一定条件时Redis会自动将内存中的数据进行快照并持久化到硬盘。
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持久化
- 有很多用户都只使用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 <masterip> <masterport> slaveof 192.168.31.200 6379对应主服务器的ip和端口号
实现原理
- slave第一次或者重连到master发送一个SYNC命令。
- master收到SYNC后
- 执行bgsave（rdb的快照文件）
- master会把新收到的修改命令存入到缓冲区
缺点：没有办法对master进行动态选举
