总结：Redis的集群都是基于复制模式
注意⚠️：接下来的内容为纯文字表述，阅读时间大概为1min，大多数为概念内容。
主从模式：
优先解决单点故障，若有多余资源可做读写分离
结构类型：
一主一从
一主多从
问题： 从节点过多，数据同步消耗时间
树状
通信机制
通信流程主要分为以下五个步骤：
主从节点建立socket连接
使用ping命令检查socket是否连接成功
权限校验
异步做数据同步
命令行数据同步
数据同步
主从模式中数据同步都是采用异步完成操作。
建立主从关系；
从节点 -> 主节点：发送同步请求 psync 运行id -1
主机点 -> 从节点：发送“FULLRESYNC 运行id 偏移量”
主节点：通过bgsave生成RDB文件
主机点 -> 从节点：发送RDB文件
从节点：读取RDB文件，删除旧数据，写入新数据
主节点：同步过程中，新的写入数据保存到客户端缓冲区中
主节点 -> 从节点：从节点完成数据同步后，将缓冲区内容交给从节点继续写入
从节点：若开启AOF，做数据重新写入操作
从节点拿到RDB文件后采取以下两种方案做写入：
全量复制
：建立连接后从节点首次同步数据采取的方案，但是随着主节点保存的数据增大达到G级别，
容易在写时出现网络波动导致失败，或者写时超时，导致失败，让从节点放弃此次写入。
部分复制
提供了全量复制中出现超时或中断等情况的解决方案
主从恢复连接，从节点向主节点发送同步请求（包括主节点运行id，偏移量），
主节点拿到偏移量判断后面数据在积压缓冲区中还是文件中，积压缓冲区直接返回，文件中继续走全量同步
存在的问题
需要保证主节点的存活度，否则主节点失效后，需要手动做主从切换
额外操作
主节点不做持久化，交给从节点完成
虽然从节点做持久化，能减轻主节点的压力，但需要保证主节点维持高存活，降低死亡概率。因为主节点未做持久化，主节点宕机后无法保存数据，恢复连接后内存中的数据也为null，所以从节点恢复连接后将同步主机点中的null数据，造成数据丢失。
哨兵
🎈为了减少主从模式中，人工干预，提高可用性，自动完成主从切换。
通信模式：
找下属（节点发现）
机制：sentinel每10s向所有数据节点发送一次info请求，获取每个节点信息。
黑森林法则（监听他人）：
机制：sentinel每2s向主节点push一次自己的信息。主节点中保存了所有做了连接的节点信息，且所有sentinel通过订阅（subscribe）主节点完成其他sentinel节点的发现。
动员（检活）
机制：sentinel每1s向所有节点发送ping命令，判断节点存活情况
节点下线
sentinel通过ping命令，能及时发现存在问题的节点，将判断分为“主观下线”与“客观下线”。
主观下线
判断依据：sentinel每s向节点发送ping命令，当超过时间未响应时，认为该节点下线。
但是主观下线可能因为网络波动而造成长时间未响应，所以不能作为故障转移依据。
女：我和你妈同时掉水里了，你先救谁
男：...
女：你不爱我了，分手吧
男：...
客观下线
判断依据：一个sentinel做了主观下线判断，再通知其他sentinel做联合判断，当超过n/2+1个sentinel肯定后，为客观下线。
判断成功标识：多数认为下线，且大多数判断时的总时间未超过设置的总时间，即为成功。超过时间后等待下一轮。
女：我和你妈同时掉水里了，你先救谁
男：问问你妈
女：你不爱我了，分手吧
男：问问你爸
选举过程
完成了下线判断后，若主节点失活，将进行新节点的选举。
配置文件中配置了指定的节点做新的主节点时，将指定节点提升为主节点
那个从节点同步内容的偏移量越大，将该节点提升为主节点。
最后判断节点的runid，runid越小，该节点月早启动，同步的数据更多。
故障转移
通过sentinel节点，对指定从节点执行slaveof no one；在将其他节点做主节点迁移，slaveof host port；最后故障的节点启动后，将成文从节点
主从中存在的问题
主从中只能大致满足故障转移操作，数据依然存在一个主节点上，无法做水平分片。
主从中，为了保证数据的单向流动，从节点默认关闭了写入操作，方式出现主从不一致问题。并且默认不支持读写分离操作
