Redis实战 | 持久化、主从复制特性和故障处理思路
前言
前面两篇我们了解了Redis的安装、Redis最常用的5种数据类型。本篇总结下Redis的持久化、主从复制特性，以及Redis服务挂了之后的一些处理思路。
前期回顾传送门：
Linux下安装Redis简易教程
Redis实战 | 5种Redis数据类型详解
Redis的两种持久化方式
经常有面试官会问：Redis数据存储在内存中，万一断电了怎么办呢？
不要慌，这个其实就是在问Redis的持久化策略啦。我们知道，保存在内存中的数据，在服务重启或者是机器挂掉之后是会丢失的。而硬盘中的数据是不会丢失的，因此只有将数据保存在硬盘上才相对安全些。
Redis为了追求高性能而将数据存在内存中，同时也提供了持久化的选项保证数据的安全性。这两种方式是：
- RDB快照持久化，就是将某一时刻的数据写入硬盘中
- AOF只追加文件的方式，就是将被执行的写命令追加到文件，并保存到硬盘里
1、RDB持久化方式
什么是RDB持久化呢？
也叫快照持久化，就是将当前Redis数据库中的数据快照保存一份到磁盘文件中（一般叫dump.rdb）。好了，这个时候如果断电了，没事啊，重启后，Redis通过加载rdb文件可以将数据库状态恢复。基本上算是，满血复活了（因为存在数据丢失问题，血不是很满！）
RDB 功能最核心的是 rdbSave 和 rdbLoad 两个函数， 前者用于生成 RDB 文件到磁盘， 而后者则用于将 RDB 文件中的数据重新载入到内存中
看图说话：
怎么实现RDB的持久化呢？
SAVE 和 BGSAVE两个命令来实现RDB持久化，这两个命令都会调用 rdbSave 函数，将数据保存在rdb文件中。但是有所区别：
- SAVE命令会直接调用rdbSave函数，阻塞Redis主进程，在保存完成之前，Redis不再响应其他任何客户端命令。
- BGSAVE命令fork出一个子进程，子进程调用rdbSave函数，这样Redis主进程可以继续处理客户端请求。
一般我们怎么配置RDB持久化呢？
这里我们可以通过修改redis.conf配置文件中关于RDB持久化的选项让Redis自动去执行持久化。比如下面这些选项：
# 900s之内有1次写入
save 900 1
# 300s内有10次写入
save 300 10
# 60s内有10000次写入
save 60 10000
#执行bgsave失败时是否继续执行写命令，默认是yes
stop-writes-on-bgsave-error yes
#是否对快照文件进行压缩，模式是yes
rdbcompression yes
#快照文件的名称，默认是dump.rdb
dbfilename dump.rdb
当配置了多个save选项时，当任意一个save配置项条件被满足时，Redis就会触发一次BGSAVE命令。
除了在redis.conf配置文件中配置rdb持久化之外，还有一些方式，可以创建快照：
- 通过直接在redis客户端敲save或bgsave命令的方式触发一次快照持久化
- 通过shutdown命令关闭服务器时，会执行一个SAVE命令，阻塞所有客户端，并在SAVE命令执行完毕之后关闭服务器
前面说到，RDB丢失数据的问题，其实就是在两次同步数据之间，如果服务器发生崩溃，便会丢失掉这之间的数据。
2、AOF持久化方式
什么是AOF，就是appendonly file的缩写啦！
简单来说，AOF持久化就是将被执行的写命令追加到AOF文件的末尾，以此来记录数据发生的变化。在恢复数据时，只需要从头到尾重新执行一遍AOF文件所包含的所有命令即可。
那么，AOF持久化有哪些配置项呢？
# 是否使用appendonly模式，默认是no
appendonly no
# appendfilename文件名
appendfilename "appendonly.aof"
# appendfsync always //每个命令都同步
appendfsync everysec //没秒执行一次同步，默认是这个
# appendfsync no //操作系统决定何时进行同步
# 在对aof文件进行压缩的时候能否执行同步
no-appendfsync-on-rewrite no
AOF方式的持久化有个缺点，就是文件的体积比较大。
Redis为了缓解这个问题，给我们提供了BGREWRITEAOF的命令，这个命令会通过移除AOF文件中的一些冗余命令来重写AOF文件，使得AOF文件的体积尽可能地缩小。类比BGSAVE命令，这里的BGREWRITEAOF命令也是fork出一个子进程进行AOF文件的压缩（也就是重写）工作。
同样地，我们可以在redis.conf配置文件中配置AOF文件的重写选项，让Redis自动执行BGREWRITEAOF
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
这两个配置的意思就是，当AOF文件的体积大于64MB，
并且AOF文件的体积比上一次重写之后的体积大了至少一倍（100%）时，
Redis将执行AOF文件的重写命令。
Redis的主从复制
单机版Redis实例存在的问题
- 首先是数据安全性问题，毕竟所有数据在一台机器上，万一这台机器被炸毁了，岂不是没救了。因此，需要多机器备份数据出来，Redis主从复制特性帮助我们实现数据的热备份。
- 第二个就是性能问题了，尤其是在处理一些较复杂命令和较大数据集合的操作时，每秒处理的请求数会下降不少。
什么是主从复制
就是将一台Redis服务器的数据，复制到另外一台或几台Redis服务器上。前者就是主服务器，后者就是从服务器。主服务器负责处理客户端的读写请求，而从服务器可以分担一部分读请求或者负责所有的读请求。
客户端每次向主服务器写入的命令，从服务器都能得到实时的更新。默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。
如何配置主从复制
配置主从复制其实很简单，就一条命令 slaveof。配置主从复制，其实就是配置Redis的从服务器从哪台主服务器复制数据。主服务器不需要动的。
因此，我们可以修改从服务器的 redis.conf 文件，增加如下一行配置就行：
slaveof masterip port
除了配置文件的方式外，还可以在启动redis实例的时候 加入 --slaveof masterip port ，这样就会告诉redis实例从哪台机器和端口处复制数据。
也可以直接在redis客户端执行命令 slaveof masterip port，让服务器开始复制一个主服务器。
另外，如果要断开同主服务器的复制，可以使用下面命令：
slaveof no one
Redis主从复制的具体过程是怎样的
当从服务器连接主服务器时，主从服务器执行的大概操作如下图所示：
需要注意的是，从服务器在进行同步时，会清空自己的所有数据。
故障处理
服务器宕机之后，可能需要恢复数据，这时候会用到之前说的持久化到硬盘上的aof或是dump快照文件。Redis给我们提供了两个命令行工具，在系统故障之后，用来检查aof文件和快照文件的状态，并且在还有修复功能。
下面是这两个命令行程序：
redis-check-aof
redis-check-dump
下面举例一种故障的场景：
A是redis主服务器，B是从服务器。A机器故障暂无法修复。现将C机器上的redis服务作为主服务器替换上去。
具体的替换计划是这样的：
- 首先向B发送一个SAVE命令，让它创建一个最新的快照文件
- 接着将这个快照文件发送给机器C，并在机器C上面启动Redis
- 在机器B上执行slaveof 命令，让它将C机器作为主服务器
作者Info：
公众号：二营长的笔记
