前言
我们都知道Redis是基于内存级别的操作，他的速度非常快，但是这样也带来了弊端。就是当Redis宕机了之后会给业务带来很大的影响，即使有RBD或AOF的持久化机制，也并不能满足我们的要求。因此有了高可用集群方案。
高可用集群的优劣
👍 优点：
- 读写分离
- 负载均衡s
- 提高吞吐量
- 增强系统健壮性
👎 缺点：
- 需要花钱买机器
- 维护成本高，业务复杂
主从模式
主从模式是redis中最简单的集群结构，cluster集群中也会出现主从的影子
主从模式从以前的单机结构，扩展成了多个从节点，1个主节点的模式
主从同步机制
想要了解主从同步机制首先要知道几个前提知识：
runId：用来标识redis节点。每个redis节点启动都会生成唯一的uuid，每次redis重启后，runId都会发生变化
offset：复制偏移量。当主节点有写入命令时，offset = offset + 命令的字节长度从节点在接收到主节点发送的命令后，也会增加自己的offset，并且把自己的offset发送给主节点；主节点既保存自己的offset ，也会保存从节点的offset，通过对比offset来判断主从节点数据是否一致
repl_backlog_size：写命令缓冲区大小。保存在主节点上的一个固定长度的先进先出队列，默认大小时1MB
流程：
从节点向主节点发送一个psync命令（在高版本redis才是psycn，低版本是sync）来告诉主节点，”我要同步你的数据啦“，并且里面携带了自己的offset和runId。用来告诉主节点，《我是谁》，《当前我同步了多少数据》
在第一次进行主从同步的时候，offset是-1，因为还没有同步，因此主节点会将从节点的offset保存一份放到自己里面，同时也维护一份自己主节点的offset。
由于是第一次进行同步，所以进行全量复制，除了全量同步，还有增量复制。
全量复制
第一次进行同步的时候，都是全量同步，因为这样能保证数据的完整性。
具体的操作是主节点通过RBD的bgsave方式，拷贝一份自己的dump文件，然后扔给从节点，让从节点自己同步
增量复制
增量同步的意思就是进行局部的数据拷贝即可。
具体操作：当有主节点接收到客户端的写命令，产生数据变化时，命令会被存在主节点的写入缓冲区中，当执行增量复制的时候，会把写入缓冲区的指令传给从节点，进行增量复制
如何全量复制或增量复制
第一次同步，都是采用全量复制
不是第一次同步的话，会首先尝试增量复制，通过offset来判断，从节点进行增量同步后offset是否还在可维护的范围之中，如果可以则进行增量复制，否则还是走全量复制
读写分离
在主从模式中，只有主节点Master能够进行读和写的操作，其他从节点只能负责读操作。在实际业务中，往往读操作会大于写操作，因此能很好地做到缓解读数据的压力，起到一个负载均衡的效果。
带来的问题
如果我们的master宕机，此时redis集群中，群龙无首，大哥倒了，其他小弟怎么办？
最直观的想法，就是选一个小弟slave来当大哥master，因此我们需要有一个机制，能够让我们知道大哥master什么时候宕机，出现故障了，好让小弟们slave能够及时去顶替大哥的位置。因此有了哨兵模式
哨兵模式
哨兵的作用就是去监控各个节点的运行状态，一旦发现某个节点下线了，会主观地认为这个redis服务主观下线，造成节点下线的原因可能有网络原因或是接收不到订阅
主观下线
主观下线是指单个哨兵认为某个节点无法工作，会主观性地认为这个节点出现故障。此时这个哨兵会去跟其他哨兵进行交流来判断，这个服务是不是真的出现故障了
客观下线
当多个哨兵都认为这个节点主观下线，达到一定数量（用户可以设置）的认同意见之后，则这个节点会被判断为客观下线，此节点将被真正意义上的歇逼。如果该节点好巧不巧是master节点，则会触发触发故障迁移
故障迁移
当某个master服务被认为客观下线后，哨兵们会选举（其实是退让制）出某个slave来成为新的master
选举的策略：
- 优先选择slave-priority（slave节点优先级）最高的
- offset最大的 （数据最完整）
- runId最小的（启动时间最早的）
Cluster集群
Cluster集群是一种采用的是一种分片（sharding）思想的去中心化的技术，客户端只需要与集群中的任意节点连接即可。
通过哈希的方式，将数据进行分片，每一个节点均分布存储一定哈希槽（slot），分配了0-16383号槽位，一共2^12（16384个）方个槽。
每一个redis节点存储的是部分数据，并不是全部数据，这个是最直观的区别
因此我们在新增redis节点的时候，只需要从各个已有节点拿去一部分数据，并且插入到对应范围的槽中即可
Cluster集群中结合主从模式、哨兵模式
为了保证数据的高可用性，Cluster也可以加入主从模式，一个主节点对应多个从节点，主节点负责提供数据存储，从节点则从主节点那里拉去数据，进行备份
并且也可以加入哨兵集群进行故障监控并转移
👍 优点：
- 无中心架构，支持动态扩容，对业务透明
- 具备Sentinel的监控和自动Failover（故障转移）
- 客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
- 高性能，客户端直连redis服务，免去了proxy代理的损耗
👎缺点：
- 运维复杂
- 只能使用0号数据库
- 不支持批量操作（pipeline管道）