《Redis设计与实现》读书笔记

吃花椒的妙酱

已于 2024-10-01 18:18:14 修改

阅读量153

点赞数 2

文章标签： redis 数据结构

于 2024-09-06 23:43:45 首次发布

本文链接：https://blog.csdn.net/m0_53688600/article/details/141978928

版权

7.2 压缩节点连锁更新的问题

一个节点由三部分组成：记录上个节点字节数的pre_entry_len、记录内容的content以及记录当前节点属性的encoding。

由于每个节点的pre_entry_len部分会记录上一个节点占用的字节数。当content从250 -> 253字节时，会引发下一个节点的pre_entry_len更新，由此下个节点的字节数增加，从而可能引发下下一个节点的pre_entry_len更新，由此最坏情况下节点更新的复杂度为O(n)，但这种可能性极小。可以忽略不计。

8.对象

redis中维护的数据都不是直接用五种数据结构存储的，而是用对象。

set的key和value都是用对象维护的

typedef struct redisObject{
    // 类型 五种基本类型string, list, hash, set, zset
    unsigned type:4;
    // 编码 eg.整数值实现的字符串、SDS实现的字符串，即不同实现模式的基本类型
    // 压缩列表实现的zset，跳表实现的zset
    unsigned encoding:4;
    // 指向底层实现数据结构的指针
    void *ptr;
    // 引用计数
    int refcount;
    // 记录最后一次被访问的时间
    unsigned lru:32;
}

开始比较疑惑有了type:4字段还要encoding:4作甚，对于存储的值类型还是要用不同实现方法的基本类型，具体场景具体分析的方法论还是有道理的。

long double类型在redis是以字符串存储的。若用数字类型存储，可能在不同平台传输可能丢精度，用字符串保证了这种情况不会发生。

不同编码实现的基本存储结构，对应函数的实现可能不同。例如int编码的字符串和embetr、raw编码的字符串的STRLEN函数，int编码需要先将数值转成的字符串再计算字符串长度，而embetr、raw编码的字符串调用sdslen函数即可，而sdslen我们知道是O(1)的。

列表有ziplist和linkedlist两种编码

最大的不同之处在于ziplist直接存的字符串，而linkedlist存的是StringObject对象。

使用场景：ziplist用于短小的list存储。具体使用条件——存储的字符串大小 < 64字节且元素数量小于512。

看了下ziplist编码使用的list的“LSET”命令，是先删除节点再插入节点，而linkedlist是直接覆盖，这点符合直觉的。为什么ziplist要这样做，考虑要保持内存连续性，先删除再插入可以触发内存分配重排机制。我也不是很清楚为什么直接赋值不行，可能偏低层吧，而且通常覆盖操作是不会完全删除原来数据，比如"123" 改成 "1"，考虑到性能，让我实现的话会记录下新字符串的长度和字符串首地址，旧数据不会马上从内存中删除，而是积攒一部分数据后再集体删除。（以上都是我口胡的）

哈希对象的编码有ziplist和hashtable，hashtable是用字典实现的。

ziplist编码实现的哈希，其实就是暴力找呗。适用场景是元素数量小于512，这也符合直觉，没啥好说的。

hashtable编码也不过赘述了，前面讲字典时具体介绍了。