Redis系列 cluster集群原理和一致性哈希算法数据分配理论

前言

上一章讲解了cluster集群的搭建,那redis的三种模式搭建方式也就都给大家介绍完了一个主从模式一个哨兵模式一个集群模式,大家可以根据不同的项目需求和生产环境的情况去选择合适的模式去搭建自己的服务器,接下来我们就来讲解一下cluster的一个原理来结束掉redis三种模式框架的叙述,另外还会说一个比较火的一个redis集群理论,可以承载更高的并发同时还能保证更高的高可用性,大家一起来看一下吧!

cluster集群原理

cluster集群也被叫做是redis分片,他的理论稍微简单一些!

cluster基本原理

  1. 当集群建立的时候他会将16384个哈希槽平均分配给没一个redis主节点,为何是16384个哈希槽,因为redis每个key的计算公式为 - slot = CRC16(key) % 16384 每个存储请求都会将他的key进行 CRC16计算然后再对16384进行取模后得出的值就会在0-16384期间
  2. 然后根据key的计算结果去寻找该值在那个节点的覆盖范围之内
  3. 找到以后跳转到该节点进行数据保存或者进行查询

    CRC16的算法原理

  • 根据CRC16的标准选择初值CRCIn的值
  • 将数据的第一个字节与CRCIn高8位异或
  • 判断最高位,若该位为 0 左移一位,若为 1 左移一位再与多项式Hex码异或
  • 重复3直至8位全部移位计算结束。
  • 重复将所有输入数据操作完成以上步骤,所得16位数即16位CRC校验码。

    CRC16 算法最大值

    CRC16 算法,产生的hash值有 16 bit 位,可以产生 65536(2^16)个值 ,也就是说值分布在 0 \~ 65535 之间

那么问题来了,那为什么不是65535个槽位而是16384个槽位呢?对于这个问题在官方也是有人提过,antirez大神对这个问题做了回复,简单归纳起来,有以下原因:

  • 正常的心跳数据包携带节点的完整配置,它能以幂等方式来更新配置。如果采用 16384 个插槽,占空间 2KB (16384/8);如果采用 65536 个插槽,占空间 8KB (65536/8),浪费带宽
  • Redis Cluster 不太可能扩展到超过 1000 个主节点,太多可能导致网络拥堵。
  • 16384 个插槽范围比较合适,当集群扩展到1000个节点时,也能确保每个master节点有足够的插槽

一致性哈希数据分配理论

一致性哈希数据分配是一个理论需要我们根据理论来进行手撸代码来实施!

  1. 首先我们定义一个大小为2^32的数组,然后把这个数组抽象成一个圆环首尾相连
  2. 然后我们在对服务器的节点ip或者节点其他数据进行hash(服务器ip)%2^32运算,然后得出一个0-2^32的值,这个值就是这个节点在第一步定义的哈希环上的坐标,比如我们有4个主服务器节点,ABCD, A运算完得出值真合适为2^32的百分之25,B的值为2^32的百分之50,C的值为2^32的百分之75,D值为0,那这4个节点在哈希环上的分布大致就是

image

  1. 每个节点都覆盖了一部分的哈希环,然后当我们进行写入数据的时候,我们就会对数据key进行hash(key)%2^32运算,得出的值就是这数据在环上的起跑点,然后该数据顺时针在环上运动,碰见的第一个节点就是他要存入的节点,如hash(key)%2^32 = 100,那

image

这也是为什么那一块被节点A覆盖了!

  1. 当其中一个节点丢失,如节点C被删除或者宕机,那节点B-节点C的数据将会丢失,节点C-节点B的数据不会收到影响

image

  1. 当节点C数据迁移到另一个IP地址的节点E上,那节点E也会通过取模运算计算他的位置,然后取出他的数据进行重新取模然后放入对应的redis节点

    虚拟节点理论

  2. 当我们节点过少的时候如上面节点C挂掉以后那节点B-节点D的数据都会存入节点D,导致节点D压力剧增怎么,那我们就要引入一个新的概念 - 虚拟节点,就是让每个节点不在有一个位置而是有多个位置,如使用 hash(节点ip+编号)%2^32,使用不同编号让一个节点生成不同的位置,如

image

  1. 这样子服务器ABCD就会有一个分身出去穿插在其他服务器节点中间.当一个节点挂掉也不会导致一个服务器托管了宕机那个服务器的全部工作,比如服务器B挂掉了(也就是节点2和节点6宕机了)那也是节点3和节点7去托管他的工作也就是服务器A和服务器D,去分担!
  2. 为了使服务器节点尽可能的平均存储数据,每个服务器可以尽可能的生成更多的虚拟节点分布在哈希环上!

小结

上面就是一个redis自带的集群模式cluster的理论,还是一个需要自己根据理论然后代码实现的一个一致性哈希数据分配了,希望大家可以手撸一个一致性哈希数据分配的架构出来!

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇