共计 2308 个字符，预计需要花费 6 分钟才能阅读完成。
这篇文章主要为大家展示了“redis 整数集不能降级的原因是什么”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让丸趣 TV 小编带领大家一起研究并学习一下“redis 整数集不能降级的原因是什么”这篇文章吧。
基本结构
在 src/t_set.c 中我们发现这样一段代码
由此我们可知在 set 中是由两种数据结构构成的：hashtable+intset。关于 redis 内部其他的结构我专门在【redis 专栏中有介绍】。hashtable 不是我们今天的主角，我们今天先分析 intset 俗称整数集合。
从上图中我们可以看出，我构造了两个 set 集合分别为【commonset】、【cs】。两个集合前者存储字符串、后者专门存储数字。
我们在通过 object encoding key 来查看下两个集合的底层数据结构，发现一个是 hashtable 一个是 intset 。这也验证了我们上面对 set 基本结构的描述。
在 redis 中对外提供五大类型实际上都是 redis 的一个抽象对象叫做 redisobject。在内部映射了我们 redis 内部的数据结构
针对 commonset 和 cs 两个集合在内部数据结构大概可以这么理解
何时使用 intset
你可以单纯的认为只要是数字就会使用 intset 结构来存储，我恐怕要给你当头一棒了。实际上并不是这样
需要同时满足以下两个条件：
intset
图中表示的很清楚了，在 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 位。他的取值范围是
\[-2^{7} \sim 2^{7}-1 \\ 即 \\
-128 \sim 127
\]
添加元素
sadd juejin -123
sadd juejin -6
sadd juejin 12
sadd juejin 56
sadd juejin 321juejin 这个 key 内部就是 intset。
上面我们添加了 5 个元素且这五个元素的长度都在 16 之内！所以当前的 intset 的 encoding=INTSET_ENC_INT16。-123 在 contents 中占前 16 位。
所以当前五个元素占 contents 的长度是 16*5=80；
注意 set 在存储 int 类型数据时，内部是按照从小到大的顺序存储的。
类型变动
上面的问题不知道你有没有考虑过，或者说有没有遇到过！intset 默认是 int16 位，正如我们上面添加的五个元素。加入此时我们添加第 6 个元素是 65535(32 位)。那么此时 16 位的长度就不够存储了这个时候 intset 会怎么做！
另外当我们添加第 6 个元素后又将 65535 删除了之后，结构和添加之前是否一样！下面我们带着这两个问题来一探究竟！！！
升级
首先我们针对第一问题来看看。原来五个元素都是 16 位就可以满足了，这个时候添加的 65535 是 32 位长度的。那么是不是可以直接追加 32 位分配给 65535 呢？
答案是肯定不行，首先直接追加无法保证数组元素的大小顺序！其次如果前五个分别是 16 位，第 6 个是 32 位那么在 intset 结构中没有多余的字段来进行标记。也就是说在解析的时候就无法判断应该解析 16 位还是 32 位了.
redis 为了方便解析所以在有高长度加入时会将整个 contents 进行升级。意思就是将整个 contents 先进行扩容，然后在重新填充数据
加入 65535
首先根据 length 可以确定扩容后元素个数为 6，每个占位 32，所以 contents 长度为 32*6=192。此时前 80 位内容保持不变
旧数据移位
开辟了足够的空间后，我们就可以对旧数据进行移位了这里我们从原数组的末尾开始移动，在移动之前需要明确在新数组中的排序位置。
此时我们首先将 321 进行比对确定在新数组中他的排名是第五名，那么他将占用新 contents 中 128~159 区间。
最终前 5 个元素就会被移动好。
最后将新加入的元素填充进去。当发生升级时肯定是因为新元素的长度大于原有长度了。那么他的值一定会是在新数组的两端。负数在最左侧，正数在最右侧
降级
接下来就是第二个问题当新加入的 65535 又被删除了 redis 该怎么办，这个时候元素长度实际 16 位就可以满足了，但是此时 encoding 却是 32 位的。按照我的看法应该在实现降级！
但是遗憾的是 redis 并没有，那么请思考为什么没有？如果让你实现你将如何实现
为什么不实现降级
当加入元素超过当前长度我们很容易就知道此时需要进行升级操作，但是当我们删除一个数据时我们如何判断是否需要降级却很困难，我们需要重新遍历一遍剩下的元素是否小于当前长度，实现复杂度 O(N)。这就是为什么不进行降级原因之一
你可能会说重新遍历一遍很快的反正在内存中，那么你有没有想过如果降级之后又遇到升级情况，这样来回的升级降级就降低了我们程序的性能了。我们知道升级是必须的所以这里降级 redis 采取的是忽略的策略
小结
以上是“redis 整数集不能降级的原因是什么”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注丸趣 TV 行业资讯频道！
