高并发；高性能；高可用
单机Redis的风险与问题
问题1.机器故障 现象：硬盘故障，系统崩溃 本质：数据丢失，很可能对业务造成灾难性打击
问题2.容量瓶颈 现象：内存不足
为了避免单点服务器故障，准备多台服务器，互相连通。将数据复制多个副本保存在不同的服务器上，连接在一起，并保证数据是同步的。即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现Redis的高可用，即数据的冗余备份
主从复制/主从同步：将master中的数据即时有效的复制到slave中 特征：一个master可以拥有多个slave，一个slave只对应一个master
（主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主）
master：写数据；执行写操作时，将出现变化的数据自动同步到slave； 读数据（可忽略） slave：读数据；写数据（禁止）
作用：读写分离，提高服务器的读写负载能力 负载均衡 故障恢复 数据冗余 高可用 容灾恢复
Redis主从同步的优点：
1、Master可以有多个Slave
2、多个Slave连接到相同Master，Slave还可以连接其他Slave形成图形结构
3、不会阻塞Master。当一个或多个Slave与Master进行初次同步数据时，Master可以继续处理客户端的请求。相反，Slave在初次同步数据时会阻塞从而不能处理客户端的请求（2.2版本后不再阻塞）
4、主从同步用来提高系统的伸缩性，比如多个Slave专门用于客户端的读请求
5、在Master服务器上禁止数据持久化（注释配置文件中所有save配置选项），只在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当前的数据库状态
slave服务器主动发送SYNC命令到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是否在线
主从复制常见问题：
频繁的全量复制：
1.伴随着系统的运行，master的数据量会越来越大，一旦master重启，runid将发生变化，会导致全部slave的全量复制操作
内部优化方案：（1）master内部创建master_replid变量，使用runid相同的策略生成，长度41位，并发送给所有slave；
（2）在master关闭时执行命令shutdown save，进行RDB持久化，将runid与offset保存到RDB文件中：
repl-id repl-offset
通过redis-check-rdb命令可以查看该信息
（3）master重启后加载RDB文件，恢复数据：
重启后，将RDB文件中保存的repl-id与repl-offset加载到内存中
master_repl_id = repl master_repl_offset = repl_offset
通过info命令可以查看该信息
作用：本机保存上次runid，重启后恢复该值，使所有slave认为还是之前的master
2.问题现象：网络环境不佳，出现网络中断，slave不提供服务
问题原因：复制缓冲区过小，断网后的slave的offset越界，触发全量复制
最终结果：slave反复进行全量复制
解决方案：修改复制缓冲区大小
频繁的网络中断
数据不一致
哨兵模式：sentinel.conf
哨兵是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master
哨兵的作用：主从切换
监控：不断地检查master和slave是否正常运行
通知（提醒）：当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知
自动故障转移：断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址
注意：哨兵也是一台Redis服务器，只是不提供数据服务；通常哨兵配置数量为单数
是什么-->反客为主的自动版，能够从后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
怎么用-->自定义的/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机器数量的增加也会使这个问题更加严重
原理：
阶段一：监控阶段
用于同步各个节点的状态信息：获取各个sentine的状态（是否在线）
获取master的状态：master属性-->runid role：master
各个slave的详细信息
获取所有slave的状态（根据master中的slave信息）
slave属性：runid role：slave master_host、master_port offset
总结：
监控-->同步信息
通知-->保持联通
故障转移-->发现问题；竞选负责人；优选新master；新master上任，其他slave切换master，原master作为slave故障回复后连接