目录
1.CAP理论
2.Redis主从复制模型
1.什么是主从复制
2. 主从复制是异步还是同步的
3.主从复制的作用
4.主从复制的过程
3.Redis Sentinel 哨兵模式
1.什么是哨兵模式
2.哨兵模式架构
3.节点下线
4.Leader选举
5.为什么需要三个及以上的哨兵
4.Redis Cluster 集群
数据分区方案
1.哈希分区方案
2.一致性哈希分区方案
3.带虚拟节点的一致性哈希分区方案
1.CAP理论
CAP理论是现代分布式系统的基石，CAP理论指的是Consistency一致性、Availabe可用性、Partition Tolerance分区容忍性这三者中只可保证其二。例如在网络分区出现时，Redis主从节点之间无法进行通信，所以主从复制停止。若要保证一致性，那就必须停止对外提供服务，在后台进行数据的同步，这就造成了不可用；若要保证可用性，那么随着数据的改变，主从节点必然不一致，牺牲了一致性。
Redis能够保证在网络分区发生时的可用性以及最终一致性。
2.Redis主从复制模型
Redis的持久化是保证单机数据可用性问题，而主从复制是保证多机数据可用性问题，Redis的主从复制是Redis读写分离和集群存在的基础。子节点通过slaveof ip port即可成为该ip下port端口Redis服务器的子节点了，之后主节点的数据将会被从节点所同步。若子节点不想继续成为从节点，使用slaveof no one即可取消同步。
1.什么是主从复制
主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点。
默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。
2. 主从复制是异步还是同步的
Redis的主从复制是异步的，所以会存在一致性问题，但是Redis能保证最终一致性。在主从复制时，主节点才可写入数据，而不可在从节点写入数据，因为主节点不会同步从节点的数据。可以通过wait 1 0命令，即可保证同步复制，这个命令的意思是至少有一个从节点在正常同步，0表示超时时间不计，如果没有至少一个节点在同步，那么主节点会一直阻塞写，直至恢复正常。
3.主从复制的作用
- 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
- 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
- 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
- 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
4.主从复制的过程
- 连接建立阶段：在这一步建立主从Redis服务器之间的连接。
- 数据同步阶段：在这一步进行从服务器的初始化。【全量复制主服务器的RDB持久化文件】
- 命令传播阶段：在这一步进行主从服务器的同步。【心跳机制 + 增量复制】
3.Redis Sentinel 哨兵模式
1.什么是哨兵模式
哨兵模式指的是通过Redis Sentinel组件搭建的一个主从复制集群，客户端通过Sentinel连接Redis，而Sentinel可以监控Master节点和Slave节点的健康状况：当一个Master节点不可用，Sentinel会立即将同步度最高的Slave节点作为Master节点来对外提供服务，当Master节点恢复时，会将其置为一个Slave节点，这样就可以避免单点问题以及手动主从切换耗时问题了。
2.哨兵模式架构
哨兵模式与Redis 2.8引入，主要的作用是主从节点故障转移。
- 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。
- 数据节点：主节点和从节点都是数据节点。
3.节点下线
（1）定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：1.通过向主从节点发送info命令获取最新的主从结构；2.通过发布订阅功能获取其他哨兵节点的信息；3.通过向其他节点发送ping命令进行心跳检测，判断是否下线。
（2）主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。
（3）客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值（大多数），则对该主节点进行客观下线。
4.Leader选举
当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。
- Raft算法：通过Raft算法进行Leader选举，即先到先得策略，一般谁先完成了客观下线，它就会成为故障转移的Leader。
- 故障转移：Leader会对故障的Master节点进行故障转移，分为以下三个步骤：
1.在从节点中选择新的主节点：选择的原则是，首先过滤掉不健康的从节点；然后选择优先级最高的从节点(由slave-priority指定)；如果优先级无法区分，则选择复制偏移量最大的从节点；如果仍无法区分，则选择runid最小的从节点。
2.更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。
3.将已经下线的主节点(即6379)设置为新的主节点的从节点，当6379重新上线后，它会成为新的主节点的从节点。
5.为什么需要三个及以上的哨兵
原因：因为客观下线需要多数哨兵的认同，当只有两个哨兵时，大多数max=2；当 有3个哨兵时，max=2；当有5个哨兵时，max=3。如果有三个哨兵，当一个哨兵节点挂掉，那么其他两个哨兵主观下线，那么max=2成立，可以客观下线；若只有两个哨兵，当一个哨兵挂掉，那么永远无法满足客观下线所需的max=2认同，那么主节点永远无法被故障切换了。
4.Redis Cluster 集群
数据分区方案
1.哈希分区方案
这是最基础的一种数据分区方案，它的做法是对每个key取hash值，并用hash值取余可分配机器的个数n即可获取当前key分到的机器位置（index = hash(key) % n）。这种做法的缺点是如果有机器发生了宕机，那么n就会改变，所有的index都需要重新计算一遍，十分耗费性能。
2.一致性哈希分区方案
一致性哈希算法将整个哈希值空间组织成一个虚拟的圆环，如下图所示，范围为0-2^32-1；对于每个数据，==根据key计算出32位的hash值，确定数据在环上的位置。若此位置不存在服务器，则从此位置沿环顺时针行走，找到的第一台服务器就是其应该映射到的服务器。==这种做法的优点是当服务器数量变动时，只需要改变少数的几个节点。缺点是当服务器数量较少时，顺时针寻找服务器需要耗费较多的时间。
3.带虚拟节点的一致性哈希分区方案
该方案在一致性哈希分区的基础上，引入了虚拟节点的概念。Redis集群使用的便是该方案，其中的虚拟节点称为槽（slot）。槽是介于数据和实际节点之间的虚拟概念；每个实际节点包含一定数量的槽，每个槽包含哈希值在一定范围内的数据。引入槽以后，数据的映射关系由数据hash->实际节点，变成了数据hash->槽->实际节点。
在使用了槽的一致性哈希分区中，槽是数据管理和迁移的基本单位。槽解耦了数据和实际节点之间的关系，增加或删除节点对系统的影响很小。仍以上图为例，系统中有4个实际节点，假设为其分配16个槽(0-15)； 槽0-3位于node1，4-7位于node2，以此类推。如果此时删除node2，只需要将槽4-7重新分配即可，例如槽4-5分配给node1，槽6分配给node3，槽7分配给node4；可以看出删除node2后，数据在其他节点的分布仍然较为均衡。
槽的数量一般远小于2^32，远大于实际节点的数量；在Redis集群中，槽的数量为16384。所以Redis集群最多只可有16384个节点，超过16384的话，就没有槽可以分配给额外的节点。
特点：
（1）Redis对数据的特征值（一般是key）计算哈希值，使用的算法是CRC16。
（2）根据哈希值，计算数据属于哪个槽。
（3）根据槽与节点的映射关系，计算数据属于哪个节点。
