Redis 入门与数据结构

1、redis 诞生历程

08 年的时候有一个意大利西西里岛的小伙子,笔名 antirez(http://invece.org/),创建了一个访客信息网站 LLOOGG.COM。有的时候我们需要知道网站的访问情况,比如访客的 IP、操作系统、浏览器、使用的搜索关键词、所在地区、访问的网页地址等等。在国内,有很多网站提供了这个功能,比如 CNZZ,百度统计,国外也有谷歌的 Google Analytics。我们不用自己写代码去实现这个功能,只需要在全局的 footer 里面嵌入一段 JS 代码就行了,当页面被访问的时候,就会自动把访客的信息发送到这些网站统计的服务器,然后我们登录后台就可以查看数据了。

LLOOGG.COM 提供的就是这种功能,它可以查看最多 10000 条的最新浏览记录。 这样的话,它需要为每一个网站创建一个列表(List),不同网站的访问记录进入到不同的列表。如果列表的长度超过了用户指定的长度,它需要把最早的记录删除(先进先出)。

在这里插入图片描述

当 LLOOGG.COM 的用户越来越多的时候,它需要维护的列表数量也越来越多,这 种记录最新的请求和删除最早的请求的操作也越来越多。LLOOGG.COM 最初使用的数据库是 MySQL,可想而知,因为每一次记录和删除都要读写磁盘,因为数据量和并发量太大,在这种情况下无论怎么去优化数据库都不管用了。

考虑到最终限制数据库性能的瓶颈在于磁盘,所以 antirez 打算放弃磁盘,自己去实现一个具有列表结构的数据库的原型,把数据放在内存而不是磁盘,这样可以大大地提升列表的 push 和 pop 的效率。antirez 发现这种思路确实能解决这个问题,所以用 C 语言重写了这个内存数据库,并且加上了持久化的功能,09 年,Redis 横空出世了。从最开始只支持列表的数据库,到现在支持多种数据类型,并且提供了一系列的高级特性, Redis 已经成为一个在全世界被广泛使用的开源项目。

为什么叫 REDIS 呢?它的全称是 REmote DIctionary Service,直接翻译过来是远程字典服务。

从 Redis 的诞生历史我们看到了,在某些场景中,关系型数据库并不适合用来存储我们的 Web 应用的数据。那么,关系型数据库和非关系型数据库,或者说 SQL 和 NoSQL,到底有什么不一样呢?

2、Redis 定位与特性

2.1 SQL 与 NoSQL

在绝大部分时候,我们都会首先考虑用关系型数据库来存储我们的数据,比如 SQLServer,Oracle,MySQL 等等。

关系型数据库的特点:

1、它以表格的形式,基于行存储数据,是一个二维的模式。
2、它存储的是结构化的数据,数据存储有固定的模式(schema),数据需要适应表结构。
3、表与表之间存在关联(Relationship)。
4、大部分关系型数据库都支持 SQL(结构化查询语言)的操作,支持复杂的关联查询。
5、通过支持事务(ACID 酸)来提供严格或者实时的数据一致性。

但是使用关系型数据库也存在一些限制,比如:

1、要实现扩容的话,只能向上(垂直)扩展,比如磁盘限制了数据的存储,就要扩大磁盘容量,通过堆硬件的方式,不支持动态的扩缩容。水平扩容需要复杂的技术来实现,比如分库分表。
2、表结构修改困难,因此存储的数据格式也受到限制。
3、在高并发和高数据量的情况下,我们的关系型数据库通常会把数据持久化到磁盘,基于磁盘的读写压力比较大。

为了规避关系型数据库的一系列问题,我们就有了非关系型的数据库,我们一般把它叫做“non-relational”或者“Not Only SQL”。NoSQL 最开始是不提供 SQL 的数据库的意思,但是后来意思慢慢地发生了变化。

非关系型数据库的特点:
1、存储非结构化的数据,比如文本、图片、音频、视频。
2、表与表之间没有关联,可扩展性强。
3、保证数据的最终一致性。遵循 BASE(碱)理论。 Basically Available(基本可用); Soft-state(软状态); Eventually Consistent(最终一致性)。
4、支持海量数据的存储和高并发的高效读写。
5、支持分布式,能够对数据进行分片存储,扩缩容简单。

对于不同的存储类型,我们又有各种各样的非关系型数据库,比如有几种常见的类型:
1、KV 存储,用 Key Value 的形式来存储数据。比较常见的有 Redis 和 MemcacheDB。
2、文档存储,MongoDB。
3、列存储,HBase。
4、图存储,这个图(Graph)是数据结构,不是文件格式。Neo4j。
5、对象存储。
6、XML 存储等等等等。

这个网页列举了各种各样的 NoSQL 数据库 http://nosql-database.org/。

NewSQL 结合了 SQL 和 NoSQL 的特性(例如 PingCAP 的 TiDB)。

2.2 redis 特性

官网介绍:https://redis.io/topics/introduction
中文网站:http://www.redis.cn

硬件层面有 CPU 的缓存;浏览器也有缓存;手机的应用也有缓存。我们把数据缓存起来的原因就是从原始位置取数据的代价太大了,放在一个临时位置存储起来,取回就可以快一些。

Redis 的特性:
1)更丰富的数据类型
2)进程内与跨进程;单机与分布式
3)功能丰富:持久化机制、过期策略
4)支持多种编程语言
5)高可用,集群

3、Redis 安装与启动

3.1 安装

参考:
CentOS7 安装 Redis 单实例 https://gper.club/articles/7e7e7f7ff7g5egc4g6b

3.2 服务启动

  • src 目录下,直接启动
./redis-server
  • 启动 Redis
redis-server redis.conf

总结:redis 的参数可以通过三种方式配置,一种是 redis.conf,一种是启动时–携带的参数,一种是 config set。

3.3 基本操作

默认有 16 个库(0-15),可以在配置文件中修改,默认使用第一个 db0。

databases 16

因为没有完全隔离,不像数据库的 database,不适合把不同的库分配给不同的业务使用。

切换数据库

select 0

清空当前数据库

flushdb

清空所有数据库

flushall

Redis 是字典结构的存储方式,采用 key-value 存储。key 和 value 的最大长度限制是 512M。

Redis 一共有几种数据类型?(注意是数据类型不是数据结构)

String、Hash、Set、List、Zset、Hyperloglog、Geo、Streams

4、Redis 基础数据类型

4.1 String 字符串

4.1.1 存储类型

可以用来存储字符串、整数、浮点数。

4.1.2 操作命令

设置多个值(批量操作,原子性)

mset qingshan 2673 jack 666 

设置值,如果 key 存在,则不成功

setnx qingshan

4.1.3 存储(实现)原理

  • 数据模型

set hello word 为例,因为 Redis 是 KV 的数据库,它是通过 hashtable 实现的(我们把这个叫做外层的哈希)。所以每个键值对都会有一个 dictEntry(源码位置:dict.h), 里面指向了 key 和 value 的指针。next 指向下一个 dictEntry。

typedef struct dictEntry {
void *key; /* key 关键字定义 */
union {
void *val; uint64_t u64; /* value 定义 */ 
int64_t s64; 
double d;
} v;
struct dictEntry *next; /* 指向下一个键值对节点 */
} dictEntry;

在这里插入图片描述

key 是字符串,但是 Redis 没有直接使用 C 的字符数组,而是存储在自定义的 SDS (简单动态字符串sds(simple dynamic string),是可以修改的字符串。它类似于Java中的ArrayList,它采用预分配冗余空间的方式来减少内存的频繁分配。)中。

value 既不是直接作为字符串存储,也不是直接存储在 SDS 中,而是存储在 redisObject 中。实际上五种常用的数据类型的任何一种,都是通过 redisObject 来存储的。

  • redisObject

redisObject 定义在 src/server.h 文件中。

typedef struct redisObject {
unsigned type:4; /* 对象的类型,包括:OBJ_STRING、OBJ_LIST、OBJ_HASH、OBJ_SET、OBJ_ZSET */ 
unsigned encoding:4; /* 具体的数据结构 */
unsigned lru:LRU_BITS; /* 24 位,对象最后一次被命令程序访问的时间,与内存回收有关 */
int refcount; /* 引用计数。当 refcount 为 0 的时候,表示该对象已经不被任何对象引用,则可以进行垃圾回收了
*/
void *ptr; /* 指向对象实际的数据结构 */
} robj;
  • 内部编码

在这里插入图片描述

字符串类型的内部编码有三种:
1、int,存储 8 个字节的长整型(long,2^63-1)。
2、embstr, 代表 embstr 格式的 SDS(Simple Dynamic String 简单动态字符串),存储小于 44 个字节的字符串。
3、raw,存储大于 44 个字节的字符串(3.2 版本之前是 39 字节)。

4.1.4 常见问题

  • 问题 1、什么是 SDS?

Redis 中字符串的实现。
在 3.2 以后的版本中,SDS 又有多种结构(sds.h):sdshdr5、sdshdr8、sdshdr16、sdshdr32、sdshdr64,用于存储不同的长度的字符串,分别代表 2^5=32byte, 28=256byte,216=65536byte=64KB,2^32byte=4GB。

/* sds.h */
struct __attribute__ ((__packed__)) sdshdr8 {
uint8_t len; /* 当前字符数组的长度 */
uint8_t alloc; /*当前字符数组总共分配的内存大小 */
unsigned char flags; /* 当前字符数组的属性、用来标识到底是 sdshdr8 还是 sdshdr16 等 */ char buf[]; /* 字符串真正的值 */
};
  • 问题 2、为什么 Redis 要用 SDS 实现字符串?

我们知道,C 语言本身没有字符串类型(只能用字符数组 char[]实现)。

1、使用字符数组必须先给目标变量分配足够的空间,否则可能会溢出。
2、如果要获取字符长度,必须遍历字符数组,时间复杂度是 O(n)。
3、C 字符串长度的变更会对字符数组做内存重分配。
4、通过从字符串开始到结尾碰到的第一个’\0’来标记字符串的结束,因此不能保存图片、音频、视频、压缩文件等二进制(bytes)保存的内容,二进制不安全。

SDS 的特点:
1、不用担心内存溢出问题,如果需要会对 SDS 进行扩容。
2、获取字符串长度时间复杂度为 O(1),因为定义了 len 属性。
3、通过“空间预分配”(sdsMakeRoomFor)和“惰性空间释放”,防止多次重分配内存。
4、判断是否结束的标志是 len 属性(它同样以’\0’结尾是因为这样就可以使用 C 语言中函数库操作字符串的函数了),可以包含’\0’。

在这里插入图片描述

  • 问题 3、embstr 和 raw 的区别?

embstr 的使用只分配一次内存空间(因为 RedisObject 和 SDS 是连续的),而 raw 需要分配两次内存空间(分别为 RedisObject 和 SDS 分配空间)。

因此与 raw 相比,embstr 的好处在于创建时少分配一次空间,删除时少释放一次空间,以及对象的所有数据连在一起,寻找方便。

而 embstr 的坏处也很明显,如果字符串的长度增加需要重新分配内存时,整个 RedisObject 和 SDS 都需要重新分配空间,因此 Redis 中的 embstr 实现为只读。

  • 问题 4:int 和 embstr 什么时候转化为 raw?

当 int 数据不再是整数,或大小超过了 long 的范围 (2^63-1=9223372036854775807)时,自动转化为 embstr。

  • 问题 5:明明没有超过阈值,为什么变成 raw 了?

对于 embstr,由于其实现是只读的,因此在对 embstr 对象进行修改时,都会先转化为 raw 再进行修改。

因此,只要是修改 embstr 对象,修改后的对象一定是 raw 的,无论是否达到了 44 个字节。

  • 问题 6:当长度小于阈值时,会还原吗?

关于 Redis 内部编码的转换,都符合以下规律:编码转换在 Redis 写入数据时完成,且转换过程不可逆,只能从小内存编码向大内存编码转换(但是不包括重新 set)。

  • 问题 7:为什么要对底层的数据结构进行一层包装呢?
    通过封装,可以根据对象的类型动态地选择存储结构和可以使用的命令,实现节省空间和优化查询速度。

4.1.5 应用场景

  • 缓存
    String 类型
    例如:热点数据缓存(例如报表,明星出轨),对象缓存,全页缓存。
    可以提升热点数据的访问速度。

  • 数据共享分布式
    String 类型
    因为 Redis 是分布式的独立服务,可以在多个应用之间共享
    例如:分布式 Session

  • 分布式锁
    STRING 类型
    setnx 方法,只有不存在时才能添加成功,返回 true。

  • 全局 ID
    INT 类型
    INCRBY,利用原子性
    (分库分表的场景,一次性拿一段)

  • 计数器
    INT 类型,INCR 方法
    例如:文章的阅读量,微博点赞数,允许一定的延迟,先写入 Redis 再定时同步到 数据库。

  • 限流
    INT 类型,INCR 方法
    以访问者的 IP 和其他信息作为 key,访问一次增加一次计数,超过次数则返回 false。

  • 位统计
    String 类型的 BITCOUNT(1.6.6 的 bitmap 数据结构介绍)。 字符是以 8 位二进制存储的。
    a 对应的 ASCII 码是 97,转换为二进制数据是 01100001
    b 对应的 ASCII 码是 98,转换为二进制数据是 01100010

因为 bit 非常节省空间(1 MB=8388608 bit),可以用来做大数据量的统计。

例如:在线用户统计,留存用户统计。

如果一个对象的 value 有多个值的时候,怎么存储? 例如用一个 key 存储一张表的数据。

在这里插入图片描述

序列化?

例如 JSON/Protobuf/XML,会增加序列化和反序列化的开销,并且不能单独获取、修改一个值。

可以通过 key 分层的方式来实现,例如:

mset student:1:sno GP16666 student:1:sname 沐风 student:1:company 腾讯

获取值的时候一次获取多个值:

mget student:1:sno student:1:sname student:1:company

缺点:key 太长,占用的空间太多。有没有更好的方式?

4.2 Hash哈希

在这里插入图片描述

4.2.1 存储类型

包含键值对的无序散列表。value 只能是字符串,不能嵌套其他类型。
同样是存储字符串,Hash 与 String 的主要区别?
1、把所有相关的值聚集到一个 key 中,节省内存空间
2、只使用一个 key,减少 key 冲突
3、当需要批量获取值的时候,只需要使用一个命令,减少内存/IO/CPU 的消耗

Hash 不适合的场景:
1、Field 不能单独设置过期时间
2、没有 bit 操作
3、需要考虑数据量分布的问题(value 值非常大的时候,无法分布到多个节点)

4.2.2 操作命令

hget
hmget
hekeys
hset
hmset

4.2.3 存储(实现)原理

Redis 的 Hash 本身也是一个 KV 的结构,类似于 Java 中的 HashMap。

外层的哈希(Redis KV 的实现)只用到了 hashtable。当存储 hash 数据类型时,我们把它叫做内层的哈希。内层的哈希底层可以使用两种数据结构实现:

ziplist:OBJ_ENCODING_ZIPLIST(压缩列表)
hashtable:OBJ_ENCODING_HT(哈希表)

4.2.4 常见问题

  • ziplist

(1)ziplist 压缩列表是什么?

ziplist 是一个经过特殊编码的双向链表,它不存储指向上一个链表节点和指向下一个链表节点的指针,而是存储上一个节点长度和当前节点长度,通过牺牲部分读写性能,来换取高效的内存空间利用率,是一种时间换空间的思想。只用在字段个数少,字段值小的场景里面。

(2)ziplist 的内部结构?

在这里插入图片描述
在这里插入图片描述

编码 encoding(ziplist.c 源码第 204 行)

#define ZIP_STR_06B (0 << 6) //长度小于等于 63 字节
#define ZIP_STR_14B (1 << 6) //长度小于等于 16383 字节 
#define ZIP_STR_32B (2 << 6) //长度小于等于 4294967295 字节

在这里插入图片描述

(3)问题:什么时候使用 ziplist 存储?

当 hash 对象同时满足以下两个条件的时候,使用 ziplist 编码:

1)所有的键值对的健和值的字符串长度都小于等于 64byte(一个英文字母一个字节);
2)哈希对象保存的键值对数量小于 512 个。

/* src/redis.conf 配置 */
hash-max-ziplist-value 64 // ziplist 中最大能存放的值长度 
hash-max-ziplist-entries 512 // ziplist 中最多能存放的 entry 节点数量

一个哈希对象超过配置的阈值(键和值的长度有>64byte,键值对个数>512 个)时, 会转换成哈希表(hashtable)。

  • hashtable(dict)

在 Redis 中,hashtable 被称为字典(dictionary),它是一个数组+链表的结构。
源码位置:dict.h

前面我们知道了,Redis 的 KV 结构是通过一个 dictEntry 来实现的。
Redis 又对 dictEntry 进行了多层的封装。

typedef struct dictEntry {
void *key; /* key 关键字定义 */
union {
void *val; uint64_t u64; /* value 定义 */ 
int64_t s64; double d;
} v;
struct dictEntry *next; /* 指向下一个键值对节点 */
} dictEntry;

dictEntry 放到了 dictht(hashtable 里面):

typedef struct dictht {
dictEntry **table; /* 哈希表数组 */
unsigned long size; /* 哈希表大小 */
unsigned long sizemask; /* 掩码大小,用于计算索引值。总是等于 size-1 */ unsigned long used; /* 已有节点数 */
} dictht;

ht 放到了 dict 里面:

typedef struct dict {
dictType *type; /* 字典类型 */
void *privdata; /* 私有数据 */
dictht ht[2]; /* 一个字典有两个哈希表 */
long rehashidx; /* rehash 索引 */
unsigned long iterators; /* 当前正在使用的迭代器数量 */
} dict;

从最底层到最高层 dictEntry——dictht——dict——OBJ_ENCODING_HT

总结:哈希的存储结构

在这里插入图片描述

注意:dictht 后面是 NULL 说明第二个 ht 还没用到。dictEntry*后面是 NULL 说明没有 hash 到这个地址。dictEntry 后面是 NULL 说明没有发生哈希冲突。

(4)问题:为什么要定义两个哈希表呢?ht[2]

redis 的 hash 默认使用的是 ht[0],ht[1]不会初始化和分配空间。
哈希表 dictht 是用链地址法来解决碰撞问题的。在这种情况下,哈希表的性能取决于它的大小(size 属性)和它所保存的节点的数量(used 属性)之间的比率:
1)比率在 1:1 时(一个哈希表 ht 只存储一个节点 entry),哈希表的性能最好;
2)如果节点数量比哈希表的大小要大很多的话(这个比例用 ratio 表示,5 表示平均一个 ht 存储 5 个 entry),那么哈希表就会退化成多个链表,哈希表本身的性能优势就不再存在。
在这种情况下需要扩容。Redis 里面的这种操作叫做 rehash。

rehash 的步骤:
1、为字符 ht[1]哈希表分配空间,这个哈希表的空间大小取决于要执行的操作,以及 ht[0]当前包含的键值对的数量。
扩展:ht[1]的大小为第一个大于等于 ht[0].used*2。
2、将所有的 ht[0]上的节点 rehash 到 ht[1]上,重新计算 hash 值和索引,然后放入指定的位置。
3、当 ht[0]全部迁移到了 ht[1]之后,释放 ht[0]的空间,将 ht[1]设置为 ht[0]表,并创建新的 ht[1],为下次 rehash 做准备。

(5)问题:什么时候触发扩容?

负载因子(源码位置:dict.c):

static int dict_can_resize = 1;
static unsigned int dict_force_resize_ratio = 5;

ratio = used / size,已使用节点与字典大小的比例
dict_can_resize 为 1 并且 dict_force_resize_ratio 已使用节点数和字典大小之间的比率超过 1:5,触发扩容。

4.2.5 应用场景

String 可以做的事情,Hash 都可以做。

存储对象类型的数据
比如对象或者一张表的数据,比 String 节省了更多 key 的空间,也更加便于集中管理。

4.3 List 列表

4.3.1 存储类型

存储有序的字符串(从左到右),元素可以重复。可以充当队列和栈的角色。

在这里插入图片描述

4.3.2 操作命令

在这里插入图片描述

4.3.3 存储(实现)原理

在早期的版本中,数据量较小时用 ziplist 存储,达到临界值时转换为 linkedlist 进行存储,分别对应 OBJ_ENCODING_ZIPLIST 和 OBJ_ENCODING_LINKEDLIST。

3.2 版本之后,统一用 quicklist 来存储。quicklist 存储了一个双向链表,每个节点都是一个 ziplist。

  • quicklist

quicklist(快速列表)是 ziplist 和 linkedlist 的结合体。 quicklist.h,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 占用多少字节 */
unsignedintcount: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;

在这里插入图片描述

ziplist 的结构前面已经说过了,不再重复。

4.3.4 常见问题

4.3.5 应用场景

  • 用户消息时间线 timeline
    因为 List 是有序的,可以用来做用户时间线

  • 消息队列
    List 提供了两个阻塞的弹出操作:BLPOP/BRPOP,可以设置超时时间。
    BLPOP:BLPOP key1 timeout 移出并获取列表的第一个元素,如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
    BRPOP:BRPOP key1 timeout 移出并获取列表的最后一个元素,如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。
    队列:先进先出:rpush blpop,左头右尾,右边进入队列,左边出队列。
    栈:先进后出:rpush brpop

4.4 Set 集合

4.4.1 存储类型

String 类型的无序集合,最大存储数量 2^32-1(40 亿左右)。

4.4.2 操作命令

sadd myset a b c d e f g
smembers myset

4.4.3 存储(实现)原理

Redis 用 intset 或 hashtable 存储 set。如果元素都是整数类型,就用 inset 存储。 如果不是整数类型,就用 hashtable(数组+链表的存来储结构)。

4.4.4 常见问题

  • 问题:KV 怎么存储 set 的元素?
    key 就是元素的值,value 为 null。 如果元素个数超过 512 个,也会用 hashtable 存储。

4.4.5 应用场景

  • 抽奖
    随机获取元素 spop myset

  • 点赞、签到、打卡

  • 商品标签

  • 商品筛选

  • 用户关注、推荐模型

4.5 ZSet 有序集合

4.5.1 存储类型

在这里插入图片描述
sorted set,有序的 set,每个元素有个 score。 score 相同时,按照 key 的 ASCII 码排序。

数据结构对比:

在这里插入图片描述

4.5.2 操作命令

zadd
zrange
zrangebyscore
zrem
...

4.5.3 存储(实现)原理

同时满足以下条件时使用 ziplist 编码:
(1)元素数量小于 128 个
(2)所有 member 的长度都小于 64 字节
在 ziplist 的内部,按照 score 排序递增来存储。插入的时候要移动之后的数据。

4.5.4 常见问题

  • 问题:什么是 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.5.5 应用场景

排行榜

4.6 其他数据结构简介

  • BitMaps
    Bitmaps 是在字符串类型上面定义的位操作。一个字节由 8 个二进制位组成。

BITOP 命令支持 AND 、 OR 、 NOT 、 XOR 这四种操作中的任意一种参数:
BITOP AND destkey srckey1 … srckeyN ,对一个或多个 key 求逻辑与,并将结果保存到 destkey BITOP OR destkey srckey1 … srckeyN,对一个或多个 key 求逻辑或,并将结果保存到 destkey BITOP XOR destkey srckey1 … srckeyN,对一个或多个 key 求逻辑异或,并将结果保存到 destkey BITOP NOT destkey srckey,对给定 key 求逻辑非,并将结果保存到 destkey

应用场景:
用户访问统计
在线用户统计

  • Hyperloglogs
    Hyperloglogs:提供了一种不太准确的基数统计方法,比如统计网站的 UV,存在 一定的误差。HyperLogLogTest.java

  • Streams
    5.0 推出的数据类型。支持多播的可持久化的消息队列,用于实现发布订阅功能,借鉴了 kafka 的设计。

5、总结

5.1 数据结构总结

在这里插入图片描述

5.2 编码转换总结

在这里插入图片描述

5.3 应用场景总结

缓存——提升热点数据的访问速度
共享数据——数据的存储和共享的问题
全局 ID——分布式全局 ID 的生成方案(分库分表) 分布式锁——进程间共享数据的原子操作保证
在线用户统计和计数
队列、栈——跨进程的队列/栈
消息队列——异步解耦的消息机制
服务注册与发现 —— RPC 通信机制的服务协调中心(Dubbo 支持 Redis) 购物车
新浪/Twitter 用户消息时间线
抽奖逻辑(礼物、转发)
点赞、签到、打卡
商品标签
用户(商品)关注(推荐)模型
电商产品筛选
排行榜

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:深蓝海洋 设计师:CSDN官方博客 返回首页
评论

打赏作者

chun_soft

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值