本文共 3611 字，大约阅读时间需要 12 分钟。

一、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中提供主从高可用的技术为哨兵模式

哨兵进程的工作原理

        在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 抢票:前台的订单下发,但是后台的数据库数据未必立刻修改

转载地址：http://iayai.baihongyu.com/