从数据存储角度分析Redis性能为何如此高

胸藏文墨怀若谷，腹有诗书气自华

前言

Redis作为一种KV缓存服务器，有着极高的性能，相对于memcache，Redis支持更多中数据类型，因此在业界广泛应用。

正文

记得笔者刚毕业那会参加面试，面试官会问我Redis为什么快，由于当时技术水平有限，我只能回答出如下两点：

数据是存储在内存中的。
Redis是单线程的。

当然，将数据存储在内存中，读取的时候后不需要进行磁盘的IO，单线程也保证了系统没有线程的上下文切换。

但这两点只是Redis高性能原因的很小一部分，下面的内容，笔者为大家从数据存储层面上分析Redis性能为何如此高。

Redis性能如此高的原因，我总结了如下几点

纯内存操作
单线程
高效的数据结构
合理的数据编码
其他方面的优化

在Redis中，常用的5中数据结构和应用场景如下：

String：缓存、计数器、分布式锁等
List：链表、队列、微博关注人世间轴列表等
Hash：用户信息、Hash表等
Set：去重、赞、踩、共同好友等
Zset：访问量排行榜、点击量排行榜等

SDS

Redis是用C语言开发完成的，但在Redis字符串中，并没有使用C语言中的字符串，而是用一种称为SDS（simple dynamic string）的结构体来保存字符串，SDS的结构如下

struct sdshdr {

    int len;

    int free;

    char buf[];
};

len：用于记录buf中已使用空间的长度

free：buf中空闲空间的长度

buf[]：存储实际内容

例如：执行命令set key value，key和value都是一个SDS类型的结构存储在内存中

二、SDS与C字符串的区别

1、常数时间内获得字符串长度

C字符串本身不记录长度信息，每次获取长度信息都需要遍历整个字符串，复杂度为O(n)
C字符串遍历时遇到'\0'时结束
SDS中len字段保存着字符串的长度，所以总能在常数时间内获取字符串长度，复杂度是O(1)

2、避免缓冲区溢出

假设在内存中有两个紧挨着的两个字符串，s1=“xxxxx”和s2=“yyyyy”，由于在内存上紧紧相连，当我们对s1进行扩充的时候，将s1=“xxxxxzzzzz”后，由于没有进行相应的内存重新分配，导致s1把s2覆盖掉，导致s2被莫名其妙的修改

但SDS的API对zfc修改时首先会检查空间是否足够，若不充足则会分分配新空间，避免了缓冲区溢出问题。

3、减少字符串修改时带来的内存重新分配的次数

在C中，当我们频繁的对一个字符串进行修改（append或trim）操作的时候，需要频繁的进行内存重新分配的操作，十分影响性能。如果不小心忘记，有可能会导致内存溢出或内存泄漏，对于Redis来说，本身就会很频繁的修改字符串，所以使用C字符串并不合适。而SDS实现了空间预分配和惰性空间释放两种优化策略

空间预分配

当SDS的API对一个SDS修改后，并且对SDS空间扩充时，程序不仅会为SDS分配所需要的必须空间，还会分配额外的未使用空间，分配规则如下：

如果对SDS修改后，len的长度小于1M，那么程序将分配和len相同长度的未使用空间。举个例子，如果len=10，重新分配后，buf的实际长度会变为10(已使用空间)+10(额外空间)+1(空字符)=21。

如果对SDS修改后len长度大于1M，那么程序将分配1M的未使用空间

惰性空间释放

当对SDS进行缩短操作时，程序并不会回收多余的内存空间，而是使用free字段将这些字节数量记录下来不释放，后面如果需要append操作，则直接使用free中未使用的空间，减少了内存的分配。

4、二进制安全

在Redis中不仅可以存储String类型的数据，也可能存储一些二进制数据。二进制数据并不是规则的字符串格式，其中会包含一些特殊的字符如'\0'，在C中遇到'\0'则表示字符串的结束，但在SDS中，标志字符串结束的是len属性。

字典

与JAVA中的HashMap类似，Redis中的Hash比JAVA中的更高级一些。Redis本身就是KV服务器，除了Redis本身数据库之外，字典也是哈希键的底层实现，字典的数据结构如下所示

typedef struct dict{
    dictType *type;
    void *privdata;
    dictht ht[2];
    int trehashidx;
}

typedef struct dictht{
    //哈希表数组
    dectEntrt **table;
    //哈希表大小
    unsigned long size;
    //
    unsigned long sizemask;
    //哈希表已有节点数量
    unsigned long used;
}

重要的两个字段是dictht和trehashidx，这两个字段与rehash有关，下面重点介绍rehash。

一、Rehash

学过JAVA的朋友都应该知道HashMap是如何rehash的，在此处我就不过多赘述，下面介绍redis中Rehash的过程。

由上段代码，我们可知dict中存储了一个dictht的数组，长度为2，表名这个数据结构中实际存储着两个哈希表ht[0]和ht[1]，为什么要存储两张hash表呢？？当然是为了rehash，rehash的过程如下：

1）为ht[1]分配空间

如果是扩容操作，ht[1]的大小为第一个大于等于ht[0].used*2的2^n；
如果是缩容操作，ht[1]的大小为第一个大于等于ht[0].used的2^n；

2）将ht[0]中的键值rehash到ht[1]中

3）当ht[0]全部迁移到ht[1]中后，释放ht[0]，将ht[1]置为ht[0]，并为ht[1]创建一张新表，为下次rehash做准备

二、渐进式Rehash

由于Redis是的rehash操作是将ht[0]中的键值全部迁移到ht[1]，如果数据量小，则迁移过程很快，但如果数据量很大，一个hash表中存储了几万甚至几百万几千万的键值时，迁移过程很慢并会影响到其他用户的使用，为了避免rehash对服务器性能造成影响，Redis采用了一种渐进式Rehash的策略，分多次、渐进的将ht[0]中的数据迁移到ht[1]中，前一过程如下：

为ht[1]分配空间，让字典同时拥有ht[0]和ht[1]两个哈希表
字典中维护一个rehashidx，并将它置为0，表示rehash开始
在rehash期间，每次对字典操作时，程序还顺便将ht[0]在rehashidx索引上的所有键值对rehash到ht[1]中，当rehash完成后，将rehashidx属性增一
当全部rehash完成后，将rehashidx置为-1，表示rehash完成

注意，由于维护了两张hash表，所以在rehash的过程中内存会增长。

另外，在rehash过程中，字典会同时使用ht[0] 和ht[1]，所以在删除、查找、更新时会在两张表中操作，在查询时会现在第一张表中查询，如果第一张表中没有，则会在第二张表中查询。但新增时一律会在ht[1]中进行，确保ht[0]中的数据只会减少不会增加。

跳跃表

zset是一个有序的链表结构，其底层的数据结构是跳跃表skiplist,其结构如下：

typedef struct zskiplistNode {
//成员对象
robj *obj;
//分值
double score;
//后退指针
struct zskiplistNode *backward;
//层
    struct zskiplistLevel {
        struct zskiplistNode *forward;//前进指针
        unsigned int span;//跨度
    } level[];
} zskiplistNode;

typedef struct zskiplist {
//表头节点和表尾节点
struct zskiplistNode *header, *tail;
//表中节点的的数量
unsigned long length;
//表中层数最大的节点层数
int level;
} zskiplist;

和普通链表的区别是：普通列表遍历时只能顺序遍历，而跳跃表的结构决定了其查询和速度很快，因为有前进指针、后退指针和跨度。

前进指针：用于从表头向表尾方向遍历。

后退指针：用于从表尾向表头方向回退一个节点，和前进指针不同的是，前进指针可以一次性跳跃多个节点，后退指针每次只能后退到上一个节点。

跨度：表示当前节点和下一个节点的距离，跨度越大，两个节点中间相隔的元素越多。

在查询过程中跳跃着前进。由于存在后退指针，如果查询时超出了范围，通过后退指针回退到上一个节点后仍可以继续向前遍历。

压缩列表

压缩列表ziplist是为Redis节约内存而开发的，是列表键和字典键的底层实现之一。当元素个数较少时，Redis用ziplist来存储数据，当元素个数超过某个值时，链表键中会把ziplist转化为linkedlist，字典键中会把ziplist转化为hashtable。

ziplist是由一系列特殊编码的连续内存块组成的顺序型的数据结构，ziplist中可以包含多个entry节点，每个节点可以存放整数或者字符串。

由于内存是连续分配的，所以遍历速度很快。

编码转化

Redis使用对象（redisObject）来表示数据库中的键值，当我们在Redis中创建一个键值对时，至少创建两个对象，一个对象是用做键值对的键对象，另一个是键值对的值对象，例如我们执行SET MSG XXX时，键值对的键是一个包含了字符串“MSG“的对象，键值对的值对象是包含字符串"XXX"的对象,redisObject的结构如下：

typedef struct redisObject{
    //类型
    unsigned type:4;

    //编码
    unsigned encoding:4;

    //指向底层数据结构的指针
    void *ptr;

    //...
}robj;

其中：

type字段记录了对象的类型，包含字符串对象、列表对象、哈希对象、集合对象、有序集合对象，当我们执行type key命令时返回的结果如下

ptr指针字段指向对象底层实现的数据结构，而这些数据结构是由encoding字段决定的，每种对象至少有两种数据编码

可以通过object encoding key来查看对象所使用的编码

细心的读者可能注意到，list、hash、zset三个键使用的是ziplist压缩列表编码，这就涉及到了Redis底层的编码转换。上面介绍到，ziplist是一种结构紧凑的数据结构，当某一键值中所包含的元素较少时，会优先存储在ziplist中，当元素个数超过某一值后，才将ziplist转化为标准存储结构，而这一值是可配置的。

一、String对象的编码转化

String对象的编码可以是int或raw，对于String类型的键值，如果我们存储的是纯数字，Redis底层采用的是int类型的编码，如果其中包括非数字，则会立即转为raw编码

127.0.0.1:6379> set str 1
OK
127.0.0.1:6379> object encoding str
"int"
127.0.0.1:6379> set str 1a
OK
127.0.0.1:6379> object encoding str
"raw"
127.0.0.1:6379>

二、List对象的编码转化

List对象的编码可以是ziplist或linkedlist，对于List类型的键值，当列表对象同时满足一下两个条件时采用ziplist编码

列表对象保存的所有字符串元素的长度都小于64字节
列表对象保存的元素个数小于512个

如果不满足这两个条件的任意一个，就会转化为linkedlist编码

注意：这两个条件是可以修改的，在redis.conf中

list-max-ziplist-entries 512
list-max-ziplist-value 64

三、Set类型的编码转化

Set对象的编码可以是intset或hashtable，intset编码的结婚对象使用整数集合作为底层实现，把所有元素都保存在一个整数集合里面。

127.0.0.1:6379> sadd set 1 2 3
(integer) 3
127.0.0.1:6379> object encoding set
"intset"
127.0.0.1:6379>

如果set集合中保存了非整数类型的数据时，Redis会将intset转化为hashtable

127.0.0.1:6379> sadd set 1 2 3
(integer) 3
127.0.0.1:6379> object encoding set
"intset"
127.0.0.1:6379> sadd set a
(integer) 1
127.0.0.1:6379> object encoding set
"hashtable"
127.0.0.1:6379>

当Set对象同时满足一下两个条件时，对象采用intset编码

保存的所有元素都是整数值（小数不行）
Set对象保存的所有元素个数小于512个

不能满足这两个条件的任意一个，Set都会采用hashtable存储

注意：第两个条件是可以修改的，在redis.conf中

set-max-intset-entries 512

四、Hash对象的编码转化

Hash对象的编码可以是ziplist或hashtable，当Hash以ziplist编码存储的时候，保存同一键值对的两个节点总是紧挨在一起，键节点在前，值节点在后

zlbytes

zltail

zllen

name

tom

age

career

programmer

zlend

当Hash对象同时满足一下两个条件时，Hash对象采用ziplist编码

Hash对象保存的所有键值对的键和值的字符串长度均小于64字节
Hash对象保存的键值对数量小于512个

如果不满足以上条件的任意一个，ziplist就会转化为hashtable编码

注意：这两个条件是可以修改的，在redis.conf中

hash-max-ziplist-entries 512
hash-max-ziplist-value 64

五、Zset对象的编码转化

Zset对象的编码可以是ziplist或zkiplist，当采用ziplist编码存储时，每个集合元素使用两个紧挨在一起的压缩列表来存储。第一个节点存储元素的成员，第二个节点存储元素的分值，并且按分值大小从小到大有序排列。

zlbytes

zltail

zllen

java

5.0

python

6.0

html

7.0

zlend

当Zset对象同时满足一下两个条件时采用ziplist编码

Zset保存的元素个数小于128
Zset元素的成员长度都小于64字节

如果不满足以上条件的任意一个，ziplist就会转化为zkiplist编码

注意：这两个条件是可以修改的，在redis.conf中

zset-max-ziplist-entries 128
zset-max-ziplist-value 64

思考：Zset如何做到O(1)复杂度内定位元素并且快速进行范围操作？

Zset采用skiplist编码时使用zset结构作为底层实现，该数据结构同时包含了一个跳跃表和一个字典，其结构如下：

typedef struct zset{
    zskiplist *zsl;
    dict *dict;
}

Zset中的dict字典为集合创建了一个从成员到分值之间的映射，字典中的键保存了成员，字典中的值保存了成员的分值，这样定位元素时时间复杂度是O(1)

Zset中的zsl跳跃表适合范围操作，比如ZRANK、ZRANGE等，程序使用zkiplist。

另外，虽然zset中使用了dict和skiplist存储数据，但这两种数据结构都会通过指针来共享相同的内存，所以没有必要担心内心的浪费。

过期数据的删除对Redis性能影响

当我们对某些key设置了expire时，数据到了时间会自动删除。如果一个键过期了，它会在什么时候删除呢？下面介绍三中删除策略

定时删除：在这是键的过期时间的同时，创建一个定时器Timer，让定时器在键过期时间来临时立即执行对过期键的删除。
惰性删除：键过期后不管，每次读取该键时，判断该键是否过期，如果过期删除该键返回空。
定期删除：每隔一段时间对数据库中的过期键进行一次检查。

定时删除：对内存友好，对CPU不友好。如果过期删除的键比较多的时候，删除键这一行为会占用相当一部分CPU性能，会对Redis的吞吐量造成一定影响。

惰性删除：对CPU友好，内存不友好。如果很多键过期了，但在将来很长一段时间内没有很合客户端访问该键导致过期键不会被删除，占用大量内存空间。

定期删除：是定时删除和惰性删除的一种折中。每隔一段时间执行一次删除过期键的操作，并且限制删除操作执行的时长和频率，具体的操作如下：

redis会将每一个设置了expire的键存储在一个独立的字典中，以后会定时遍历这个字典来删除过期的key。除了定时遍历外，它还会使用惰性删除策略来删除过期的key。
redis默认每秒进行十次过期扫描，过期扫描不会扫描所有过期字典中的key，而是采用了一种简单的贪心策略。

从过期字典中随机选择20个key
删除这20个key中已过期的key
如果过期key比例超过1/4，那就重复步骤1

同时，为了保证在过期扫描期间不会出现过度循环，导致线程卡死，算法还增加了扫描时间上限，默认不会超过25ms

总结

总而言之，Redis为了高性能，从各方各面都进行了优化，下次小伙伴们面试的时候，面试官问Redis为什么如此高，可不能傻傻的只说单线程和内存存储了，好了，这既是我这次给大家分享的内容，谢谢大家的阅读。关注我的微信公众号或加本人微信，可以获得更多技术干货。