我们应该从 Redis 是如何保存数据的原理展开,分析键值对的存储结构和原理。
从而继续延展出每种数据类型底层的数据结构,针对不同场景使用更恰当的数据结构和编码实现更少的内存占用。
为了保存数据, Redis 需要先申请内存,数据过期或者内存淘汰需要回收内存,从而拓展出内存碎片优化。
最后,说下 key、value 使用规范和技巧、 Bitmap 等高阶数据类型,运用这些技巧巧妙解决有限内存去存储更多数据难题……
这一套组合拳下来直接封神。
具体详情,且看「码哥」一一道来。
主要优化神技如下:
- 键值对优化。
- 小数据集合的编码优化。
- 使用对象共享池。
- 使用 Bit 比特位或 byte 级别操作。
- 使用 hash 类型优化。
- 内存碎片优化。
- 使用 32 位的 Redis。
在优化之前,我们先掌握 Redis 是如何存储数据的。
Redis 如何存储键值对
Redis 以 redisDb为中心存储,redis 7.0 源码在 https://github.com/redis/redis/blob/7.0/src/server.h:
redisDb
- dict:最重要的属性之一,就是靠这个定义了保存了对象数据键值对,dcit 的底层结构是一个哈希表。
- expires:保存着所有 key 的过期信息。
- blocking_keys 和 ready_keys 主要为了实现 BLPOP 等阻塞命令。
- watched_keys用于实现watch命令,记录正在被watch的一些key,与事务相关。
- id 为当前数据库的id,redis 支持单个服务多数据库,默认有16个。
- clusterSlotToKeyMapping:cluster 模式下,存储key 与哈希槽映射关系的数组。
Redis 使用「dict」结构来保存所有的键值对(key-value)数据,这是一个全局哈希表,所以对 key 的查询能以 O(1) 时间得到。
所谓哈希表,我们可以类比 Java 中的 HashMap,其实就是一个数组,数组的每个元素叫做哈希桶。
dict 结构如下,源码在 https://github.com/redis/redis/blob/7.0/src/dict.h:
复制
struct dict {
// 特定类型的处理函数
dictType *type;
// 两个全局哈希表指针数组,与渐进式 rehash 有关
dictEntry **ht_table[2];
// 记录 dict 中现有的数据个数。
unsigned long ht_used[2];
// 记录渐进式 rehash 进度的标志, -1 表示当前没有执行 rehash
long rehashidx;
// 小于 0 表示 rehash 暂停
int16_t pauserehash;
signed char ht_size_exp[2];
};
- dictType:存储了hash函数,key和value的复制等函数。
- ht_table:长度为 2 的 数组,正常情况使用 ht_table[0] 存储数据,当执行 rehash 的时候,使用 ht_table[1] 配合完成 。
key 的哈希值最终会映射到 ht_table 的一个位置,如果发生哈希冲突,则拉出一个哈希链表。
大家重点关注 dictEntry 类型的 ht_table,ht_table 数组每个位置我们也叫做哈希桶,就是这玩意保存了所有键值对。
码哥,Redis 支持那么多的数据类型,哈希桶咋保存?
哈希桶的每个元素的结构由 dictEntry 定义:
复制
typedef struct dictEntry {
// 指向 key 的指针
void *key;
union {
// 指向实际 value 的指针
void *val;
uint64_t u64;
int64_t s64;
double d;
} v;
// 哈希冲突拉出的链表
struct dictEntry *next;
} dictEntry;
- key 指向键值对的键的指针,key 都是 string 类型。
- value是个 union(联合体)当它的值是 uint64_t、int64_t 或 double 类型时,就不再需要额外的存储,这有利于减少内存碎片。(为了节省内存操碎了心)当然,val 也可以是 void 指针,指向值的指针,以便能存储任何类型的数据。
- next指向另一个 dictEntry 结构, 多个 dictEntry 可以通过 next 指