腾讯专门做数据标注的网站是,全国网站建设企业,wordpress+文章分页插件,商标买卖图文主要参考小林Coding的图解redis数据结构 redis为什么快 除了它是内存数据库#xff0c;使得所有的操作都在内存上进⾏之外#xff0c;还有⼀个重要因素#xff0c;它实现的数据结构#xff0c;使 得我们对数据进⾏增删查改操作时#xff0c;Redis 能⾼效的处理。 数…图文主要参考小林Coding的图解redis数据结构 redis为什么快 除了它是内存数据库使得所有的操作都在内存上进⾏之外还有⼀个重要因素它实现的数据结构使 得我们对数据进⾏增删查改操作时Redis 能⾼效的处理。 数据库全景图 :::tips redisDb 结构表示 Redis 数据库的结构结构体⾥存放了指向了 dict 结构的指针 dict 结构结构体⾥存放了 2 个哈希表正常情况下都是⽤「哈希表1」「哈希表2」只有在rehash 的时候才⽤具体什么是 rehash我在本⽂的哈希表数据结构会讲 ditctht 结构表示哈希表的结构结构⾥存放了哈希表数组数组中的每个元素都是指向⼀个哈希表节点结构dictEntry的指针 dictEntry 结构表示哈希表节点的结构结构⾥存放了 void * key 和 void * value 指针 *key 指向的是 String 对象⽽ *value 则可以指向 String 对象也可以指向集合类型的对象⽐如 List 对象、Hash 对象、Set 对象和 Zset 对象 ::: Redis 数据结构 并不是指 String字符串对象、List列表对象、Hash哈希对象、Set集合对象和 Zset有序集合对象因为这些是 Redis 键值对中值的数据类型也就是数据的保存形式这些对象的底层实现的⽅式就⽤到了数据结构。 SDS 简单动态字符串simple dynamic stringSDS C语言字符缺陷 1结尾位置用“\0” char * 指针只是指向字符数组的起始位置⽽字符数组的结尾位置就⽤“\0”表示意思是指字符串的结束 获取字符串⻓度的函数strlen 就是通过字符数组中的每⼀个字符并进⾏计数等遇到字符为 “\0” 后就会停⽌遍历 2字符串里面不能含有“\0”字符 这个限制使得 C 语⾔的字符串只能保存⽂本数据不能保存像图⽚、⾳频、视频⽂化这样的⼆进制数据 3strcat会缓冲区溢出 总结 :::tips 1获取字符串⻓度的时间复杂度为 ON 2字符串的结尾是以 “\0” 字符标识字符串⾥⾯不能包含有 “\0” 字符因此不能保存⼆进制数据 3字符串操作函数不⾼效且不安全⽐如有缓冲区溢出的⻛险有可能会造成程序运⾏终⽌ ::: SDS的改进 :::tips 1len记录了字符串⻓度。这样获取字符串⻓度的时候只需要返回这个成员变量值就⾏时间复杂度 只需要 O1 2alloc分配给字符数组的空间⻓度。这样在修改字符串的时候可以通过 alloc - len 计算出剩余的 空间⼤⼩可以⽤来判断空间是否满⾜修改需求如果不满⾜的话就会⾃动将 SDS 的空间扩展⾄ 执⾏修改所需的⼤⼩然后才执⾏实际的修改操作所以使⽤ SDS 既不需要⼿动修改 SDS 的空间⼤ ⼩也不会出现前⾯所说的缓冲区溢出的问题。 3flags⽤来表示不同类型的 SDS。⼀共设计了 5 种类型分别是 sdshdr5、sdshdr8、sdshdr16、 sdshdr32 和 sdshdr64后⾯在说明区别之处。 4buf[]字符数组⽤来保存实际数据。不仅可以保存字符串也可以保存⼆进制数据。 ::: 总结 O1复杂度获取字符串⻓度Redis 的 SDS 结构因为加⼊了 len 成员变量获取字符串⻓度的时候直接返回这个成员变量的值就⾏⼆进制安全有个专⻔的 len 成员变量来记录⻓度所以可存储包含 “\0” 的数据不会发⽣缓冲区溢出引⼊了 alloc 和 len 成员变量当判断出缓冲区⼤⼩不够⽤时Redis 会⾃动将扩⼤ SDS 的空间⼤⼩下次在操作 SDS 时如果 SDS 空间够的话API 就会直接使⽤「未使⽤空间」⽽⽆须执⾏内存分配有效的减少内存分配次数节省内存空间有个 flags 成员变量表示的是 SDS 类型。Redis ⼀共设计了 5 种类型分别是 sdshdr5、sdshdr8、sdshdr16、sdshdr32 和 sdshdr64。之所以 SDS 设计不同类型的结构体是为了能灵活保存不同⼤⼩的字符串从⽽有效节省内存空间。Redis 在编程上还使⽤了专⻔的编译优化来节省内存空间即在 struct 声明了 attribute ((packed)) 它的作⽤是告诉编译器取消结构体在编译过程中的优化对⻬按照实际占⽤字节数进⾏对⻬ 链表 Redis 的 List 对象的底层实现之⼀就是链表 :::tips 链表优点 listNode 链表节点的结构⾥带有 prev 和 next 指针获取某个节点的前置节点或后置节点的时间复杂 度只需O(1)⽽且这两个指针都可以指向 NULL所以链表是⽆环链表list 结构因为提供了表头指针 head 和表尾节点 tail所以获取链表的表头节点和表尾节点的时间复杂度只需O(1) list 结构因为提供了链表节点数量 len所以获取链表中的节点数量的时间复杂度只需O(1) listNode 链表节使⽤ void* 指针保存节点值并且可以通过 list 结构的 dup、free、match 函数指针为节点设置该节点类型特定的函数因此链表节点可以保存各种不同类型的值 链表缺陷 链表每个节点之间的内存都是不连续的意味着⽆法很好利⽤ CPU 缓存。能很好利⽤ CPU 缓存的数据结构就是数组因为数组的内存是连续的这样就可以充分利⽤ CPU 缓存来加速访问。保存⼀个链表节点的值都需要⼀个链表节点结构头的分配内存开销较⼤ ::: 压缩列表 压缩列表的最⼤特点就是它被设计成⼀种内存紧凑型的数据结构占⽤⼀块连续的内存空间不仅可以利⽤ CPU 缓存⽽且会针对不同⻓度的数据进⾏相应编码这种⽅法可以有效地节省内存开销。 :::tips 压缩列表的缺陷也是有的 不能保存过多的元素否则查询效率就会降低新增或修改某个元素时压缩列表占⽤的内存空间需要重新分配甚⾄可能引发连锁更新的问题。 因此Redis 对象List 对象、Hash 对象、Zset 对象包含的元素数量较少或者元素值不⼤的情况才会使⽤压缩列表作为底层数据结构。 ::: :::tips zlbytes记录整个压缩列表占⽤对内存字节数zltail记录压缩列表「尾部」节点距离起始地址由多少字节也就是列表尾的偏移量zllen记录压缩列表包含的节点数量zlend标记压缩列表的结束点固定值 0xFF⼗进制255。 压缩列表entry节点包含三部分内容 prevlen记录了「前⼀个节点」的⻓度encoding记录了当前节点实际数据的类型以及⻓度data记录了当前节点的实际数据 ::: 连锁更新 :::tips 压缩列表新增某个元素或修改某个元素时如果空间不不够压缩列表占⽤的内存空间就需要重新分配。⽽当新插⼊的元素较⼤时可能会导致后续元素的 prevlen 占⽤空间都发⽣变化从⽽引起「连锁更新」问题导致每个元素的空间都要重新分配造成访问压缩列表性能的下降 ::: 压缩列表的缺陷 :::tips 连锁更新⼀旦发⽣就会导致压缩列表占⽤的内存空间要多次重新分配这就会直接影响到压缩列表的访问性能,压缩列表只会⽤于保存的节点数量不多的场景. ::: quicklist quicklist 是「双向链表 压缩列表」组合因为⼀个 quicklist 就是⼀个链表⽽链表中的每个元素⼜是⼀个压缩列表 :::tips 压缩列表会有「连锁更新」的⻛险⼀旦发⽣会造成性能下降。 quicklist 解决办法通过控制每个链表节点中的压缩列表的⼤⼩或者元素个数来规避连锁更新的问题。 因为压缩列表元素越少或越⼩连锁更新带来的影响就越⼩从⽽提供了更好的访问性能。 ::: 结构设计 :::tips 在向 quicklist 添加⼀个元素的时候不会像普通的链表那样直接新建⼀个链表节点。⽽是会检查插⼊位置的压缩列表是否能容纳该元素如果能容纳就直接保存到 quicklistNode 结构⾥的压缩列表如果不能容纳才会新建⼀个新的 quicklistNode 结构。quicklist 会控制 quicklistNode 结构⾥的压缩列表的⼤⼩或者元素个数来规避潜在的连锁更新的⻛险但是这并没有完全解决连锁更新的问题。 ::: listpack 结构设计 :::tips listpack 头包含两个属性分别记录了 listpack 总字节数和元素数量然后 listpack 末尾也有个结尾标 识。图中的 listpack entry 就是 listpack 的节点了。 主要包含三个⽅⾯内容 encoding定义该元素的编码类型会对不同⻓度的整数和字符串进⾏编码data实际存放的数据lenencodingdata的总⻓度 ::: listpack 没有压缩列表中记录前⼀个节点⻓度的字段了listpack 只记录当前节点的⻓度当我们向 listpack 加⼊⼀个新元素的时候不会影响其他节点的⻓度字段的变化从⽽避免了压缩列表的连锁更新问题。 哈希表 :::tips 哈希表中的每⼀个 key 都是独⼀⽆⼆的程序可以根据 key 查找到与之关联的 value或者通过 key 来更 新 value⼜或者根据 key 来删除整个 key-value等等。 在讲压缩列表的时候提到过 Redis 的 Hash 对象的底层实现之⼀是压缩列表最新 Redis 代码已将压缩 列表替换成 listpack。Hash 对象的另外⼀个底层实现就是哈希表。 哈希表优点在于它能以 O(1) 的复杂度快速查询数据Redis 采⽤了「链式哈希」来解决哈希冲突 ::: rehash过程 :::tips 在正常服务请求阶段插⼊的数据都会写⼊到「哈希表 1」此时的「哈希表 2 」 并没有被分配空间。 随着数据逐步增多触发了 rehash 操作这个过程分为三步 给「哈希表 2」 分配空间⼀般会⽐「哈希表 1」 ⼤ 2 倍将「哈希表 1 」的数据迁移到「哈希表 2」 中迁移完成后「哈希表 1 」的空间会被释放并把「哈希表 2」 设置为「哈希表 1」然后在「哈希表 2」 新创建⼀个空⽩的哈希表为下次 rehash 做准备。 ::: 渐进式rehash 为了避免 rehash 在数据迁移过程中因拷⻉数据的耗时影响 Redis 性能的情况所以 Redis 采⽤了渐 进式 rehash也就是将数据的迁移的⼯作不再是⼀次性迁移完成⽽是分多次迁移。 rehash 触发条件 rehash 的触发条件跟负载因⼦load factor有关系 整数集合 整数集合是 Set 对象的底层实现之⼀Set 对象只包含整数值元素 :::tips 可以看到保存元素的容器是⼀个 contents 数组虽然 contents 被声明为 int8_t 类型的数组但是实际上 contents 数组并不保存任何 int8_t 类型的元素contents 数组的真正类型取决于 intset 结构体⾥的encoding 属性的值。⽐如 如果 encoding 属性值为 INTSET_ENC_INT16那么 contents 就是⼀个 int16_t 类型的数组数组中每⼀个元素的类型都是 int16_t如果 encoding 属性值为 INTSET_ENC_INT32那么 contents 就是⼀个 int32_t 类型的数组数组中每⼀个元素的类型都是 int32_t如果 encoding 属性值为 INTSET_ENC_INT64那么 contents 就是⼀个 int64_t 类型的数组数组中每⼀个元素的类型都是 int64_t不同类型的 contents 数组意味着数组的⼤⼩也会不同。 ::: 升级操作 :::tips 当我们将⼀个新元素加⼊到整数集合⾥⾯如果新元素的类型int32_t⽐整数集合现有所有元素的类型int16_t都要⻓时整数集合需要先进⾏升级也就是按新元素的类型int32_t扩展 contents 数组的空间⼤⼩然后才能将新元素加⼊到整数集合⾥当然升级的过程中也要维持整数集合的有序性。 ::: 1假设有3个类型int16_t的元素 2现在要加入一个新元素65535需要使用int32_t来保存 contents数组腰扩容4*32-3-1680 :::tips 如果要让⼀个数组同时保存 int16_t、int32_t、int64_t 类型的元素最简单做法就是直接使⽤ int64_t 类型的数组。不过这样的话当如果元素都是 int16_t 类型的就会造成内存浪费的情况整数集合升级就能避免这种情况如果⼀直向整数集合添加 int16_t 类型的元素那么整数集合的底层实现就⼀直是⽤ int16_t 类型的数组只有在我们要将 int32_t 类型或 int64_t 类型的元素添加到集合时才会对数组进⾏升级操作因此整数集合升级的好处是节省内存资源不⽀持降级操作⼀旦对数组进⾏了升级就会⼀直保持升级后的状态。⽐如前⾯的升级操作的例⼦如果删除了 65535 元素整数集合的数组还是 int32_t 类型的并不会因此降级为 int16_t 类型 ::: 跳表 :::tips Redis 只有在 Zset 对象的底层实现⽤到了跳表跳表的优势是能⽀持平O(logN) 复杂度的节点查找 Zset 对象在使⽤压缩列表作为底层数据结构的时候zset对象结构的指针会指向压缩列表Zset对象在使⽤跳表作为底层数据结构的时候zset对象结构的指针会指向zset结构哈希表跳表 ::: :::tips Zset 对象在使⽤跳表作为底层实现的时候并不是指向跳表数据结构⽽是指向了zset结构它包含两个数据结构⼀个是跳表⼀个是哈希表。这样的好处是既能进⾏⾼效的范围查询也能进⾏⾼效单点查询。 ::: 结构设计 跳表是在链表基础上改进过来的实现了⼀种「多层」的有序链表 :::tips 图中头节点有 L0~L2 三个头指针分别指向了不同层级的节点然后每个层级的节点都通过指针连接起来 L0 层级共有 5 个节点分别是节点1、2、3、4、5L1 层级共有 3 个节点分别是节点 2、3、5L2 层级只有 1 个节点也就是节点 3 。 如果我们要在链表中查找节点 4 这个元素只能从头开始遍历链表需要查找 4 次⽽使⽤了跳表后只需要查找 2 次就能定位到节点 4因为可以在头节点直接从 L2 层级跳到节点 3然后再往前遍历找到节点4。 可以看到这个查找过程就是在多个层级上跳来跳去最后定位到元素。当数据量很⼤时跳表的查找复杂度就是 O(logN)。 ::: 节点数据结构 :::tips 跨度实际上是为了计算这个节点在跳表中的排位 ::: 跳表结构体 :::tips 跳表的头尾节点便于在O(1)时间复杂度内访问跳表的头节点和尾节点跳表的⻓度便于在O(1)时间复杂度获取跳表节点的数量跳表的最⼤层数便于在O(1)时间复杂度获取跳表中层⾼最⼤的那个节点的层数量 ::: 跳表查询过程 :::tips 查找⼀个跳表节点的过程时跳表会从头节点的最⾼层开始逐⼀遍历每⼀层。在遍历某⼀层的跳表节点时会⽤跳表节点中的 SDS 类型的元素和元素的权重来进⾏判断共有两个判断条件 如果当前节点的权重「⼩于」要查找的权重时跳表就会访问该层上的下⼀个节点。如果当前节点的权重「等于」要查找的权重时并且当前节点的 SDS 类型数据「⼩于」要查找的数据时跳表就会访问该层上的下⼀个节点。 如果上⾯两个条件都不满⾜或者下⼀个节点为空时跳表就会使⽤⽬前遍历到的节点的 level 数组⾥的下⼀层指针然后沿着下⼀层指针继续查找这就相当于跳到了下⼀层接着查找。 ::: :::tips 如果要查找「元素abcd权重4」的节点查找的过程是这样的 先从头节点的最⾼层开始L2 指向了「元素abc权重3」节点这个节点的权重⽐要查找节点的⼩所以要访问该层上的下⼀个节点但是该层上的下⼀个节点是空节点于是就会跳到「元素abc权重3」节点的下⼀层去找也就是 leve[1];「元素abc权重3」节点的 leve[1] 的下⼀个指针指向了「元素abcde权重4」的节点然后将其和要查找的节点⽐较。虽然「元素abcde权重4」的节点的权重和要查找的权重相同但是当前节点的 SDS 类型数据「⼤于」要查找的数据所以会继续跳到「元素abc权重3」节点的下⼀层去找也就是 leve[0]「元素abc权重3」节点的 leve[0] 的下⼀个指针指向了「元素abcd权重4」的节点该节点正是要查找的节点查询结束。 ::: 跳表节点层数设置 :::tips 跳表的相邻两层的节点数量最理想的⽐例是 2:1查找复杂度可以降低到 O(logN)。 ::: 怎么维持 :::tips Redis 则采⽤⼀种巧妙的⽅法是跳表在创建节点的时候随机⽣成每个节点的层数并没有严格维持相 邻两层的节点数量⽐例为 2 : 1 的情况。 具体的做法是跳表在创建节点时候会⽣成范围为[0-1]的⼀个随机数如果这个随机数⼩于 0.25相当 于概率 25%那么层数就增加 1 层然后继续⽣成下⼀个随机数直到随机数的结果⼤于 0.25 结束 最终确定该节点的层数。 这样的做法相当于每增加⼀层的概率不超过 25%层数越⾼概率越低层⾼最⼤限制是 64。 :::