Redis的主从复制 master-slave

高并发；高性能；高可用

单机Redis的风险与问题

问题1.机器故障    现象：硬盘故障，系统崩溃  本质：数据丢失，很可能对业务造成灾难性打击  

问题2.容量瓶颈    现象：内存不足

为了避免单点服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的。即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现Redis的高可用，即数据的冗余备份

主从复制：将master中的数据即时有效的复制到slave中      特征：一个master可以拥有多个slave，一个slave只对应一个master

（主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主）

master：写数据；        执行写操作时，将出现变化的数据自动同步到slave；    读数据（可忽略）   slave：读数据；写数据（禁止）

作用：读写分离，提高服务器的读写负载能力  负载均衡  故障恢复    数据冗余    高可用    容灾恢复

怎么用：配从不配主：

　　从库配置：命令-->slaveof 主库IP 主库端口 --> 每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件；Info replication

　　修改配置文件细节操作：拷贝多个redis.conf文件；开启daemonize yes；Pid文件名字；指定端口；Loq文件名字；Dump.rdb名字

　　常用3招：一主二仆  薪火相传  反客为主

一主二备：（三角形）

读写分离，只有主机可写，从机只能读

主机宕掉，从机不动，主机恢复后，再更新数据，从机可以继续备份

从机宕掉，需重连

薪火相传：（链式）

反客为主：slaveof no one  使当前数据库停止与其他数据库的同步，转成主数据库

复制原理：Slave启动成功连接到master后会发送一个sync命令

　　Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步

　　全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中

　　增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步

　　但是只要是重新连接master，一次完全同步（全量复制）将被自动执行

主从复制三阶段：建立连接阶段-->数据同步阶段-->命令传播阶段

建立连接阶段：建立slave到master的连接，使master能够识别slave，并保存slave端口号    

　　　流程：

 方式：

1.slaveof  ip  port

2.redis-server  --slaveof masterip masterport

3.修改配置文件， slaveof  masterip masterport

主从断开连接：slaveof no one

授权访问：

master配置文件设置密码：requirepass  password

master客户端发送命令设置密码：config set requirepass password           config get requirepass

slave客户端发送命令设置密码：auth password

slave配置文件设置密码：masterauth  password

启动客户端设置密码：redis-cli  -a  password

数据同步阶段工作流程:在slave初次连接master后，复制master中的所有数据到slave

　　　　　　　　将slave的数据库状态更新成master当前的数据库状态

小结：

1.如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行

2.复制缓冲区大小设定不合理，会导致数据溢出。如果进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的情况，必须进行第二次全量复制，导致slave陷入死循环状态  repl-backlog-size 1mb

3.master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执行bgsave命令和创建复制缓冲区

slave

1.为避免slave进行全量复制、部分复制时服务器响应阻塞或数据不同步，建议关闭此期间的对外服务

slave-serve-stale-data yes|no

2.数据同步阶段，master发送给slave信息可以理解master是slave的一个客户端，主动向slave发送命令

3.多个slave同时对master请求数据同步，master发送的RDB文件增多，会对带宽造成巨大冲击，如果master带宽不足，因此数据同步需要根据业务需求，适量错峰

4.slave过多时，建议调整拓扑结构，由一主多从结构变为树状结构，中间的节点既是master，也是slave。注意使用树状结构时，由于层级深度，导致深度越高的slave与最顶层master间数据同步延迟较大，数据一致性变差，应谨慎选择。

命令传播阶段

当master数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致的状态，同步的动作称为命令传播

master将接收到的数据变更命令发送给slave，slave接受命令后执行命令

命令传播阶段的部分复制：

命令传播阶段出现了断网现象-->网络闪断闪连  忽略； 短时间网络中断  部分复制；长时间网络中断 全量复制

部分复制的三个核心要素：服务器的运行id(run id)；主服务器的复制积压缓冲区；主从服务器的复制偏移量

服务器运行ID:

复制缓冲区：是一个先进先出的队列，用于存储服务器执行过的命令，每次传播命令，master都会将传播的命令记录下来，并存储在复制缓冲区

主从服务器复制偏移量offset

概念：一个数字，描述复制缓冲区中的指令字节位置

分类：master复制偏移量-->记录发送给所有slave的指令字节对应的位置（多个）

slave复制偏移量-->记录slave接收master发送过来的指令字节对应的位置（一个）

 数据来源：master端-->发送一次记录一次 

　　　slave端-->接受一次记录一次

作用：同步信息，比对master与slave的差异，当slave断线后，恢复数据使用

数据同步+命令传播阶段工作流程

心跳机制

进入命令传播阶段后，master与slave间需要进行信息交换，使用心跳机制进行维护，实现双方连接保持在线

master心跳：指令-->Ping 

　　　　周期-->由repl-ping-slave-period决定，默认10秒

　　　　作用-->判断slave是否在线

　　　　查询-->info replication  获取slave最后一次连接时间间隔，lag项维持在0或1视为正常

slave心跳任务：指令-->REPLCONF ACK{offset}

　　　　　　周期-->1秒

　　　　　　作用1：汇报slave自己的复制偏移量，获取最新的数据变更指令

　　　　　　作用2：判断master是否在线

主从复制常见问题：

频繁的全量复制：记录从机的id和offset；复制缓冲区过小

哨兵模式：sentinel.conf

是什么-->反客为主的自动版，能够从后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库

怎么用-->自定义的/myredis目录下新建sentinel.conf文件

　　配置哨兵，填写内容：sentinel monitor被监控数据库名字（自己起名字）127.0.0.1 6379 1    最后一个数字1，表示主机挂掉后slave投票看让谁接替成为主机，得票数多少后成为主机

　　启动哨兵：Redis-sentinel /usr/common/sentinel.conf  上述目录按照各自的实际情况配置，可能目录不同

　　　　　　主机宕掉之后，会投票选一个从机当作主机，主机重启后会成为新主机的从机

　　正常主从演示

　　原有的master挂了

　　投票新选

　　重新主从继续开工，info replication查查看　　

　　问题：如果之前的master重启回来，会不会双master冲突？

　　一组sentinel能同时监控多个Master

复制的缺点：由于所有的写操作都是先在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使这个问题更加严重