Redis5.x两种持久化方式以及主从复制配置
关注公众号：CoderBuff，回复“redis”获取《Redis5.x入门教程》完整版PDF。
- 《Redis5.x入门教程》目录
- 第一章 · 准备工作
- 第二章 · 数据类型
- 第三章 · 命令
- 第四章 · 配置
- 第五章 · Java客户端（上）
- 第六章 · 事务
- 第七章 · 分布式锁
- 第八章 · Java客户端（下）
配置
redis除了支持多种多样的存储类型，还有一点也非常重要，那就是尽管它是基于内存的存储系统，但它也能进行数据的持久化操作。这一点，对于缓存不幸宕机想恢复缓存数据时相当有效。同样，我们实际使用redis时，为了更高的性能和更高的可用性会将redis配置为集群主从模式。本章节重点介绍持久化和主从复制的相关配置。
持久化
redis的持久化有两种方式：快照持久化（RDB）和AOF持久化。
快照持久化（RDB）
快照持久化，是在某一时刻的所有数据写入到硬盘中持久化。显然，这存在一个“何时”写入硬盘的问题。如果相隔时间过长，那么恰好在没有持久化前宕机，这部分数据就会丢失。也就是说，无论如何配置持久化的时机，都有可能存在丢失数据的风险。所以，快照持久化适用于即使丢失一部分数据也不会造成问题的场景。
配置快照持久化，既可以直接通过命令，也可以通过配置文件的方式。
配置文件
回到我们redis的安装位置，根据第一章准备工作，redis安装在/usr/local/redis-5.0.7路径，修改redis.conf配置文件。在配置文件中包含了持久化的相关配置、模板插件、lua脚本等等，我们提取出关于快照持久化相关的配置信息。
################################ SNAPSHOTTING ################################
# save [seconds] [changes] 表示在[seconds]秒内有[changes]个键值的变化则进行持久化。可同时配置多个，满足一个条件则触发。
save 900 1 #在900秒内有1次键值变化则进行持久化。
save 300 10 #在300秒内有10次键值变化则进行持久化。
save 60 10000 #在60秒内有10000次键值变化则进行持久化。
stop-writes-on-bgsave-error yes #当持久化出现错误时，是否停止数据写入，默认停止数据写入。可配置为no，当持久化出现错误时，仍然能继续写入缓存数据。
rdbcompression yes #是否压缩数据，默认压缩。可配置为no，不压缩。
rdbchecksum yes #对持久化rdb文件是否进行校验，默认校验。可配置为no，不校验。
dbfilename dump.rdb #指定rdb保存到本地的文件名。
dir ./ #指定rdb保存的目录，默认在本目录下，即redis的安装目录。
在redis中，持久化默认使用快照持久化方式，如果想要开启AOF持久化appendonly yes，下文会讲AOF持久化的配置。
注意，尽管这是redis安装目录下默认的配置文件，但我们在启动时需要制定配置文件的路径。如果在启动时使用redis-server则会有以下提示：
10768:C 08 Feb 2020 19:52:40.149 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
所以我们终止redis服务，并在配置文件中增加一条save 10 1“在10秒内有1次键值变化则持久化”配置，指定redis安装目录下的配置文件。
okevindeMacBook-Air:redis-5.0.7 okevin$ redis-server redis.conf
14206:C 11 Feb 2020 23:58:52.589 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
14206:C 11 Feb 2020 23:58:52.589 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=14206, just started
14206:C 11 Feb 2020 23:58:52.589 # Configuration loaded
可以看到，安装目录下的配置文件加载成功。
接下来我们来验证redis是否是“在10秒内有1次键值变化则持久化”，我们通过redis-cli进入redis命令行交互，并且写入一条数据。在redis的启动窗口出现了以下日志内容：
14234:M 12 Feb 2020 00:02:13.016 * 1 changes in 10 seconds. Saving...
14234:M 12 Feb 2020 00:02:13.017 * Background saving started by pid 14235
14235:C 12 Feb 2020 00:02:13.020 * DB saved on disk
14234:M 12 Feb 2020 00:02:13.121 * Background saving terminated with success
这表示配置生效了。
直接修改配置文件的方式需要重启redis服务，我们可以直接通过命令动态修改配置：
127.0.0.1:6379> config set save "5 1"
OK
此时写入一条数据，并在redis的启动窗口验证：
14206:M 12 Feb 2020 00:04:26.133 * 1 changes in 5 seconds. Saving...
14206:M 12 Feb 2020 00:04:26.134 * Background saving started by pid 14237
14232:C 12 Feb 2020 00:04:26.139 * DB saved on disk
14206:M 12 Feb 2020 00:04:26.238 * Background saving terminated with success
可见，我们已经动态地修改了快照持久化的配置。不过这种动态配置的方式当在redis重启后将会失效。
命令
除了通过配置文件的方式快照持久化，我们还可以通过命令的方式“随时”地进行快照持久化，有两个命令可供使用：bgsave和save。bgsave，redis会创建一个子进程，通过子进程将快照写入硬盘，父进程则继续处理命令请求。save则是redis在快照创建完成前不会响应其他命令，也就是阻塞式的，并不常用。
在redis客户端使用bgsave命令：
127.0.0.1:6379> bgsave
Background saving started
在redis服务端的日志：
14234:M 12 Feb 2020 00:15:11.943 * Background saving started by pid 14245
14245:C 12 Feb 2020 00:15:11.948 * DB saved on disk
14234:M 12 Feb 2020 00:15:12.031 * Background saving terminated with success
在redis客户端使用save命令：
127.0.0.1:6379> save
OK
在redis服务端的日志：
14234:M 12 Feb 2020 00:16:12.922 * DB saved on disk
通过redis服务端的日志我们就能发现，配置文件中的save配置底层调用的是bgsave命令。那么什么时候会用到save命令呢？
那就是在调用shutdown命令时，将会调用save命令阻塞其他命令，当执行完成后关闭服务器。
在redis客户端调用shutdown命令：
127.0.0.1:6379> shutdown
在redis服务端的日志：
14234:M 12 Feb 2020 00:18:52.353 # User requested shutdown...
14234:M 12 Feb 2020 00:18:52.353 * Saving the final RDB snapshot before exiting.
14234:M 12 Feb 2020 00:18:52.356 * DB saved on disk
14234:M 12 Feb 2020 00:18:52.356 * Removing the pid file.
14234:M 12 Feb 2020 00:18:52.357 # Redis is now ready to exit, bye bye...
AOF持久化
AOF持久化的方式和MySQL中binlog主从同步类似，它记录的是执行的命令，将被执行的写命令写入到AOF文件的末尾。它同样有持久化时机的问题，通常我们会配置“每秒执行一次同步”。下面我们仍然通过配置来直观感受一下。
配置文件
############################## APPEND ONLY MODE ###############################
appendonly no #是否开起AOF持久化，默认关闭，yes打开。在redis4.0以前不允许混合使用RDB和AOF，但此后允许使用混合模式，通过最后两个参数配置。
appendfilename "appendonly.aof" #AOF持久化数据的文件名。
appendfsync everysec #执行AOF持久化的频率，默认“每秒执行一次同步”。还有“always”选项，表示每个redis命令都要同步写入硬盘，但是这样会严重减低redis的速度。还有“no”选项，此时持久化的时机将有操作系统决定。redis建议如果你不知道怎么做，就使用“everysec”配置。
no-appendfsync-on-rewrite no #默认不重写AOF文件。
#下面这两个配置是用于AOF“重写”触发条件。当AOF文件的体积大于64m，且AOF文件的体积比上一次重写之后的体积至少打了一倍（100%）则执行重新命令。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes #指redis在恢复时，会忽略最后一条可能存在问题的指令，默认值yes。
aof-use-rdb-preamble yes #是否打开RDB和AOF混合模式，默认yes打开。
我们修改配置文件中appendonly yes即打开AOF持久化，并重启redis服务。
和快照持久化略微不同的是我们在redis-cli中写入一条数据后，redis服务端并没有记录AOF的持久化日志。但我们在启动时，会出现从AOF文件中加载数据。
15336:M 12 Feb 2020 14:21:42.541 # Server initialized
15336:M 12 Feb 2020 14:21:42.542 * DB loaded from append only file: 0.001 seconds
15336:M 12 Feb 2020 14:21:42.542 * Ready to accept connections
如果我们此时关闭redis服务端再启动，由于我们开启了持久化所以仍然能获取到刚刚写入的值。
和快照持久化相同，我们同样能在命令行中通过config set appendonly "yes"动态修改配置文件。
在前面的配置文件中，我们提到了“重写”这个术语，它实际上是针对AOF文件过大，需要覆盖掉之前的AOF文件的配置。它和bgsave类似，都是通过一个子进程操作。
主从复制
对于一个使用了redis的大型应用程序，为了保证redis的性能，我们会配置redis集群。同MySQL类似，redis的主服务器（master）也会向多个从服务器（slave）发送更新。主服务器负责写、从服务器负责读，以提高性能。
这一小节，我会找到另外一台mac实体机在同一局域网内实现redis主从复制，当然你也可以在虚拟机中试验。
修改master主服务器的配置文件（为了更好演示主从复制，将尽可能做更少的配置）：
#bind 127.0.0.1 #默认只允许本机连接redis服务，所以需要注释掉这行配置。
protected-mode no #默认打开了保护模式，这里我们配置为no关闭。
daemonize no #实际应用中，我们是通常是将redis以后台运行，也就是会配置为yes，默认是no表示不以后台运行。我们在这里保持默认的配置，方便查看相关的运行日志。
修改slave从服务器的配置文件（只比master多一行配置）：
#bind 127.0.0.1 #默认只允许本机连接redis服务，所以需要注释掉这行配置。
protected-mode no #默认打开了保护模式，这里我们配置为no关闭。
daemonize no #实际应用中，我们是通常是将redis以后台运行，也就是会配置为yes，默认是no表示不以后台运行。我们在这里保持默认的配置，方便查看相关的运行日志。
slaveof 192.168.31.125 6379
我们先启动master主服务器显示以下信息：
okevindeMacBook-Air:redis-5.0.7 okevin$ redis-server redis.conf
15702:C 12 Feb 2020 22:18:24.777 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
15702:C 12 Feb 2020 22:18:24.778 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=15702, just started
15702:C 12 Feb 2020 22:18:24.778 # Configuration loaded
15702:M 12 Feb 2020 22:18:24.781 * Increased maximum number of open files to 10032 (it was originally set to 2560).
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 5.0.7 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in standalone mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 6379
| `-._ `._ / _.-' | PID: 15702
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
15702:M 12 Feb 2020 22:18:24.801 # Server initialized
15702:M 12 Feb 2020 22:18:24.803 * DB loaded from append only file: 0.002 seconds
15702:M 12 Feb 2020 22:18:24.803 * Ready to accept connections
再启动slave从服务器显示以下信息：
t4f-mbp-17346:redis-5.0.7 yulinfeng$ redis-server redis.conf
13801:C 12 Feb 2020 22:20:08.954 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
13801:C 12 Feb 2020 22:20:08.954 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=13801, just started
13801:C 12 Feb 2020 22:20:08.954 # Configuration loaded
13801:S 12 Feb 2020 22:20:08.955 * Increased maximum number of open files to 10032 (it was originally set to 256).
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 5.0.7 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in standalone mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 6379
| `-._ `._ / _.-' | PID: 13801
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
13801:S 12 Feb 2020 22:20:08.956 # Server initialized
13801:S 12 Feb 2020 22:20:08.956 * Ready to accept connections
13801:S 12 Feb 2020 22:20:08.957 * Connecting to MASTER 192.168.31.145:6379
13801:S 12 Feb 2020 22:20:08.965 * MASTER <-> REPLICA sync started
13801:S 12 Feb 2020 22:20:09.030 * Non blocking connect for SYNC fired the event.
13801:S 12 Feb 2020 22:20:09.034 * Master replied to PING, replication can continue...
13801:S 12 Feb 2020 22:20:09.039 * Partial resynchronization not possible (no cached master)
13801:S 12 Feb 2020 22:20:09.043 * Full resync from master: b7b0b93ea396930cc622250b959fd9eb8eb71c5f:0
13801:S 12 Feb 2020 22:20:09.138 * MASTER <-> REPLICA sync: receiving 185 bytes from master
13801:S 12 Feb 2020 22:20:09.139 * MASTER <-> REPLICA sync: Flushing old data
13801:S 12 Feb 2020 22:20:09.139 * MASTER <-> REPLICA sync: Loading DB in memory
13801:S 12 Feb 2020 22:20:09.139 * MASTER <-> REPLICA sync: Finished with success
可以看到从服务器在启动完成后多了一些日志，第一行MASTER <-> REPLICA sync started向主服务器发送了同步的命令，一直到最后同步成功。
我们回到master主服务的日志：
15702:M 12 Feb 2020 22:20:09.010 * Replica 192.168.31.215:6379 asks for synchronization
15702:M 12 Feb 2020 22:20:09.010 * Full resync requested by replica 192.168.31.215:6379
15702:M 12 Feb 2020 22:20:09.010 * Starting BGSAVE for SYNC with target: disk
15702:M 12 Feb 2020 22:20:09.011 * Background saving started by pid 15703
15703:C 12 Feb 2020 22:20:09.014 * DB saved on disk
15702:M 12 Feb 2020 22:20:09.106 * Background saving terminated with success
15702:M 12 Feb 2020 22:20:09.106 * Synchronization with replica 192.168.31.215:6379 succeeded
可以看到，第一行表示有一台从服务器正在请求同步，并且观察日志可以发现主服务器此时执行了bgsave命令进行了一次持久化操作。
此时，当我们在主服务写入一条数据时，在从服务器就可以读取到了。但是，如果我们在从服务器写入数据时会出现以下错误：
127.0.0.1:6379> set slave master
(error) READONLY You cant't write against a read only replica.
回顾主从复制中的一些细节，除了配置文件需要有注意的地方，在底层当从服务器连接到主服务器时会发送一条sync同步命令，当主服务器接收到从服务器的sync同步命令后，会在主服务器中执行bgsave持久化命令，执行完成后将向从服务器发送一份快照持久化的文件以完成同步。并且从服务器是只读不能写入的。
关注公众号：CoderBuff，回复“redis”获取《Redis5.x入门教程》完整版PDF。
