Redis 概念以及底层数据结构
Redis 简介
REmote DIctionary Server(Redis) 是一个由SalvatoreSanfilippo写的key-value存储系统。
Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。
它通常被称为数据结构服务器,因为值(value)可以是字符串(String), 哈希(Map), 列表(list), 集合(sets) 和有序集合(sorted sets)等类型。
Redis特点
Redis 是完全开源免费的,遵守BSD协议,是一个高性能的key-value数据库。
Redis 与其他 key - value 缓存产品有以下三个特点:
-
Redis支持数据的持久化,可以将内存中的数据保持在磁盘中,重启的时候可以再次加载进行使用。
-
Redis不仅仅支持简单的key-value类型的数据,同时还提供list,set,zset,hash等数据结构的存储。
-
Redis支持数据的备份,即master-slave模式的数据备份。
Redis 优势
性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
丰富的数据类型 – Redis支持 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
原子 – Redis的所有操作都是原子性的,同时Redis还支持对几个操作全并后的原子性执行。
丰富的特性 – Redis 还支持 publish/subscribe, 队列,key 过期等等特性。
Redis对象类型简介
- Redis是一种key/value型数据库,其中,每个key和value都是使用对象表示的。 比如,我们执行以下代码:
redis> SET message "hello redis"
其中的key是message,是一个包含了字符串"message"的对象。而value是一个包含了"hello redis"的对象。 Redis共有五种对象的类型,分别是:
类型常量 | 对象的名称 |
---|---|
REDIS_STRING | 字符串对象 |
REDIS_LIST | 列表对象 |
REDIS_HASH | 哈希对象 |
REDIS_SET | 集合对象 |
REDIS_ZSET | 有序集合对象 |
Redis中的一个对象的结构体表示如下: |
typedef struct redisObject { // 类型 unsigned type:4; // 编码方式 unsigned encoding: 4; // 引用计数 int refcount; // 指向对象的值 void *ptr; } robj;
type表示了该对象的对象类型,即上面五个中的一个。但为了提高存储效率与程序执行效率,每种对象的底层数据结构实现都可能不止一种。encoding就表示了对象底层所使用的编码。
- Redis对象底层数据结构
编码常量 | 编码所对应的底层数据结构 |
---|---|
REDIS_ENCODING_INT | long 类型的整数 |
REDIS_ENCODING_EMBSTR | embstr 编码的简单动态字符串 |
REDIS_ENCODING_RAW | 简单动态字符串 |
REDIS_ENCODING_HT | 字典 |
REDIS_ENCODING_LINKEDLIST | 双端链表 |
REDIS_ENCODING_ZIPLIST | 压缩列表 |
REDIS_ENCODING_INTSET | 整数集合 |
REDIS_ENCODING_SKIPLIST | 跳跃表和字典 |
- 字符串对象
字符串对象的编码可以是int、raw或者embstr 如果一个字符串的内容可以转换为long,那么该字符串就会被转换成为long类型,对象的ptr就会指向该long,并且对象类型也用int类型表示。 普通的字符串有两种,embstr和raw。embstr应该是Redis 3.0新增的数据结构,在2.8中是没有的。如果字符串对象的长度小于39字节,就用embstr对象。否则用传统的raw对象。
#define REDIS_ENCODING_EMBSTR_SIZE_LIMIT 44 robj *createStringObject(char *ptr, size_t len) { if (len <= REDIS_ENCODING_EMBSTR_SIZE_LIMIT) return createEmbeddedStringObject(ptr,len); else return createRawStringObject(ptr,len); }
embstr的好处有如下几点:
- embstr的创建只需分配一次内存,而raw为两次(一次为
sds
分配对象,另一次为objet分配对象,embstr省去了第一次)。 - 相对地,释放内存的次数也由两次变为一次。
- embstr的objet和sds放在一起,更好地利用缓存带来的优势。
raw和embstr的区别可以用下面两幅图所示:
- 列表对象 列表对象的编码可以是ziplist或者linkedlist
- ziplist是一种压缩链表,它的好处是更能节省内存空间,因为它所存储的内容都是在连续的内存区域当中的。当列表对象元素不大,每个元素也不大的时候,就采用ziplist存储但当数据量过大时就ziplist就不是那么好用了。因为为了保证他存储内容在内存中的连续性,插入的复杂度是O(N),即每次插入都会重新进行realloc。如下图所示,对象结构中ptr所指向的就是一个ziplist整个ziplist只需要malloc一次,它们在内存中是一块连续的区域。
- linkedlist是一种双向链表。它的结构比较简单,节点中存放pre和next两个指针,还有节点相关的信息。当每增加一个node的时候,就需要重新malloc一块内存。
- 哈希对象 哈希对象的底层实现可以是ziplist或者hashtable。 ziplist中的哈希对象是按照key1,value1,key2,value2这样的顺序存放来存储的。当对象数目不多且内容不大时,这种方式效率是很高的。
hashtable的是由dict这个结构来实现的, dict是一个字典,其中的指针dicht ht[2] 指向了两个哈希表
typedef struct dict { dictType *type; void *privdata; dictht ht[2]; long rehashidx; /* rehashing not in progress if rehashidx == -1 */ int iterators; /* number of iterators currently running */ } dict; typedef struct dictht { dictEntry **table; unsigned long size; unsigned long sizemask; unsigned long used; } dictht;
dicht[0] 是用于真正存放数据,dicht[1]一般在哈希表元素过多进行rehash的时候用于中转数据。 dictht中的table用语真正存放元素了,每个key/value对用一个dictEntry表示,放在dictEntry数组中。
- 集合对象 集合对象的编码可以是intset或者hashtable intset是一个整数集合,里面存的为某种同一类型的整数,支持如下三种长度的整数:
#define INTSET_ENC_INT16 (sizeof(int16_t)) #define INTSET_ENC_INT32 (sizeof(int32_t)) #define INTSET_ENC_INT64 (sizeof(int64_t))
intset是一个有序集合,查找元素的复杂度为O(logN),但插入时不一定为O(logN),因为有可能涉及到升级操作。比如当集合里全是int16_t型的整数,这时要插入一个int32_t,那么为了维持集合中数据类型的一致,那么所有的数据都会被转换成int32_t类型,涉及到内存的重新分配,这时插入的复杂度就为O(N)了。 intset不支持降级操作。
- 有序集合对象 有序集合的编码可能两种,一种是ziplist,另一种是skiplist与dict的结合。 ziplist作为集合和作为哈希对象是一样的,member和score顺序存放。按照score从小到大顺序排列 skiplist是一种跳跃表,它实现了有序集合中的快速查找,在大多数情况下它的速度都可以和平衡树差不多。但它的实现比较简单,可以作为平衡树的替代品。它的结构比较特殊。下面分别是跳跃表skiplist和它内部的节点skiplistNode的结构体:
/* * 跳跃表 */ typedef struct zskiplist { // 头节点,尾节点 struct zskiplistNode *header, *tail; // 节点数量 unsigned long length; // 目前表内节点的最大层数 int level; } zskiplist; /* ZSETs use a specialized version of Skiplists */ /* * 跳跃表节点 */ typedef struct zskiplistNode { // member 对象 robj *obj; // 分值 double score; // 后退指针 struct zskiplistNode *backward; // 层 struct zskiplistLevel { // 前进指针 struct zskiplistNode *forward; // 这个层跨越的节点数量 unsigned int span; } level[]; } zskiplistNode;
head和tail分别指向头节点和尾节点,然后每个skiplistNode里面的结构又是分层的(即level数组) 用图表示,大概是下面这个样子:
总结
以上简单介绍了Redis的简介,特性以及五种对象类型和五种对象类型的底层实现。事实上,Redis的高效性和灵活性正是得益于同一个对象类型采用不同的底层结构,并且在必要的时候对二者进行转换,还有就是各种底层结构对内存的合理利用。
本文作者:Worktile高级工程师 龚林杰
文章来源:Worktile技术博客
欢迎访问交流更多关于技术及协作的问题。
文章转载请注明出处。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
从边车模式到 Service Mesh
从边车模式到 Service Mesh 所谓边车模式( Sidecar pattern ),也译作挎斗模式,是分布式架构中云设计模式的一种。因为其非常类似于生活中的边三轮摩托车而得名。该设计模式通过给应用程序加上一个“边车”的方式来拓展应用程序现有的功能。该设计模式出现的很早,实现的方式也多种多样。现在这个模式更是随着微服务的火热与 Service Mesh 的逐渐成熟而进入人们的视野。 什么是边车模式 在 Azure Architecture Center 的云设计模式中是这么介绍边车模式的: Deploy components of an application into a separate process or container to provide isolation and encapsulation. --- Sidecar pattern 这里要注意的是: 这里的 Sidecar 是分布式架构中云设计模式的一种,与我们目前在使用的 Istio 或 Linkerd 中的 Sidecar 是设计与实现的区别,后文中提到的边车模式均是指这种设计模式,请勿与 Istio 或 ...
- 下一篇
nginx-rtmp-module的缺陷分析
Arut最初在开发nginx-rtmp-module的时候只实现了单进程模式,好处是架构简单,推送和播放,数据统计,流媒体控制等都在一个进程上完成。但是这显然浪费了Nginx多进程(在Linux和FreeBSD平台上每个进程都可以绑定一个CPU核心,以减少进程切换带来的开销)的处理能力。但是,如果开启多进程模式,推送和播放如果不在同一个进程上,会造成播放失败的问题: 另外,请求数据统计信息也是个问题,因为采取HTTP方式请求数据统计信息时,在多进程模式下,请求被Nginx随机分配给了worker进程,可能造成我想看worker 1上的数据统计信息,但是Nginx返回的是worker 3上的数据统计信息。流媒体控制也采取了HTTP请求的方式,所以也存在着同样的问题: 针对推送和播放不在同一个进程上的问题,Arut后来加入了auto push的功能,即把原始的推流数据再relay到其他进程上去。这个功能需要Unix domain socket的支持(所以类Unix系统都支持,Windows在Windows 10的某个版本后才开始支持): 这样处理后,不管播放请求落在哪个进程上,都能获得推送...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2全家桶,快速入门学习开发网站教程
- MySQL8.0.19开启GTID主从同步CentOS8
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- CentOS8安装Docker,最新的服务器搭配容器使用
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题