英协网一、redis的持久化
Redis的持久化是将内存的数据保存到硬盘，防止redis因进程重启导致的数据丢失。Redis有RDB和AOF两种持久化的方式。
1、redis RDB持久化
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB的方式有手动触发和自动触发。
（1）手动触发
命令：sava
bgsave
执行save命令时，会阻塞当前Redis服务器，直到RDB过程完成为止，对于内存较大的实例会造成长时间的阻塞。
执行bgsave命令时，redis进程会执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束，阻塞只发生在fork阶段。
（2）自动触发机制
在配置文件中使用如”save m n”，表示m秒内数据修改n次,自动触发bgsave。在执行”debug reload”命令重新加载redis，也会自动触发save操作，在执行”shutdown”命令时，没有开启AOF持久化也会自动执行bgsave。
# Redis中自动触发的配置如下 save 900 1 save 300 10 save 60 10000
（3）redis对rdb文件的处理
保存：保存在dir配置指定的目录下，文件名通过dbfilename配置指定。
压缩：默认采用LZF算法对生成的RDB文件做压缩处理
校验：redis加载损坏的RDB文件时拒绝启动，可使用”redis-check-dump”工具检测RDB文件并获取对应的错误报告。
（4）RDB的优缺点
优点：RDB是一个紧凑的二进制文件、代表redis在某个时间点上的数据快照。适用于备份、全量复制等场景。Redis加载RDB恢复数据远远快于AOF的方式。
缺点：RDB不能做到实时持久化；老版本redis无法兼容新版本RDB。
2、AOF持久化
AOF持久化以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF解决了数据持久化的实时性，目前已经是redis持久化的主流方式。
（1）配置使用AOF
使用AOF需要配置”appendonly yes”,默认不开启，AOF文件名通过”appendfilename”配置设置，默认文件名是” appendonly.aof”,保存路劲也是通过”dir”配置。
（2）AOF命令的写入
AOF命令写入的内容直接是文本格式。AOF写入时，先将数据追加到aof_buf中，再同步到硬盘。
文件同步：redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制，选项如下：
always:命令写入aof_buf后调用系统fsync操作同步到AOF文件，fsync 完成后线程返回。每次写入都要同步AOF文件，与redis高性能背道而驰。
no: 命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同 步，同步硬盘操作由操作系统负责，通常同步周期最长30秒。当配置为no时,提升了性能，但是数据安全性无法保证。
everysec:命令写入aof_buf后调用系统write操作，write完成后线程返回。Fsync同步文件操作命令由专门线程美妙调用一次。everysec为默认的同步策略，做到了兼顾性能和数据安全。为默认的值。
（3）AOF重写机制
AOF重写机制是把redis内存的数据转化为写命令同步到新的AOF文件的过程，以防止AOF文件的无限增大。
1）重写规则：
进程内已经超时的数据不再写入文件；写入时多条命令会合并为一条；旧的AOF文件中无效的命令不再写入
2）AOF重写触发机制
手动触发：使用bgrewriteaof命令
自动触发：根据”auto-aof-rewrite-min-size”和”auto-aof-rewrite-percentage”参数确定自动触发机制。
auto-aof-rewrite-min-size：表示AOF重写时文件最小体积，默认为60M
auto-aof-rewrite-percentage：代表当前AOF文件空间和上一次重写后AOF文件空间的比值。
3、持久化文件加载流程
（1）AOF持久化开启且存在AOF持久化文件时首先加载AOF文件
（2）AOF关闭或AOF持久化文件不存在时，加载RDB文件
（3）加载AOF/RDB文件成功后，redis启动成功
（4）AOF/RDB文件存在错误时，redis启动失败并打印错误日志。
二、redis的复制
Redis 的主从复制实现了相同数据的多个redis副本，复制功能是redis高可用的基础。
1、主从复制的建立与查看
（1）主从复制的建立
1）修改配置文件实现主从复制
在配置文件中加入”slaveof {masterHost} {masterPort}”
2）在redis启动时建立主从复制
在启动命令后面加入：–slaveof {masterHost} {masterPort}
# 在启动时建立主从复制 ~]# redis-server --slaveof 192.168.16.129 6379
3）通过命令建立主从复制
登录redis执行如下命令：slaveof {masterHost} {masterPort}
# 登录redis通过命令建立主从复制 127.0.0.1:6379> SLAVEOF 192.168.16,128 6379 OK
主从复制建立后，从节点默认使用”slave-read-only=yes”配置为只读模式，如果修改从节点的只读配置，会导致主从数据不一致。
（2）查看redis的的主从复制
命令：127.0.0.1:6379> info replication
127.0.0.1:6379> info replication # Replication role:slave master_host:192.168.16,128 master_port:6379
（3）主从复制断开
命令：SLAVEOF no one
# 断开当前redis的主从复制 127.0.0.1:6379> SLAVEOF no one OK
（4）主从复制中切主操作
命令：slave {newMasterIP} {newMmasterPort}
主从复制切主命令同建立主从复制的命令一样，切主后从节点会清空之前所有的数据。在生产生谨慎使用。
（5）主从复制安全性
为了提高复制的安全性，主节点会通过设置requirepass参数进行密码验证，这是所有的客户端访问必须使用auth命令进行校验。
（6）主从复制的传输延迟
配置选项：repl-disable-tcp-nodelay
当关闭时，主节点产生的命令及时的发送给从几点，这样会使主从延迟变小，会增加网络带宽的消耗。默认是关闭的。
当开启时，主节点会合并较小的TCP数据包以节省带宽，默认发送时间间隔取决于linux的内核，默认40毫秒，这种配置会节省带宽但会增大主从之间的延迟。
2、主从复制的过程
（1）保存主节点信息
（2）从节点内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建议网络连接。
（3）从节点发送ping命令请求进行首次通信，ping的目的包括检测主从之间网络套接字是否可用及检测主节点当前是否可以接受处理命令。发送ping命令后，从节点没有收到主节点的pong回复或者超时，从节点会断开复制连接，下次定时任务发起时从连。
（4）权限验证
（5）同步数据集，主从复制连接正常后，如果为首次复制，主节点会吧所有的数据全部发送给从节点
（6）命令持续复制
3、主从复制的方式
（1）全量复制
全量复制是redis最早支持的复制方式，也是主从第一次建立复制时必须经历的阶段。触发全量复制的命令是sync和psync。
（2）部分复制
部分复制时针对全量复制的过高开销做出的一种优化措施，使用psync {runid} {offset}命令实现。Runid为从节点所复制的主节点的运行ID，offset为当前从节点已复制的数据偏移量。
（3）异步复制
主从复制中写命令的发送过程是异步完成的；主节点自身处理完写命令后直接返回给客户端，并不等待从几点复制完成。
4、 主从复制状态的维护
主从复制建立后，主从节点都有心跳检测机制，各自模拟成对方的客户端进行通信；主节点默认每隔10秒对从节点发送ping命令，判断从节点的存活性和连接状态；从节点在主线程中每隔1秒发送”replconf ack {offset}”命令给主节点上报自身当前的复制偏移量。
