本篇文章给大家分享的是有关复述,集群中分区的实现原理是什么,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。
<>强摘要
复述,集群本身提供了自动将数据分散到复述,集群不同节点的能力,分区实现的关键点问题包括:如何将数据自动地打散到不同的节点,使得不同节点的存储数据相对均匀;如何保证客户端能够访问到正确的节点和数据,如何保证重新分片的过程中不影响正常服务。这篇文章通过了解这些问题来认识复述,集群分区实现原理。
<>强认识复述,集群
复述,集群是由多个同时服务于一个数据集合的复述,实例组成的整体,对于用户来说,用户只关注这个数据集合,而整个数据集合的某个数据子集存储在哪个节点对于用户来说是透明的.Redis集群具有分布式系统的特点,也具有分布式系统如何实现高可用性与数据一致性的难点,由多个复述,实例组成的复述,集群结构通常如下:
<强>复述,集群
复述,集群特点如下:
所有的节点相互连接;
<李>集群消息通信通过集群总线通信,,集群总线端口大小为客户端服务端口+ 10000,这10000个是固定值;
<李>节点与节点之间通过二进制协议进行通信;
<李>客户端和集群节点之间通信和通常一样,通过文本协议进行;
<李>集群节点不会代理查询;
<强>复述,集群分区实现原理
<强>槽(槽)概念
复述,集群中有一个长16384度的槽的概念,他们的编号为0,1,2,3……16382年,16383年。这个槽是一个虚拟的槽,并不是真正存在的。正常工作的时候,复述,集群中的每个主节点都会负责一部分的槽,当有某个键被映射到某主负个责的槽,那么这主负个责为这个关键提供服务,至于哪个主节点负责哪个槽,这是可以由用户指定的,也可以在初始化的时候自动生成(redis-trib。rb脚本)。这里值得一提的是,在复述,集群中,只有主人才拥有槽的所有权,如果是某个主人的奴隶,这个奴隶只负责槽的使用,但是没有所有权.Redis集群怎么知道哪些槽是由哪些节点负责的呢?某个大师又怎么知道某个槽自己是不是拥有呢?
<强>位序列结构
主节点维护着一个字16384/8节的位序列,主节点用点来标识对于某个槽自己是否拥有。比如对于编号为1的槽,主人只要判断序列的第二位(索引从0开始)是不是为1即可。
<强>位序列
如上面的序列,表示当前主人拥有编号为1134的槽。集群同时还维护着槽到集群节点的映射,是由长度为16384类型为节点的数组实现的,槽编号为数组的下标,数组内容为集群节点,这样就可以很快地通过槽编号找到负责这个槽的节点。位序列这个结构很精巧,即不浪费存储空间,操作起来又很便捷。
<强>键空间分布基本算法
这里讲的是复述,集群如何将键空间分布在不同的节点的,键空间意为复述,集群所拥有用户所有数据集合的键的取值范围,这个范围叫做键空间。提到空间分布,必然会想到哈希算法,没错,通过哈希算法再加上取模运算可以将一个值固定地映射到某个区间,在这里,这个区间叫做槽区间由连续的槽组成。在复述,集群中,我们拥有16384个插槽,这个数是固定的,我们存储在复述,集群中的所有的键都会被映射到这些槽中、下面讲讲复述,集群是如何做映射的。
键到槽的基本映射算法如下:
<节> <节> <节> <节> <节>HASH_SLOT=CRC16(关键)国防部16384
用复述中的代码表示如下(这个代码被稍微修改了一下,后面会还原):
<节> <节> <节> <节> <节>CRC16(关键),0 x3fff
经过简单的计算就得到了当前关键应该是存储在哪里个槽面,值得注意的是,指定的关键会被存储在哪个插槽,这个关系是铁打不变的。如果我提交了一批命令,往复述中存储一批键,那么这些键一般会被映射到不同的位置,而不同的位置又可能由复述,集群中不同的节点服务,这样就和的预期有点不同,有没有办法将这批键映射到同一个槽呢?答案是可以。
