Redis----数据结构

关注

原创 2025-05-30 23:35:34 5k 阅读 AI 写同款· GEO 优化 ›

Redis之数据结构 Redis 为什么那么快？除了它是内存数据库，使得所有的操作都在内存上进行之外，还有一个重要因素，它实现的数据结构，使得我们对数据进行增删查改操作时，Redis 能高效地处理。因此，这次我们就来好好聊一下 Redis 数据结构：String（字符串）对象、List（列表）对象、Hash（哈希）对象、Set（集合）对象和 Zset（有序集合）。底层（3.0和3.2之后有变化）对应的分别是：SDS、双向链表、压缩列表、哈希表、跳表、整数集合、quicklist、listpack。阅读详情

一.认识Redis

什么是Redis

一款基于内存的非关系型数据库,对数据的读写操作都是在内存中完成的,具有高性能高并发的特点，可以用来作为缓存降低mysql数据库的压力，还可以用来做分布式锁以及轻量级消息队列等

与Memcached的区别

具备许多Memcached不具备的功能，多种可满足不同需求的数据类型，数据持久化，原生集群

为什么用 Redis 作为 MySQL 的缓存

Redis具有高性能与高并发的特性可以提前将部分MySql中存储的数据存储到 Redis中进行数据访问时直接访问Redis即可即使在高并发的场景下也可以做到较快的响应速度避免大量请求直接访问MySql导致服务宕机

二.Redis中的数据结构

Redis具有哪些基础数据结构

Redis具有七种基础数据结构，其中六种基本数据结构以及RedisObject，Redis中的所有数据类型都封装在RedisObject中

SDS动态字符串

Redis是利用C语言开发的由于c语言原生的字符串具有非二进制安全,不可修改等缺点，构建了全新的字符串结构 SDS动态字符串

SDS实际是C语言中的结构体分为Header与字符串数组两部分实际数据保存在字符数组中Header中保存字符串已经占用的字节数申请的总字节数 SDS类型(控制可保存数据的上限) 通过头信息可以可以直接得知数组长度无需再受'\0'的影响还具有动态扩容的能力解决了c语言原生字符串不可修改二进制安全等问题

动态扩容: 当SDS申请的空间不足以容纳要添加的新字符串时则会申请新的内存空间根据新字符串的大小还会有不同的申请方式(小于1M 新字符串长度2倍+1 大于1M 新字符串长度+1M+1)

IntSet 整数数组

InSet结构体 encoding编码方式决定存放整数大小范围 length记录存放元素个数 contents指针指向实际数组起始地址长度可变有序

编码升级:当即将添加的元素超过了当前编码方式每个元素可表示的范围，就会发生编码升级，每个元素占用的字节数会改变，按新的编码方式进行数组扩容，倒序将数组中的旧元素拷贝到正确位置(正序拷贝会覆盖原数据)，将待添加的元素添加到末尾最后更改结构体中的encoding(编码方式) 以及length

Inset的元素是唯一有序的，具备升级机制，当元素小时采用占用内存空间小的编码方式元素过大时才会升级编码节省内存空间，底层采用二分查找查询元素，不适合存储大量数据,数据量大查询效率低且InSet申请的是连续内存空间 数据量大时不便申请较大的连续内存空间

Dict字典(数组+单向链表)

Dict内部维护了一个指向哈希表数组的指针，实际数据都存储在哈希表数组的元素DictEntry中，每个节点都包含key value next(哈希冲突时升级成链表)，内部有两张哈希表，一张用于存储现有数据另一张用于rehash

Rehash：当负载因子(哈希数组长度/已存储元素) >=1，表示hash数组已存满，再存储数据必然会出现哈希冲突升级为链表，避免链表出现，链表过长影响存储性能，则需要进行rehash；rehash的时机: Redis本身没有进行需要消耗算力资源的后台进程例如 BGSAVE(异步RDB持久化) BGREWRITEAOF(AOF重写)或负载因子大于5 直接扩容；当删除元素时，检查负载因子，负载因子<0.1时哈希表收缩

渐进式rehash: 当哈希表负载因子超过阈值时，会分配一个更大的新哈希表 ht[1]，并设置 rehashidx=0标记迁移起点；随后在每次数据访问时，Redis 会顺带将 ht[0] 中 rehashidx 位置的键值对迁移到 ht[1]，并递增rehashidx，同时新数据直接写入 ht[1](如果有数据写入操作)；当所有数据迁移完成后，释放 ht[0] 并将 ht[1] 设为新的主表，完成平滑扩容或缩容。避免因扩容造成阻塞，Redis对底层数据结构优化的代表性实例。

Dict字典，底层利用hash表存储数据，精确查询性能好，但会产生内存碎片，且内部维护了较多指针，指针本身会占据较多内存空间

ZipList压缩链表

便于首尾操作:每个元素占用空间不定需要多少占多少节省内存，连续内存空间头部维护了几个变量分别记录了当前ZipList占用的总内存空间，尾偏移量记录尾节点距离其实地址有多少字节，可以确定尾节点地址；由于头部变量占用的字节数固定，且记录了链表总占用内存空间，以及尾偏移量记录了起始到最后一个起点起始之间的空间，所以可以方便的得出第一个元素与最后一个元素的地址，便于头尾操作

Entry内部结构: previous 记录前一个节点的总长度 encoding编码属性记录 contents的数据类型(字符串或整数) 以及contents的长度 contents 节点保存的数据;既不满足数组遍历规律也不满足链表遍历规律,通过记录每个节点的长度遍历

缺点: 连续内存空间不便于存储大量数据,随机读取性能差,存在连锁更新问题

连锁更新: 若一个ZipList中保存了N个连续的长度为250~253字节的entry其长度,刚好不超过254 则每个entry只需要1字节记录上一个entry的长度,假如此时在第一个entry前插入了一个,长度大于等于254字节的元素,那么此时该entry的长度用1字节就无法表示，需要用5 字节表示，那么下一个entry的pre就由1字节变更为5字节，那么其本身的长度也会增大，表示其长度也需要5字节，就导致了联锁反应，之后的每个entry都需要改变其占用的内存空间，导致频繁的产生内存的申请销毁数据迁移