10、Redis持久化之RDB(Redis DataBase)
10.1、什么是RBD
在指定时间间隔内将内存中的数据集写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。在整个过程中，主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那么RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化数据可能丢失。
10.2、什么是Fork
Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据都可原进程一致，但是是一个全新的进程，并作为原进程的子进程。
10.3、dump.rdb
1、rdb保存的是dump.rdb文件
2、在redis.conf配置中关于rbd的配置
rbd是时间间隔内将数据集写入磁盘，可以在这里配置相关触发条件。
默认触发条件：
- 一分钟内改了1万次
- 5分钟内改了10次
- 15分钟内改了1次
如果想禁用RDB的持久化策略，只要不设置任何save指令，或者给save传入一个空字符串参数也可以。
其余命令解析
Stop-writes-on-bgsave-error：当Redis无法写入磁盘的话，直接关掉redis的写操作。推荐yes
rbdcompression：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用 LZF算法进行压缩，如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能。
rdbchecksum：在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约 10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。默认为yes。
如何触发RDB快照
1、save命令或者bgsave命令
- save只管保存，其他不管，全部阻塞
- bgsave，Redis会在后台异步进行快照操作，快照同时还可以相应客户端请求。可以通过lastsave命令获取左后一次成功执行快照的时间。
2、执行flushall命令的时候，也会触发dump.rdb文件，因为需要将里面的内容清空
3、shutdown退出的时候也会触发dump.rbd文件
rdb的备份
1、复制一份
2、将备份文件移动到redis安装目录并启动即可
127.0.0.1:6379> config get dir dir /usr/local/bin
优缺点
优点：
- 适合大规模的数据恢复
- 对数据完整性和一致性要求不高
缺点：
- 在一定间隔内做一次备份，如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
- Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。
小结
11、Redis持久化之AOF(Append Only File)
11.1、是什么
以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
aop保存的是appendonly.aof文件
11.2、配置部分
appendonly no # 是否以append only模式作为持久化方式，默认使用的是rdb方式持久化，这种方式在许多应用中已经足够用了 appendfilename "appendonly.aof" # appendfilename AOF 文件名称 appendfsync everysec # appendfsync aof持久化策略的配置 # no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。 # always表示每次写入都执行fsync，以保证数据同步到磁盘。 # everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。 No-appendfsync-on-rewrite #重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性 Auto-aof-rewrite-min-size 64mb # 设置重写的基准值 Auto-aof-rewrite-percentage 100 #设置重写的基准值 # 以上两个，表示重写触发机制是大于64mb的100%也就是128mb触发
11.3、AOF数据恢复
正常恢复：
- appendonly no 改为yes
- 将有数据的aof进行复制一份保存到对应目录(config get dir)
- 重启即可
异常恢复：
- appendonly no 设置yes
redis-check-aof --fix appendonly.aof进行修复- 重启redis然后重新加载
11.4、Rewrite
是什么：
AOF 采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当AOF文件的大小 超过所设定的阈值时，Redis 就会启动AOF 文件的内容压缩，只保留可以恢复数据的最小指令集，可以 使用命令 bgrewriteaof ！
重写原理：
AOF 文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再 rename），遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧 的aof文件，这点和快照有点类似！
触发机制：
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件是上次rewrite后大小的一倍且文件大 于64M的触发。
AOF持久化流程
1、客户端的请求写命令会被append追加到AOF缓冲区内；
2、AOF缓冲区根据AOF持久化策略【always,everysec,no】将操作sync同步到磁盘的AOF文件中；
3、AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
11.5、优缺点
优点：
1、每修改同步：appendfsync always 同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差 但数据完整性比较好
2、每秒同步： appendfsync everysec 异步操作，每秒记录 ，如果一秒内宕机，有数据丢失
3、不同步： appendfsync no 从不同步
缺点：
1、相同数据集的数据而言，aof 文件要远大于 rdb文件，恢复速度慢于 rdb。
2、Aof 运行效率要慢于 rdb，每秒同步策略效率较好，不同步效率和rdb相同。
小结
12、Redis主从复制
12.1、概念
主从复制，是指将一台Redis服务器的数据，复制到其他的Redsi服务器。前者称为主节点(master/leader),后者称为从节点(slave/follower);数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave以读为主。
默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点),但一个从节点只能有一个主节点。
主从复制的作用主要包括：
1、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复。
3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务，分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大地提高redis服务器的并发量。
4、高可用：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是redis高可用的基础。
一般来说，要将Redis运用于工程项目中，只使用一台Redis是万万不能的，原因如下：
1、从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较 大；
2、从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有 内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。 电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是"多读少写"。 对于这种场景，我们可以使如下这种架构：
12.2、主从复制配置
1、新建一个文件夹，把redis.conf文件copy一份放进去
[root@VM-4-12-centos /]# mkdir myredis [root@VM-4-12-centos /]# cd myredis [root@VM-4-12-centos myredis]# cp /usr/local/bin/redis.conf /myredis/redis.conf
2、配置一主两从，需要创建三个配置文件
- redis6380.conf（主）
- redis6381.conf（从）
- redis6382.conf（从）
3、在三个配置中写入配置
# 第一个配置文件内容 include /myredis/redis.conf pidfile /var/run/redis_6380.pid port 6380 dbfilename dump6380.rdb
# 第二个配置文件内容 include /myredis/redis.conf pidfile /var/run/redis_6381.pid port 6381 dbfilename dump6381.rdb
# 第一个配置文件内容 include /myredis/redis.conf pidfile /var/run/redis_6382.pid port 6382 dbfilename dump6382.rdb
现在目录下面已经有刚才建立的三个配置文件了
4、启动三台服务器
5、查看三台主机运行状况
info replication
我们会发现三台主机的运行情况都是一样的，没有主机丛机的概念。这就需要我们有一些配置。
6、配从(从库)不配主(主库)
slaveof <ip><port> (成为某个实例的从服务器)
1、在6381和6382上执行：slaveof 127.0.0.1 6380,然后重新查看主机运行状况
7、测试效果(在主机上进行写操作，在从机上读取)
注意：从机中不能做写操作，只能做读操作。
12.3、常用三招
12.3.1、一主二仆
**问题一：**在一主二仆的情况下，如果其中一个从机down掉，在主机里面添加新数据，当down掉的主机重新启动的话，是否还是从机？down掉的过程中如果主机又添加新数据，重新启动后是否可以复制？
实验：
1、现在主机里面有一个key，然后我们将6382从机shutdown掉，然后查看主机运行信息。
2、在主机里面新添加几个key,然后重新启动6382
3、我们会发现从机重新启动后变成了主机，我们继续手动把它变回从机
slaveof ip port
总结：
- 从机down掉再重新连接会自动变回主机
- 从机down掉再变回从机会从头开始复制主机的数据。
**问题二：**当主机down掉，从机该何去何从？
实验：
1、将主服务器给shutdown，然后查看从服务器的运行信息
**发现：**主机down掉后，从机知道主机down掉，不做任何事情，之前数据仍然保留
2、将主服务器重新启动，然后查看主服务器的信息
**发现：**主机down掉再重新启动仍然是主机，主仆关系没有发生改变
12.3.2、薪火相传
简单来说就是一个主机下面有一个从机，而这个从机也可以作为主机下面继续跟一个从机。这样的层层链路，可以减轻master的写压力
演示：将6381作为中间链路
如图：6380的从机是6381，而6381的从机是6382，
6380设置的值6381和6382都可以获取得到
12.3.3、反客为主
当一个master宕机后，后面的slave可以立刻升为master，其后面的slave不用做任何修改。
12.4、复制原理
Slave启动成功连接到master后会发送一个sync命令
Master接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步。
但是只要是重新连接master，一次完全同步(全量复制)将被自动执行。
12.5、哨兵模式
概述
反客为主的自动版,能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
原理
哨兵通过发送命令，等待Redis服务器的响应，从而监控运行的多个Redis实例。
配置测试
1、重新调整为6380为主，下面带着6381和6382
2、自定义的/myredis目录下新建sentinel.conf文件，名字千万不要错
3、配置哨兵，填写内容
sentinel monitor mymaster 127.0.0.1 6379 1- 其中mymaster为监控对象起的服务器名称，1 ：至少有多少个哨兵同一迁移的数量
4、启动哨兵
redis-sentinel sentinel.conf
5、正常主从演示
6、down掉主机也就是6380
7、查看6381主机运行情况
8、重启之前的主机进行观察
9、可以设置从服务器的优先级
在redis.conf文件中：默认： slave-priority 100 ，值越小优先级越高
优缺点
优点：
1、主从可以切换，故障可以转移，系统可用性好
2、哨兵模式是主从模式的升级，更健壮、可用
缺点：
1、配置繁琐
2、复制延时，在master上写然后同步，当系统很繁忙的时候，这个问题更加严重。
