【redis】为何整数集升级后不能在进行降级操做 | intset位升级频率

前言

整数集合相信有的同窗没有据说过,由于redis对外提供的只有封装的五大对象!而咱们本系列主旨是学习redis内部结构。内部结构是redis五大结构重要支撑!html

前面咱们分别从redis内部结构分析了redis的List、Hash、Zset三种数据结构了。今天咱们再来分析set数据结构内部是如何存储的java

基本结构

  • 在src/t_set.c中咱们发现这样一段代码

image-20210706105819274

  • 由此咱们可知在set中是由两种数据结构构成的: hashtable+intset 。关于redis内部其余的结构我专门在【redis专栏中有介绍】。hashtable不是咱们今天的主角,咱们今天先分析intset俗称整数集合。

image-20210706110151754

  • 从上图中咱们能够看出,我构造了两个set集合分别为【commonset】、【cs】。两个集合前者存储字符串、后者专门存储数字。git

  • 咱们在经过object encoding key 来查看下两个集合的底层数据结构,发现一个是hashtable 一个是intset 。这也验证了咱们上面对set基本结构的描述。github

  • 在redis中对外提供五大类型实际上都是redis的一个抽象对象叫作redisobject。在内部映射了咱们redis内部的数据结构redis

image-20210706111432308

  • 针对commonset和cs两个集合在内部数据结构大概能够这么理解

image-20210706112349968

什么时候使用intset

  • 你能够单纯的认为只要是数字就会使用intset结构来存储,我恐怕要给你当头一棒了。实际上并非这样数组

  • 须要同时知足如下两个条件:数据结构

image-20210706113636870

image-20210706113647350

intset

image-20210706133736601

  • 图中表示的很清楚了,在intset中的encoding有三种取值分别表明contents保存数据类型。这里有人可能会有疑问了contents的类型不就是int8_t吗?为何还须要encoding呢?这里经过源码跟踪内部的确跟int8_t没啥关系。并且数据的默认类型就是int16_t 。关于length这里无需太多解释,记住一点表示contents元素的个数并不是表示contents数组的长度!
  • 了解intset的同窗都知道在encoding三种取值范围中涉及了升级的操做!在讲升级以前咱们先来了解下C、C++中int的取值范围是如何定义的
  • int8_t的取值范围是【-128,127】 。 相似于java中byte占1个字节也就是8位。他的取值范围是
−27∼27−1即−128∼127-2^{7} \sim 2^{7}-1 \\ 即 \\ -128 \sim 12727271128127

image-20210706135925132

添加元素

sadd juejin -123
sadd juejin -6
sadd juejin 12
sadd juejin 56
sadd juejin 321	
复制代码
  • juejin这个key内部就是intset 。

image-20210706162521929

  • 上面咱们添加了5个元素且这五个元素的长度都在16以内!因此当前的intset的encoding=INTSET_ENC_INT16。-123在contents中占前16位。post

  • 因此当前五个元素占contents的长度是16*5=80 ;性能

  • 注意set在存储int类型数据时,内部是按照从小到大的顺序存储的。学习

类型变更

image-20210706164922957

  • 上面的问题不知道你有没有考虑过,或者说有没有遇到过!intset默认是int16位,正如咱们上面添加的五个元素。加入此时咱们添加第6个元素是65535(32位)。那么此时16位的长度就不够存储了这个时候intset会怎么作!
  • 另外当咱们添加第6个元素后又将65535删除了以后,结构和添加以前是否同样!下面咱们带着这两个问题来一探究竟!!!

升级

  • 首先咱们针对第一问题来看看。原来五个元素都是16位就能够知足了,这个时候添加的65535是32位长度的。那么是否是能够直接追加32位分配给65535呢?
  • 答案是确定不行,首先直接追加没法保证数组元素的大小顺序!其次若是前五个分别是16位,第6个是32位那么在intset结构中没有多余的字段来进行标记。也就是说在解析的时候就没法判断应该解析16位仍是32位了.
  • redis为了方便解析因此在有高长度加入时会将整个contents进行升级。意思就是将整个contents先进行扩容,而后在从新填充数据

image-20210706171505334

加入65535

  • 首先根据length能够肯定扩容后元素个数为6 , 每一个占位32,因此contents长度为32*6=192 。 此时前80位内容保持不变

image-20210706171605386

旧数据移位

  • 开辟了足够的空间后,咱们就能够对旧数据进行移位了这里咱们从原数组的末尾开始移动,在移动以前须要明确在新数组中的排序位置。
  • 此时咱们首先将321进行比对肯定在新数组中他的排名是第五名,那么他将占用新contents中128~159区间。

image-20210706172455270

  • 最终前5 个元素就会被移动好 。

image-20210706172652958

  • 最后将新加入的元素填充进去。当发生升级时确定是由于新元素的长度大于原有长度了。那么他的值必定会是在新数组的两端。负数在最左侧,正数在最右侧

image-20210706172836896

降级

  • 接下来就是第二个问题当新加入的65535又被删除了redis该怎么办,这个时候元素长度实际16位就能够知足了,可是此时encoding倒是32位的。按照个人见解应该在实现降级!
  • 可是遗憾的是redis并无,那么请思考为何没有?若是让你实现你将如何实现

为何不实现降级

  • 当加入元素超过当前长度咱们很容易就知道此时须要进行升级操做,可是当咱们删除一个数据时咱们如何判断是否须要降级却很困难,咱们须要从新遍历一遍剩下的元素是否小于当前长度,实现复杂度O(N) 。这就是为何不进行降级缘由之一
  • 你可能会说从新遍历一遍很快的反正在内存中,那么你有没有想过若是降级以后又遇到升级状况,这样来回的升级降级就下降了咱们程序的性能了。咱们知道升级是必须的因此这里降级redis采起的是忽略的策略

小结

image-20210707135328472

创做不易,若是对你们有所帮助,但愿你们点赞支持,有什么问题也能够在评论区里讨论😄~

若是你以为这篇文章对你有点用的话,麻烦请给咱们的开源项目点点star:   http://github.crmeb.net/u/defu   不胜感激 !
来自 “开源独尊 ” ,连接: https://ym.baisou.ltd/post/795.html
相关文章
相关标签/搜索