为什么目录中有集群的概念？ 为什么有三种模式主从模式？ 主从复制特征角色工作流为什么存在连接阶段数据同步阶段复制缓冲区注意事项命令传播阶段服务器执行ID心跳机制常见问题解答哨兵模式？ 哨兵角色集群
为什么需要集群
单个Redis具有不稳定性，如果Redis服务关闭或硬盘出现故障，导致系统崩溃，则没有可用的服务，并且可能会丢失数据
单个Redis的读写能力也有限
由于互联网的三高架构、高并发性、高性能、高可用性
概念是通过增加服务的数量和提供相同的服务，使服务处于稳定和高效的状态
三种模式主从模式哨兵模式Cluster模式主从模式
用主从机复制独立redis的风险与问题
问题1 :机器故障
硬盘故障、系统崩溃的本质：可能会丢失数据，严重影响业务的问题2 :容量瓶颈
内存不足。 redis内存是有限的解决方案。
要避免单个Redis服务器出现故障，请准备多台服务器，并相互连接，复制数据以将多个副本存储在不同的服务器上，然后连接以确保数据同步。 如果其中一台服务器停机，其他服务器将继续提供服务，以实现数据冗馀备份，同时实现Redis的高可用性
特点一个主机可以有多个slave，一个slave只需对应一个主从机进行复制，即可及时、有效地将主机中的数据复制到slave中的职责主机
写入数据时，更改的数据会自动同步到slave
slave :禁止读写数据的作用读写分离： master写，slave度，提高服务器读写负荷能力负荷分散：基于主从结构，配合读写分离，slave分担master负荷，应对需求变化通过多个节点分担数据读取负载大幅提高Redis服务器并发量和数据吞吐量故障恢复：如果主机出现问题，slave提供服务，提供快速故障恢复数据冗余：实现数据热备份基于主从复制构建哨兵模式和集群，实现Redis高可用性方案工作流分为三个阶段
建立连接阶段-建立与主服务器的slave连接，使主服务器识别slave并保存slave端口号的数据同步阶段-在首次连接到主服务器后， 将所有主机数据复制到slave命令的传播阶段-主机数据库状态更改后，主从服务器上的数据库状态会不一致，需要维护主从数据
数据同步阶段要理解此阶段，请先了解复制缓冲区这一知识点
复制缓冲区复制缓冲区，又名复制积压缓冲区，是一个先入先出的队列，用于存储服务器执行的命令。每次传播命令时，主服务器都会记录传播的命令并将其存储在复制缓冲区中
工作原理
配置：
偏移是记录所发送的消息的偏移、并基于字节值作为下一发送的消息的坐标存储的用户操作指令
原理：
通过偏移来区分slave当前数据传播的差异。 每个slave master接受的命令数量不同。
总结
复制缓冲区存储全部复制后的用户操作。 rdb不是实时的，所以在全部复制更新期间需要存储用户操作命令的位置。 全部复制后，这些命令发送到slave，但不是一次全部发送，而是有一定的规则多次发送，每次都记录命令发送到了哪个位置，下次发送从那里发送
注意如果主数据量很大，数据同步阶段将避开通信高峰，以避免主数据被阻止或影响业务正常运行的复制缓冲区大小设置不当导致数据溢出如果完整卷复制周期太长，在进行部分复制时发现数据已经丢失，则第二次完整卷复制主节点的单元内存占主机内存的比例不能太大。 要了解使用50%-70%内存和保留30%-50%内存执行bgsave命令和创建复制缓冲区命令的传播阶段，必须首先了解这些知识点。 必须了解复制缓冲区、复制缓冲区命令的传播阶段
服务器运行ID服务器运行ID是各服务器每次运行的ID，通过一台服务器多次运行可以生成多个运行ID
配置：执行id由40位字符组成，是随机的十六进制字符。 例如，FDC9ff 13 B9 bbaab 28 db42 b3d 50 f 852 bb5E3 fcd ce
角色：操作id用于服务器之间的传输。 为了识别身份，如果想在同一台服务器上执行两次操作，则每次操作都需要携带对应的操作id，用于识别对方
如何实现：在每个服务器启动时自动生成运行id。 master在第一次连接slave时，会将自己的执行id发送给slave。 slave会保存此id，并允许info Server命令查看节点的runid
心跳机制进入命令传播阶段，主机与slave之间需要进行信息交换，使用心跳机制进行维护，维持双方的连接
主心跳：
命令： 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只能对应一个masterslave挂了不影响其他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服务器，只是不提供数据服务通常哨兵配置数量为单数工作原理博客
Clusterredis最开始使用主从模式做集群，若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集合，pgch个redis-master意外失效，则再将其对应的slave进行升级为临时redis-master。
redis-cluster集群详细博客1
redis-cluster集群详细博客2