1、redis特点
redis是一个key-value内存数据库,key和value的最大长度限制是512M,有以下特点:
(1)性能极高,读的速度是110000次/s,写的速度是81000次/s。
(2)支持数据的持久化。
(3)支持丰富的数据类型。
(4)支持数据备份(master-slave)。
(5)所有单个操作都是原子的,多操作支持事务。
(6)其他高级特性:发布与订阅、二进制位数组、慢日志查询等。
CentOS7 安装 Redis 单实例 https://gper.club/articles/7e7e7f7ff7g5egc4g6b
Docker 安装Redis 集群 https://gper.club/articles/7e7e7f7ff7g5egc5g6c
2、redis数据结构与数据对象
redis底层实现了很多中数据结构,如:简单动态字符串(SDS)、链表、字典(dict)、跳跃表、整数集合、压缩列表(ziplist)。redis并不是直接使用这些数据结构来存储键值对,而是基于这些数据结构实现了一个对象系统,包括字符串对象、列表对象、哈希对象、集合对象、有序集合对象五中类型。
使用对象的好处:
1)根据对象类型,可以直接判断是否可以执行给定的命令。
2)针对不同的使用场景,可以根据对象的类型动态地选择存储结构和可以使用的命令,实现节省空间和优化查询速度。
3)redis实现了基于引用计数的内存回收机制,当程序不再引用某个对象的时候,这个对象就会被回收。
4)对象共享机制,在适当的条件下,让多个键共享一个对象来节约内存。
5)redis对象带有访问时间记录信息,用于计算键的空转时长,如果服务器启用了maxmemory功能,空转时长较大的键可能会优先被服务器删除。
redis中对象的定义:redisObject
typedef struct redisObject{ unsigned type:4;/* 对象的类型,包括:REDIS_STRING、REDIS_LIST、REDIS_HASH、REDIS_SET、REDIS_ZSET*/ unsigned encoding:4;/* 具体的数据结构 */ unsigned lru:LRU_BITS;/*24 位,对象最后一次被命令程序访问的时间,与内存回收有关 */ int refcount;/* 引用计数。当 refcount 为 0 的时候,表示该对象已经不被任何对象引用,则可以进行垃圾回收了 */ void *ptr;/* 指向对象实际的数据结构 */ }robj;
对象类型和编码:
3、redis数据库底层数据模型
redis数据库使用字典作为底层实现,字典dict的定义:
typedef struct dict{ dictType *type;/* 字典类型 */ void *privdata;/* 私有数据 */ dicththt[2];/* 一个字典有两个哈希表 */ long rehashidx;/*rehash 索引 */ unsigned long iterators;/* 当前正在使用的迭代器数量 */ }dict;
字典底层是通过哈希表(hashtable)实现的,字典中hashtable的定义:
typedef struct dictht{ //哈希表数组 dictEntry **table; //哈希表大小 unsigned long size; //哈希表大小掩码,用于计算索引值,总是等于size-1 unsigned long sizemask; //该哈希表已有节点的数量 unsigned long used; }dictht;
哈希表中节点的定义为dictEntry,每个哈希表节点(dictEntry)保存了一个键值对,dictEntry的定义:
typedef struct dictEntry{ void*key;/*key 关键字定义 */ union{ void*val; uint64_tu64;/*value 定义 */ int64_ts64; doubled; }v; struct dictEntry*next;/* 指向下一个键值对节点 */
}dictEntry;
在向字典中插入新的键值对时,先根据键值对的键计算出哈希值和索引值,然后再根据索引值,将包含新键值对的哈希节点(dictEntry)放到哈希表数组的指定索引上面。
字典存储结构:从最底层到最高层 dictEntry——dictht——dict。
dict会定义两个哈希表,默认使用 ht[0],ht[1]不会初始化和分配空间,其用于扩展与收缩。
* 解决键冲突
当有两个以上的键被分配到哈希表数组的同一个索引上面时,就会发生键冲突。redis的哈希表使用链地址法(separate chaining)来解决键冲突(类似于hashMap),每个dictEntry都有一个 next 指针,多个 dictEntry 节点通过 next 指针构成一个单向链表,被分配到同一个索引上的dictEntry 以链表的方式连接起来。
* 哈希表的扩展和收缩
哈希表的扩展与收缩取决于哈希表的负载因子,负载因子定义:
load_factor = ht[0].used / ht[0].size , 即 负载因子 = 哈希表已保存的节点数量 / 哈希表大小
当以下条件中的任意一个被满足时,程序会自动对哈希表进行扩展操作:
1)服务器目前没有在执行BGSAVE或者BGREWRITEAOF命令,并且哈希表的负载因子大于等于1;
2)服务器目前正在执行BGSAVE或者BGREWRITEAOF命令,并且哈希表的负载因子大于等于5。
因为在执行BGSAVE或者BGREWRITEAOF的过程中,redis需要创建子进程,为了提高子进程的使用率,服务器会提高执行扩展所需的负载因子,尽量避免子进程存在期间进行哈希表的扩展操作。(大多数操作系统会使用写时复制技术来优化子进程的使用,此时扩展数据转移会增加不必要的内存写入)
当哈希表的负载因子小于0.1时,程序会自动对哈希表进行收缩。
* 扩展与收缩的步骤
扩展与收缩哈希表通过rehash(重新散列)操作来完成。步骤如下:
1)为字典的 ht[1] 哈希表分配空间,空间大小取决于要执行的操作,以及 ht[0] 当前包含的键值对数量(即 ht[0].used 属性值)
如果执行扩展操作,那么 ht[1] 的大小为第一个大于等于 ht[0].used * 2 的2n;(如 ht[0].used = 3,ht[1] 的大小就是8,因为8是大于等于6的第一个2的3次幂)
如果执行收缩操作,那么 ht[1] 的大小为第一个大于等于 ht[0].used 的2n。
2)将保存在 ht[0] 中的所有键值对rehash 到 ht[1]上面:rehash指的是重新计算键的哈希值和索引值,然后将键值对放在 ht[1] 指定的位置上。
3)当 ht[0] 包含的所有键值对都迁移到了 ht[1] 之后(ht[0] 变为空表),释放 ht[0],将 ht[1] 设置为 ht[0],并在 ht[1] 新创建一个空哈希表,为下次rehash做准备。
4、数据类型(数据对象)
4.1、String字符串
(1)存储类型
可以用来存储字符串、整数、浮点数。
(2)实现原理
key是字符串,redis并没有直接使用C 的字符数组,而是存储在自定义的SDS(简单动态字符串)中。value则存储在redisObject中。内部编码如下:
字符串类型的内部编码有三种:
1)int,存储8个字节的长整型(long,2^63-1)。
2)embstr,代表embstr格式的SDS,存储小于44个字节的字符串。
3)raw,存储大于44个字节的字符串。
* 什么是SDS?
redis中字符串的实现,在3.2以后的版本中,SDS又有多种结果(sds.h):sdshdr5、sdshdr8、sdshdr16、sdshdr32、sdshdr64,用于存储不同长度的字符串,分别代表2^5=32byte,2^8=256byte,2^16=65536byte=64KB,2^32byte=4GB。
/*sds.h*/ struct__attribute__ ((__packed__)) sdshdr8{ uint8_tlen;/* 当前字符数组的长度 */ uint8_talloc;/*当前字符数组总共分配的内存大小 */ unsignedcharflags;/* 当前字符数组的属性、用来标识到底是 sdshdr8 还是 sdshdr16 等 */ charbuf[];/* 字符串真正的值 */ };
* redis为什么用SDS实现字符串?
C语言本身没有字符串类型(只能用字符数组char[]实现),但是作为字符串的实现会有很多弊端:
1)使用字符数组必须先给目标变量分配足够的空间,否则可能会溢出。
2)如果要获取字符长度,必须遍历字符数组,时间复杂度是O(n)。
3)C字符串长度的变更会对字符数组做内存重分配。
4)通过从字符串开始到结尾碰到的第一个' '来标记字符串的结束,因此不能保存图片、音频、视频、压缩文件等二进制(bytes)保存的内容,二进制不安全。
SDS的特点:
1)不用担心内存溢出问题,如果需要会对SDS进行扩容。
2)获取字符串长度时间复杂度为O(1),因为定义了len属性。
3)通过“空间预分配”( sdsMakeRoomFor)和“惰性空间释放”,防止多次重分配内存。
4)判断是否结束的标志是len属性(它同样以' '结尾是因为这样就可以使用C语言中函数库操作字符串的函数了),可以包含' '。
* embstr和raw的区别?
embstr 的使用只分配一次内存空间(因为RedisObject 和SDS是连续的), 而 raw需要分配两次内存空间(分别为RedisObject和SDS分配空间)。因此与 raw 相比,embstr 的好处在于创建时少分配一次空间,删除时少释放一次空间,以及对象的所有数据连在一起,寻找方便。而 embstr 的坏处也很明
显,如果字符串的长度增加需要重新分配内存时,整个RedisObject和SDS都需要重新分配空间,因此 Redis 中的 embstr 实现为只读。
* 编码转换
当 int 数 据 不 再 是 整 数 , 或 大 小 超 过 了 long 的 范 围时,自动转化为 embstr;如果embstr编码的字符串进行修改,自动转换为raw类型后再进行修改,因此,只要是修改 embstr 对象,修改后的对象一定是 raw 的,无论是否达到了 44个字节。编码转换是在redis写数据时完成的,是不可逆的(不包
含重新set)。
4.2、Hash哈希
(1)存储类型
包含键值对的无序散列表。value只能是字符串,不能嵌套其他类型(字符串也是唯一可以嵌套的对象类型)。同样是存储字符串,Hash 与 String的主要区别:
1)把所有相关的值聚集到一个key中,节省内存空间
2)只使用一个key,减少key冲突
3)当需要批量获取值的时候,只需要使用一个命令,减少内存/IO/CPU的消耗
Hash不适合的场景:
1)Field不能单独设置过期时间
2)没有bit操作
3)需要考虑数据量分布的问题(value值非常大的时候,无法分布到多个节点)
(2)实现原理
Hash类型可以使用两种数据结构实现:ziplist(压缩列表):REDIS_ENCODING_ZIPLIST,hashtable(哈希表):REDIS_ENCODING_HT。
hashtable是一个数组+链表的结构,在前面已经分析过。
* ziplist压缩列表
ziplist是一个经过特殊编码的双向链表(连续的空间),它不存储指向上一个链表节点和指向下一个链表节点的指针,而是存储上一个节点的长度和当前节点的长度。通过牺牲部分读写性能,来换取高效的内存空间利用率,是一种时间换空间的思想,只用在字段个数少,字段值小的场景里。
1)内部结构与定义
typedef struct zlentry{ unsigned int prevrawlensize;/* 上一个链表节点占用的长度 */ unsigned int prevrawlen; /* 存储上一个链表节点的长度数值所需要的字节数 */ unsigned int lensize; /* 存储当前链表节点长度数值所需要的字节数 */ unsigned int len; /* 当前链表节点占用的长度 */ unsigned int headersize; /* 当前链表节点的头部大小(prevrawlensize+lensize),即非数据域的大小 */ unsigned char encoding; /* 编码方式 */ unsigned char *p; /* 压缩链表以字符串的形式保存,该指针指向当前节点起始位置 */ }zlentry;
2)Hash对象什么时候使用ziplist存储?
当hash对象同时满足以下两个条件的时候,使用ziplist编码:
——所有的键值对的健和值的字符串长度都小于等于64byte(一个英文字母一个字节);
——哈希对象保存的键值对数量小于512个。
一个哈希对象超过配置的阈值(键和值的长度有>64byte,键值对个数>512个)时,会转换成哈希表(hashtable)。
4.3、List列表
(1)存储类型
存储有序的字符串(从左到右),元素可以重复。可以充当队列和栈的角色。如下:
(2)实现原理
3.2版本之前,数据量较小时用ziplist存储,达到临界值时转换为linkedlist进行存储,分别对应REDIS_ENCODING_ZIPLIST和REDIS_ENCODING_LINKEDLIST。
3.2版本之后,统一用quicklist来存储。quicklist为一个双向链表,每个节点都是一个ziplist。
* quicklist(快速列表)
quicklist是ziplist和linkedlist的结合体,外层是一个双向链表(linkedlist),linkedlist中每个节点都是一个压缩列表(ziplist)。定义如下:head和tail指向双向列表的表头和表尾。
typedef struct quicklist { quicklistNode *head; /* 指向双向列表的表头 */ quicklistNode *tail; /* 指向双向列表的表尾 */ unsigned long count; /* 所有的 ziplist 中一共存了多少个元素 */ unsigned long len; /* 双向链表的长度,node 的数量 */ int fill : 16; /* fill factor for individual nodes */ unsigned int compress : 16; /* 压缩深度,0:不压缩; */ } quicklist;
quicklistNode中的*zl指向一个ziplist,一个ziplist可以存放多个元素。
typedef struct quicklistNode { struct quicklistNode *prev; /* 前一个节点 */ struct quicklistNode *next; /* 后一个节点 */ unsigned char *zl; /* 指向实际的 ziplist */ unsigned int sz; /* 当前 ziplist 占用多少字节 */ unsigned int count : 16; /* 当前 ziplist 中存储了多少个元素,占 16bit(下同),最大 65536 个 */ unsigned int encoding : 2; /* 是否采用了 LZF 压缩算法压缩节点,1:RAW 2:LZF */ unsigned int container : 2; /* 2:ziplist,未来可能支持其他结构存储 */ unsigned int recompress : 1; /* 当前 ziplist 是不是已经被解压出来作临时使用 */ unsigned int attempted_compress : 1; /* 测试用 */ unsigned int extra : 10; /* 预留给未来使用 */ } quicklistNode;
4.4、Set集合
(1)存储类型
String类型的无序集合,最大存储数量2^32-1(40亿左右)。
(2)实现原理
redis用 intset(整数集合) 或 hashtable 存储set。如果元素都是整数类型,就用 intset存储。如果不都是整数类型,就用 hashtable(数组+链表)。如果元素数量超过512个,也会用 hashtable存储。
* KV如何存储set集合元素?
key就是元素值,value为null。
4.5、ZSet有序集合
(1)存储类型
sorted set,有序的set,每个元素有个score,score相同时,按照key的ASCII码排序。
(2)实现原理
ZSet使用 ziplist 或 skiplist(跳跃表)+dict存储。同时满足以下条件时才使用ziplist,否则使用 skiplist+dict:
1)元素数量小于128个;
2)所有元素的长度都小于64字节。
在ziplist内部,按照score排序递增来存储,插入的时候要移动后面的元素。
ZSet使用skiplist+dict存储的结构如下:
zset的定义如下:
typedef struct zset{ dict *dict; /* 字典结构 */ zskiplist *zsl; /* 跳跃表 */ }zset;
跳跃表 zskiplist 的定义:
typedef struct zskiplist{ struct zskiplistNode *header, *tail;/* 指向跳跃表的头结点和尾节点 */ unsigned long length; /* 跳跃表的节点数 */ int level;/* 最大的层数 */ }zskiplist;
跳跃表节点 zskiplistNode的定义:
typedef struct zskiplistNode{ sds ele;/*zset 的元素 */ double score;/* 分值 */ struct zskiplistNode*backward;/* 后退指针 */ struct zskiplistLevel{ struct zskiplistNode*forward;/* 前进指针,对应 level 的下一个节点 */ unsigned long span;/* 从当前节点到下一个节点的跨度(跨越的节点数) */ }level[];/* 层 */ }zskiplistNode;
1)跳跃表按score分值从小到大存储元素,可以通过跳跃表对有序集合进行范围型操作,如zrank、zrange就是基于跳跃表API实现的。
2)zset结构中dict为有序集合创建了一个从成员到分值的映射,每个字典的键值对保存了一个元素,键就是元素的成员,值就是元素的分值。通过字典,可以用O(1)复杂度找到给定成员
的分值,如zscore就是基于这个原理。
3)有序集合元素的成员是一个字符串对象,元素的分值是一个double类型的浮点数。
4)虽然zset同时使用skiplist和dict保存了集合元素,但这两种数据结构都会通过指针来共享相同元素的成员和分值,所以不会产生任何重复的成员或分值,也不会因此浪费额外的内存。
* skiplist 跳跃表
先来看一下有序链表:
在这样一个链表中,如果要查找某个数据,那么需要从头开始逐个进行比较,直到找到包含数据的那个节点,或者找到第一个比给定数据大的节点为止(没找到)。也就是说,时间
复杂度为O(n)。同样,当要插入新数据的时候,也要经历同样的查找过程,从而确定插入位置。而二分查找法只适用于有序数组,不适用于链表。
假如每相邻两个节点增加一个指针,让指针指向下下个节点,如下为两层的跳跃表结构:
这样所有新增加的指针连成了一个新的链表,但它包含的节点个数只有原来的一半(上图中是7, 19, 26)。在插入一个数据的时候,决定要放到那一层,取决于一个算法(在redis中
t_zset.c 有一个zslRandomLevel这个方法)。
现在当想查找数据的时候,可以先沿着这个新链表进行查找。当碰到比待查数据大的节点时,再回到原来的链表中的下一层进行查找。比如,想查找23,查找的路径是沿着下图中标红的
指针所指向的方向进行的:
1) 23首先和7比较,再和19比较,比它们都大,继续向后比较。
2) 但23和26比较的时候,比26要小,因此回到下面的链表(原链表),与22比较。
3) 23比22要大,沿下面的指针继续向后和26比较。23比26小,说明待查数据23在原链表中不存在
在这个查找过程中,由于新增加的指针,我们不再需要与链表中每个节点逐个进行比较了。需要比较的节点数大概只有原来的一半。这就是跳跃表。
为什么不用AVL树或者红黑树?因为skiplist更加简单,但是效率是差不多的。
4.6、其他数据结构
(1)BitMap
Bitmap是在字符串类型上面定义的位操作。一个字节由8个二进制位组成。GETBIT 命令用于返回位数组 bitarray
在 offset
偏移量上的二进制位的值:
GETBIT key <offset>
GETBIT 命令的执行过程如下:
1)计算 , byte
值记录了 offset
偏移量指定的二进制位保存在位数组的哪个字节。
2)计算 , bit
值记录了 offset
偏移量指定的二进制位是 byte
字节的第几个二进制位。
3)根据 byte
值和 bit
值, 在位数组 bitarray
中定位 offset
偏移量指定的二进制位, 并返回这个位的值。
如下例子:GETBIT key 10 将执行以下操作:
1) 的值为 1
2) 的值为 3
。
3)定位到 buf[1]
字节上面, 然后取出该字节上的第 3
个二进制位的值。
4)向客户端返回二进制位的值 0
。
命令的执行过程如图所示:
(2)Hyperloglogs
提供了一种不太准确的基数统计方法,比如统计网站的UV,存在一定的误差。
(3)Streams
5.0推出的数据类型。支持多播的可持久化的消息队列,用于实现发布订阅功能,借鉴了kafka的设计。