本文是Redis成本优化系列文章的第2篇，这篇篇幅较少，但是是Redis内存优化的重要里程碑。

一、2个实验

写入1万条hash键值对：key为37字节、1000对field(f0..f99)-value(2字节)

写入1万条zset键值对：key为37字节、1000对score(10001到11001)-element(32字节)

初步结论：

• 3.2.13相比于3.0.7:

  • hash类型(hashtable实现)：Redis使用容量优化了28.2% (主要是Redis 3.2在sdshdr的优化，请参考[Redis成本优化-版本升级-1.SDS优化历史]
  • zset类型(hashtable + skiplist实现)：Redis使用容量优化了17.4% (主要是Redis 3.2在sdshdr的优化，请参考[Redis成本优化-版本升级-1.SDS优化历史]

• 4.0.14相比于3.2.13，

  • hash类型(hashtable实现)：Redis使用容量又优化了68.2%

  • zset类型(hashtable + skiplist实现)：Redis使用容量又优化了13.4%

    二、Redis 4重要优化

    相关releaseNotes如下：所有复杂类型(例如hash、list、set、zset)中的元素不再使用robj改为使用sds
    all the aggregated data types no longer use Redis Objects structures but directly SDS objects
    改动示意图如下：
    

    每个robj占用数据量: 4bit + 4bit + 24bit + 4字节 + 8字节 = 16字节

    define LRU_BITS 24

    typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or

    • LFU data (least significant 8 bits frequency
    • and most significant 16 bits access time). */

    int refcount;
    void *ptr;
    } robj;

三、结论

Redis可能没有打算在复杂数据结构的每个元素做一些功能，考虑到内存占用，所以在Redis 4做了上述优化，从实际看基本能满足大部分场景的需求，同时确实带来了很大的成本优化。

四、思考题

1. Redis的复杂数据结构，比如hash能否实现field级别的过期？
2. 4bit的type encoding如果不够用了怎么办？