一、hash一致性
hash一致性作为散列算法
1、hash取余的缺点
考虑分布式缓存中的数据分片过程的哈希取余的缺点（两点）：
（1）数据倾斜
只要是散列算法.必定数据倾斜（散列是无关系、无规律的）没有办法用算法做到平均，但是可以尽量减少数据倾斜。
数据倾斜:例如3个redis节点.在散列计算后的存储数据有可能是;
1. node1:4000条数据
2. node2:3000条数据
3. node3:1500条数据
当数据存储量非常大时(上亿条),微小的数据倾斜量也会造成集群中节点间的巨大负载差距。
解决数据倾斜的问题:可以在key值上做文章；uuid/md5加密，在key值的取值时就进行散列分布;
（2） 哈希取余的散列计算,导致数据迁移量过大
可以看出：当客户端使用哈希取余的分片逻辑时,导致：节点数量越多.当增加或减少节点时的数据迁移量越大。
2 、hash一致性
jedis的数据分片没有使用hash取余计算而是引入的hash一致性。
2.1 Hash一致性的简介
1997年麻省理工学院的学生开发了哈希一致性的计算方法。
具体如下：
引入了一个0-43亿的整数哈希环(0-2^32)
把节点的ip和端口和其他信息作为字符串的对象进行散列计算
利用这个hash环上的对应内容的散列结果,对key做顺时针寻找最近节点映射整数的判断
如上图中：
key1顺时针最近节点–node1
key2,key3顺时针最近节点–node3
key4顺时针最近节点–node2
以这样一种计算.将所有的key值进行数据分片的计算
如果某个key值的散列结果刚好和节点的散列结果一致，落在同一个点上，则可以包含，也可以不包含，看实际的需求。
2.2 三级标题Hash一致性能否减少增删节点的数据迁移量?
当增加节点node4时，如下图：
对于当前存在的数据,只需要根据顺时针最近节点的计算原理,迁移key4,其他的key不用动当节点删除时(node3)时，如下图：
对于当前存在的数据,只需要根据顺时针最近节点的计算原理,只需要迁移key2,和key3,其他的key不用动。
2.3 哈希一致性解决数据平衡的问题
单独的使用节点ip+端口+其他信息的散列映射.有可能导致数据的倾斜量过大
解决数据平衡的问题,hash一致性.引入虚拟节点的概念
在没有虚拟节点的情况下：
node2需要存储key2,key3,key4,key5
node1存储key1
当引入了虚拟节点的映射(ip+端口+#序列号)
node1-node1-01:“192.168.40.139:6379#01”
node1-node1-02:“192.168.40.139:6379#02”
（序列号：如果有5个节点，序号为0-4，如果有两个节点，序号为0-1…）
key值存放结果变成:
node1存储key1,key2,key4;
node2存储key3,key5;
默认情况下每个物理节点的虚拟节点数量1000个
二、主从复制
1、redis的两种集群结构
普通集群：只有三个节点的集群。。
当前的三个redis节点实例无法做到高可用，一旦其中任意一个节点宕机，就必须重新访问数据库并没有备份的数据。
主从复制高可用（主从复制和哨兵的结合）
可以使用从节点备份主节点的数据
2、主从结构主从复制
redis中可以提供主从复制的结构
master-slave,可以多级复制
三、哨兵集群的高可用
1、 哨兵模式
哨兵模式
哨兵进程的工作原理
在redis中可以启动哨兵的进程,挂载某一个主从结构,来管理当前的主从,同一个主从结构可以由多个哨兵进程管理(便于选举),在监控主从结构时,所有的哨兵进程会调用info命令查看当前的主从状态,一旦发现返回的结果中master宕机了,所有的哨兵进程会进行选举的操作(过半选举),选出替代主节点执行服务的从节点.执行命令将从节点变换成主节点。
选举机制(过半选举)
哨兵集群中.监控管理主从结构的哨兵个数最好是奇数个集群选举容忍度
2个哨兵存在的时候,为了达到过半原则,可以允许几个宕机?
2 个哨兵的选举容忍度0
3 个哨兵选举容忍度1
4个哨兵,选举容忍度1
5 --2
6 --2
2n 和2n-1个集群的选举容忍度相同;为了节省资源.配置奇数个
四、redis集群（Redis-cluster）
（1）所有的redis节点彼此互联(包括所有的主和从节点),（互联是为了）使用内部二进制的协议优化传输速度（相互之间跨网络通信了，速度越快越好）。
（2）节点的fail是通过集群中的超过半数的主节点投票选举的(抛弃了哨兵的进程)
(3)客户端与redis-cluster的直连,不需要连接所有节点,只要至少连接一个,就可以做到数据的分布式存储效果（由于所有节点是彼此互通的，内部会进行数据的转发）
（4）redis-cluster把所有的主节点映射到[0-16383]号的slot(槽道上)(不一定平均分配)。
cluster维护的key不是直接与节点挂钩,node---->slot----->数据
（例如：管理某个key值的槽道不再由该节点管理了，那么key就间接换节点管理了）
（5）当数据即将存储到集群中时,key值做哈希取模运算(散列运算),得到0-16383的整数,从而得到映射的槽道号,通过槽道号找到对应的node节点存储
注意：
和哨兵的高可用集群不同。集群中从节点是可以set的（可以写数据）,因为可以进行转发。 |
根据企业的运维经验;主从结构最多2级主从,每个主节点最多6个从节点,否则主从结构不稳定
槽道都是由主节点维护的，从节点是不维护槽道的。
redis-cluster最大的特点就是动态添加（动态扩容）：比如3个不够用了，需要加第四个、第五个。。。。
对于前面的两种集群，添加的方法：配置一个启动，配置一个启动
redis-cluster是添加方法：启动集群，调用命令添加到集群中来享用集群的分布式逻辑，享用集群的槽道。
维护人员可以人为的控制当前节点上的槽道从而控制数据倾斜
也可以引入代码维护集群节点的数据倾斜
代码定时检查集群节点状态,当数据倾斜达到一定程度,根据倾斜数据做计算将槽道自动重新分配
槽道并不是真正存在的
槽道的本质：分为两部分 一个是位序列(16384位),一个是共享数组(16384个元素)
和hash一致性不同,hash一致性是得到43亿的整数区间,而槽道的得到一个0-16383的整数区间。
为什么jedis连接一个节点就可以做到数据的分布存储效果呢？
因为数据的维护在集群内部的。
例如：某个key值进入到集群里面的某一个节点，经过计算key的槽道号为5003，那么就会将该key值转发到槽道5003管理的节点上进行存储。
五、CAP理论
CAP是分布式集群中的一个重要理论
C:consistency(一致性) A:avalibility(可用性) P:partition(分区)-tolenrence to partition(分区容忍度)
随着数据量增长需求.业务的多元化,分布式结构不可或缺.CAP理论是分布式集群中的记录理论之一
分区:一个分布式系统中.多个系统组成的网络本来是互通的,但是可能因为某种原因导致两个或多个节点间的数据通信断开，整个系统的整体被分割成了若干个取余的过程.叫做分布式系统的分区(分区是常态)
一旦分区出现,数据的修改和查询将受到影响,需要考虑数据一致性
一致性:数据在某个查看的时间点上保持整体一致;
如果在数据修改时,对于查看数据的客户端要求数据一致,必须加锁,实现整体一致性;
在修改时.如果要求数据一致性,客户端将在加锁的时间段内不能访问数据,导致可用性的降低
可用性:客户端的请求在一定时间段内都有回应;
分区容忍度:在分区出现的情况下,如果对数据的一致性要求高,分区容忍度高;如果在分区出现的情况下.对数据的一致性要求低,分区容忍度低;
CAP理论的结论:
在分布式集群中.只可能同时满足CAP理论中的2个条件
CA–无分区,数据一致性可达
CP–数据一致性要求高的分区状态
AP–数据一致性要求低的分区状态(不加锁,可用性提高)
（CA出现的概率不高，现实中网络不会一直都是畅通的）
分布式集群中的CAP理论可以理解为;
分区是常态,要求数据一致性导致可以用性减低,可用性提高;数据一致性低
两个CP 和 AP的现实场景;
1 支付:需要第三方平台的数据必须和银行一直(支付宝,银行)
2 抢票:前台的订单下发,但是后台的数据库数据未必立刻修改
