目录
为什么要有集群
单个Redis存在不稳定性，当Redis服务宕机或硬盘故障，系统崩溃之后，就没有可用的服务了，还会造成数据的丢失
单个Redis的读写能力也是有限的
还由于互联网的三高架构，高并发，高性能，高可用
概念
通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定，高效的状态
三种模式
- 主从模式
- 哨兵模式
- Cluster模式
主从模式
为什么要用主从复制
单机redis的风险与问题
问题一：机器故障
- 硬盘故障，系统崩溃
- 本质：数据丢失，可能对业务造成灾难性打击
问题二：容量瓶颈
- 内存不足，一台redis内存是有限的
解决方案：
为了避免单点Redis服务器故障，准备多台服务器，互相联通，将数据复制多个副本保存在不同服务器上，连接在一起，并保证数据是同步的，即使有其中一台服务器宕机，其他服务器依然可以继续提供服务，实现Redis的高可用，同时实现数据冗余备份
特征
- 一个master可以拥有多个slave，一个slave只对应一个master
- 主从复制即将master中的数据及时，有效的复制到slave中
职责
master
- 写数据
- 执行写操作时，将出现变化的数据自动同步到slave
slave： - 读数据，禁止写数据
作用
- 读写分离：master写，slave度，提高服务器的读写负载能力
- 负载均衡：基于主从结构，配合读写分离，由slave分担master负载，并根据需求的变化，改变slave的数据，通过多个结点分担数据读取负载，大大提高Redis服务器并发量与数据吞吐量
- 故障恢复：当master出现问题时，由slave提供服务，实现快速的故障恢复
- 数据冗余：实现数据热备份，是持久化之外的一种数据冗余方式
- 高可用基石：基于主从复制，构建哨兵模式与集群，实现Redis的高可用方案
工作流程
分三个阶段
- 建立连接阶段-建立slave到master的连接，使master能够识别slave，并保存slave端口号
- 数据同步阶段-在slave初次连接master后，复制master中的所有数据到slave
- 命令传播阶段-当master数据库状态被修改后，导致主从服务器数据库状态不一致，此时需要让主从数据同步到一致的 状态
建立连接阶段
数据同步阶段
要想了解这一阶段，先了解这几个知识点：复制缓冲区
复制缓冲区
复制缓冲区，又名复制积压缓冲区，是一个先进先出的队列，用于存储服务器执行过的命令，每次传播命令，master都会将传播的命令记录下来，并存储在复制缓冲区
工作原理
组成：
- 偏移量（offset），用来记录已发送的信息对应的偏移量,作为下次发送信息的座标依据
- 字节值，存放的用户的操作命令
原理：
通过偏移量区分不同的slave当前数据传播的差异（每个slave可能接受到master的命令的数量还不一样）
总结
复制缓冲区存的是全量复制之后的用户的一些操作，因为rdb不是实时的，需要有一个地方存储在全量复制更新期间，用户的一些操作命令，全量复制之后，这些命令都会发到slave，但不是一次性全发过去，而是有一定的规则去发，分好几次发送，每次都会记录命令发到了哪个位置，下回发送就从这个地方发送
注意事项
- 如果master数据量巨大，数据同步阶段应避开流量高峰期，避免造成master阻塞，影响业务正常执行
- 复制缓冲区大小设定不合理，会导致数据溢出。如进行全量复制周期太长，进行部分复制时发现数据已经存在丢失的清空，必须进行第二次全量复制
- master单机内存占用主机内存的比例不应过大，建议使用50%-70%的内存，留下30%-50%的内存用于执行bgsave命令和创建复制缓冲区
命令传播阶段
要想了解这一阶段，先了解这几个知识点：复制缓冲区、服务器运行ID、心跳机制
服务器运行ID
服务器运行ID是每一台服务器每次运行的身份识别码，一台服务器多次运行可以生成多个运行id
组成：运行id由40位字符组成，是一个随机的十六进制字符 例如：fdc9ff13b9bbaab28db42b3d50f852bb5e3fcdce
作用：运行id被用于在服务器间进行传输，识别身份 如果想两次操作均对同一台服务器进行，必须每次操作携带对应的运行id，用于对方识别
实现方式：运行id在每台服务器启动时自动生成的，master在首次连接slave时，会将自己的运行ID发 送给slave，slave保存此ID，通过info Server命令，可以查看节点的runid
心跳机制
进入命令传播阶段候，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是否在线
常见问题
- master数据巨大的时候，一旦master重启，runid将会发生变化，会导致全部的slave的全量复制操作
- 复制缓冲区过小，断网后slave的offset越界，触发全量复制
总结
- 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库
- 从数据库一般都是只读的，并且接收主数据库同步过来的数据
- 一个master可以拥有多个slave，但是一个slave只能对应一个master
- slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来
- master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务
- master挂了以后，不会在slave节点中重新选一个master，只能手动的一个一个改，不合适，就有了之后的哨兵
哨兵模式
哨兵（sentinel）是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master
为什么有哨兵
主机宕机，如何能够高可用的恢复正常，不用人为进行干预
作用
- 监控
- 不断地检查master和slave是否正常运行
- master存活检测，master与slave运行清空检测
- 通知（提醒）
- 当被监控地服务器出现问题时，向其他（哨兵、客户端）发送通知
- 自动故障转移
- 断开master与slave连接，选取一个slave作为master，将其他slave连接到新地master，并告知客户端新地服务器地址
注意：
- 哨兵也是一台redis服务器，只是不提供数据服务
- 通常哨兵配置数量为单数
Cluster
redis最开始使用主从模式做集群，若master宕机需要手动配置slave转为master；后来为了高可用提出来哨兵模式，该模式下有一个哨兵监视master和slave，若master宕机可自动将slave转为master，但它也有一个问题，就是不能动态扩充，哨兵模式还是只有一个master；所以在3.x提出cluster集群模式。
redis cluster在设计的时候，就考虑到了去中心化，去中间件，也就是说，集群中的每个节点都是平等的关系，都是对等的，每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接，而且这些连接保持活跃，这样就保证了我们只需要连接集群中的任意一个节点，就可以获取到其他节点的数据。
那么redis 是如何合理分配这些节点和数据的呢？
Redis 集群没有并使用传统的一致性哈希来分配数据，而是采用另外一种叫做哈希槽 (hash slot)的方式来分配的。redis cluster 默认分配了 16384 个slot，当我们set一个key 时，会用CRC16算法来取模得到所属的slot，然后将这个key 分到哈希槽区间的节点上，具体算法就是：CRC16(key) % 16384。
在redis-cluster架构中，redis-master节点一般用于接收读写，而redis-slave节点则一般只用于备份，其与对应的master拥有相同的slot集合，若某个redis-master意外失效，则再将其对应的slave进行升级为临时redis-master。