redis队列什么意思

Redis队列功能介绍

List

常用命令：

Blpop删除，并获得该列表中的第一元素，或阻塞，直到有一个可用

Brpop删除，并获得该列表中的最后一个元素，或阻塞，直到有一个可用

Brpoplpush

Lindex获取一个元素，通过其索引列表

Linsert在列表中的另一个元素之前或之后插入一个元素

Llen获得队列(List)的长度

Lpop从队列的左边出队一个元素

Lpush从队列的左边入队一个或多个元素

Lpushx当队列存在时，从队到左边入队一个元素

Lrange从列表中获取指定返回的元素

Lrem从列表中删除元素

Lset设置队列里面一个元素的值

Ltrim修剪到指定范围内的清单

Rpop从队列的右边出队一个元素

Rpoplpush删除列表中的最后一个元素，将其追加到另一个列表

Rpush从队列的右边入队一个元素

Rpushx从队列的右边入队一个元素，仅队列存在时有效

Redis支持php、python、c等接口

应用场景：

Redis list的应用场景非常多，也是Redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用Redis的list结构来实现。

Lists 就是链表，相信略有数据结构知识的人都应该能理解其结构。使用Lists结构，我们可以轻松地实现最新消息排行等功能。

Lists的另一个应用就是消息队列，

可以利用Lists的PUSH *** 作，将任务存在Lists中，然后工作线程再用POP *** 作将任务取出进行执行。Redis还提供了 *** 作Lists中某一段的api，你可以直接查询，删除Lists中某一段的元素。

如果需要还可以用redis的Sorted-Sets数据结构来做优先队列可以给每条消息加上一个唯一的序号。这里就不详细介绍了。

实现方式：

Redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便 *** 作，不过带来了部分额外的内存开销，Redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。

示意图:

1)入队

2)出队(非阻塞模式)

lpopd出列表首元素（即最后入队的元素）

Rpopd出列表尾元素 （即入队的最开始的一个元素）

注意：如果要当作队列功能，应该是用这个出队

这里的出队都是非阻塞模式，就是你用pop出队的时候，如果队列是空的话，你得到的是一个NULL的值

3)出队(阻塞模式)

假如现在queue队列为空  我们用brpop命令

BRPOP 是一个阻塞的列表d出原语。 它是 RPOP 的阻塞版本，因为这个命令会在给定list无法d出任何元素的时候阻塞连接。 该命令会按照给出的 key 顺序查看 list，并在找到的第一个非空 list 的尾部d出一个元素。

A)

我们执行brpop命令

可以看到队列queue没有元素的时候  是阻塞的  即不返回值

其中0是超时时间 为0表示一直等待

B)

这个时候我们用lpush往队列里 入队一个数据“bbb”

C)

阻塞的队列立马会d出出队元素   显示队列名字  和 出队元素  已经等待了多少时间

D)

Brpop还能同时阻塞多个队列比如这样

用redis的list当作队列可能存在的问题

1)redis崩溃的时候队列功能失效

2)如果入队端一直在塞数据，而出队端没有消费数据，或者是入队的频率大而多，出队端的消费频率慢会导致内存暴涨

3)Redis的队列也可以像rabbitmq那样  即可以做消息的持久化，也可以不做消息的持久化。

当做持久话的时候，需要启动redis的dump数据的功能暂时不建议开启持久化。

Redis其实只适合作为缓存，而不是数据库或是存储。它的持久化方式适用于救救急啥的，不太适合当作一个普通功能来用。应为dump时候，会影响性能，数据量小的时候还看不出来，当数据量达到百万级别，内存10g左右的时候，非常影响性能。

4)假如有多个消费者同时监听一个队列，其中一个出队了一个元素，另一个则获取不到该元素

5)Redis的队列应用场景是一对多或者一对一的关系，即有多个入队端，但是只有一个消费端(出队)

PHP的redis 简单 *** 作示例

从业务服务器到Redis服务器这条调用链路中变慢的原因可能有2个

但是大多数情况下都是Redis服务的问题。但是应该如何衡量Redis变慢了呢？命令执行时间大于1s，大于2s？这其实并没有一个固定的标准。

例如在一个配置较高的服务器中，05毫秒就认为Redis变慢了，在一个配置较低的服务器中，3毫秒才认为Redis变慢了。所以我们要针对自己的机器做基准测试，看平常情况下Redis处理命令的时间是多长？

我们可以使用如下命令来监测和统计测试期间的最大延迟（以微秒为单位）

比如执行如下命令

参数中的60是测试执行的秒数，可以看到最大延迟为3725微秒（3毫秒左右），如果命令的执行远超3毫秒，此时Redis就有可能很慢了！

那么Redis有哪些慢 *** 作呢？

Redis的各种命令是在一个线程中依次执行的，如果一个命令在Redis中执行的时间过长，就会影响整体的性能，因为后面的请求要等到前面的请求被处理完才能被处理，这些耗时的 *** 作有如下几个部分

Redis可以通过日志记录那些耗时长的命令，使用如下配置即可

执行如下命令，就可以查询到最近记录的慢日志

之前的文章我们已经介绍了Redis的底层数据结构，它们的时间复杂度如下表所示

名称 时间复杂度 dict（字典） O(1) ziplist （压缩列表） O(n) zskiplist （跳表） O(logN) quicklist（快速列表） O(n) intset（整数集合） O(n)

「单元素 *** 作」 ：对集合中的元素进行增删改查 *** 作和底层数据结构相关，如对字典进行增删改查时间复杂度为O(1)，对跳表进行增删查时间复杂为O(logN)

「范围 *** 作」 ：对集合进行遍历 *** 作，比如Hash类型的HGETALL，Set类型的SMEMBERS，List类型的LRANGE，ZSet类型的ZRANGE，时间复杂度为O(n)，避免使用，用SCAN系列命令代替。（hash用hscan，set用sscan，zset用zscan）

「聚合 *** 作」 ：这类 *** 作的时间复杂度通常大于O(n)，比如SORT、SUNION、ZUNIONSTORE

「统计 *** 作」 ：当想获取集合中的元素个数时，如LLEN或者SCARD，时间复杂度为O(1)，因为它们的底层数据结构如quicklist，dict，intset保存了元素的个数

「边界 *** 作」 ：list底层是用quicklist实现的，quicklist保存了链表的头尾节点，因此对链表的头尾节点进行 *** 作，时间复杂度为O(1)，如LPOP、RPOP、LPUSH、RPUSH

「当想获取Redis中的key时，避免使用keys 」 ，Redis中保存的键值对是保存在一个字典中的（和Java中的HashMap类似，也是通过数组+链表的方式实现的），key的类型都是string，value的类型可以是string，set，list等

例如当我们执行如下命令后，redis的字典结构如下

我们可以用keys命令来查询Redis中特定的key，如下所示

keys命令的复杂度是O(n)，它会遍历这个dict中的所有key，如果Redis中存的key非常多，所有读写Redis的指令都会被延迟等待，所以千万不用在生产环境用这个命令（如果你已经准备离职的话，祝你玩的开心）。

「既然不让你用keys，肯定有替代品，那就是scan」

scan是通过游标逐步遍历的，因此不会长时间阻塞Redis

「用用zscan遍历zset，hscan遍历hash，sscan遍历set的原理和scan命令类似，因为hash，set，zset的底层实现的数据结构中都有dict。」

「如果一个key对应的value非常大，那么这个key就被称为bigkey。写入bigkey在分配内存时需要消耗更长的时间。同样，删除bigkey释放内存也需要消耗更长的时间」

如果在慢日志中发现了SET/DEL这种复杂度不高的命令，此时你就应该排查一下是否是由于写入bigkey导致的。

「如何定位bigkey」

Redis提供了扫描bigkey的命令

可以看到命令的输入有如下3个部分

这个命令的原理就是redis在内部执行了scan命令，遍历实例中所有的key，然后正对key的类型，分别执行strlen，llen，hlen，scard，zcard命令，来获取string类型的长度，容器类型（list，hash，set，zset）的元素个数

使用这个命令需要注意如下两个问题

「如何解决bigkey带来的性能问题？」

我们可以给Redis中的key设置过期时间，那么当key过期了，它在什么时候会被删除呢？

「如果让我们写Redis过期策略，我们会想到如下三种方案」

定时删除策略对CPU不友好，当过期键比较多的时候，Redis线程用来删除过期键，会影响正常请求的响应

惰性删除读CPU是比较有好的，但是会浪费大量的内存。如果一个key设置过期时间放到内存中，但是没有被访问到，那么它会一直存在内存中

定期删除策略则对CPU和内存都比较友好

redis过期key的删除策略选择了如下两种

「惰性删除」 客户端在访问key的时候，对key的过期时间进行校验，如果过期了就立即删除

「定期删除」 Redis会将设置了过期时间的key放在一个独立的字典中，定时遍历这个字典来删除过期的key，遍历策略如下

「因为Redis中过期的key是由主线程删除的，为了不阻塞用户的请求，所以删除过期key的时候是少量多次」 。源码可以参考expirec中的activeExpireCycle方法

为了避免主线程一直在删除key，我们可以采用如下两种方案

Redis是一个内存数据库，当Redis使用的内存超过物理内存的限制后，内存数据会和磁盘产生频繁的交换，交换会导致Redis性能急剧下降。所以在生产环境中我们通过配置参数maxmemoey来限制使用的内存大小。

当实际使用的内存超过maxmemoey后，Redis提供了如下几种可选策略。

「Redis的淘汰策略也是在主线程中执行的。但内存超过Redis上限后，每次写入都需要淘汰一些key，导致请求时间变长」

可以通过如下几个方式进行改善

Redis的持久化机制有RDB快照和AOF日志，每次写命令之后后，Redis提供了如下三种刷盘机制

「当aof的刷盘机制为always，redis每处理一次写命令，都会把写命令刷到磁盘中才返回，整个过程是在Redis主线程中进行的，势必会拖慢redis的性能」

当aof的刷盘机制为everysec，redis写完内存后就返回，刷盘 *** 作是放到后台线程中去执行的，后台线程每隔1秒把内存中的数据刷到磁盘中

当aof的刷盘机制为no，宕机后可能会造成部分数据丢失，一般不采用。

「一般情况下，aof刷盘机制配置为everysec即可」

在持久化一节中，我们已经提到 「Redis生成rdb文件和aof日志重写，都是通过主线程fork子进程的方式，让子进程来执行的，主线程的内存越大，阻塞时间越长。」

可以通过如下方式优化

当机器的内存不够时， *** 作系统会将部分内存的数据置换到磁盘上，这块磁盘区域就是Swap分区，当应用程序再次访问这些数据的时候，就需要从磁盘上读取，导致性能严重下降

「当Redis性能急剧下降时就有可能是数据被换到Swap分区，我们该如何排查Redis数据是否被换到Swap分区呢？」

每一行Size表示Redis所用的一块内存大小，Size下面的Swap表示这块大小的内存，有多少已经被换到磁盘上了，如果这2个值相等，说明这块内存的数据都已经被换到磁盘上了

我们可以通过如下方式来解决

最后我们总结一下Redis的慢 *** 作

redis的字符串类型是由一种叫做简单动态字符串(SDS)的数据类型来实现

SDC和C语言字符串的区别：

1：SDS保存了字符串的长度，而C语言不保存，只能遍历找到第一个\0的结束符才能确定字符串的长度

2：修改SDS，会检查空间是否足够，不足会先扩展空间，防止缓冲区溢出，C字符串不会检查

3：SDS的预分配空间机制，可以减少为字符串重新分配空间的次数

备注：重新分配空间方式，小于1M的数据 翻倍+1，例如：13K+13K+1，如果大于1M，每次多分配1M，例如：10M+1M+1,如果字符串变短，并不会立即缩短，而是采用惰性空间释放，有专门的API可以释放多余空间

hash结构里其实是一个字典，有许多的键值对

redis的哈希表是一个dictht结构体：

哈希表节点的结构体如下：

hash算法：

当要将一个新的键值对添加到字典里面时， 程序需要先根据键值对的键计算出哈希值和索引值， 然后再根据索引值， 将包含新键值对的哈希表节点放到哈希表数组的指定索引上面。

hash冲突解决方式：链表法，后入的放到最前面

rehash：

键值数据量变动时，时为了让哈希表的负载因子（load factor）维持在一个合理的范围之内， 当哈希表保存的键值对数量太多或者太少时， 程序需要对哈希表的大小进行相应的扩展或者收缩。

如果是扩充，新数组的空间大小为 大于2used的2的n次方，比如：used=5,则去大于10的第一个2的n次方，为16

如果是缩小，新数组的空间大小为第一个不大于used的2的n次方，比如：used=5,则新大小为4

redis的list列表是使用双向链表来实现的

···

typedef struct listNode {

struct listNode pre; //前置节点

struct listNode next; //后置节点

void value; //节点的值

}

typedef struct list {

listNode head; //表头节点

listNode tail; //表尾节点

unsigned long len; //链表所包含的节点数量

void ( dup) (void ptr); //节点值赋值函数 这里有问题

void ( free) (void ptr); //节点值释放函数

int ( match) (void ptr, void key) //节点值对比函数

}

···

1：有序集合的底层实现之一是跳表， 除此之外跳表它在 Redis 中没有其他应用。

2：整数集合（intset）是集合键的底层实现之一： 当一个集合只包含整数值元素， 并且这个集合的元素数量不多时， Redis 就会使用整数集合作为集合键的底层实现。

3：数据少是，使用ziplist(压缩列表)，占用连续内存，每项元素都是(数据+score)的方式连续存储，按照score从小到大排序。ziplist为了节省内存，每个元素占用的空间可以不同，对于大数据(long long),就多用一些字节存储，而对于小的数据(short)，就少用一些字节来存储。因此查找的时候需要按顺序遍历。ziplist省内存但是查找效率低。

无序集合可以用整数集合(intset)或者字典实现

Redis的50版本中，放出一个新的数据结构Stream。其实也是一个队列，没一个不同的key对应的是不同的队列，没个队列的元素，也就是消息，都有一个msgid，并且需要保证msgid是严格递增的。在Stream当中，消息是默认持久化的，即便是Redis重启，也能够读取到信息。

Stream的多播，与其它队列系统相似，对不同的消费者，也有消费者Group这样的概念，不同的消费组，可以消费通一个消息，对于不同的消费组，都维护一个Idx下标，表示这一个消费群组费到了哪里，每次进行消费，都会更新一下这个下标，往后面一位进行偏移。

跳跃表是一种有序数据结构，它通过在每个节点中维持多个指向其它节点的指针，从而大道快速访问节点的目的，具有以下性质：

1：有很多层结构组成

2：每一层都是一个有序的链表，排列顺序为由高到低，都至少包含两个链表节点，分别是前面的head节点和后面的nil节点

3：最底层的链表包含了所有的元素

4：如果一个元素出现在某一层的链表中，那么在该层之下的链表也全部都会出现

5：链表中的每个节点都包含两个指针，一个指向同一层的下一个链表节点，另一个指向下一层的通一个链表节点

多个跳跃表节点构成一个跳跃表

1：搜索，从最高层的链表节点开始，如果比当前节点要大和比当前层的下一个节点要小，那么则往下找，也及时和当前层的下一层的节点下一个节点

2：插入，首先确定插入的层数，有一种方法是抛一个硬币，如果是正面就累加，直到遇到反面为止，最后记录正面的次数作为插入的层数，当确定插入的层数K后，则需要将新元素插入从底层到K层

3：删除，在各个层中找到包含指定值得节点，然后将节点从链表中删除即可，如果删除以后只剩下头尾两个节点，则删除这一层。

整数集合是Redis用于保存整数值集合的抽象数据类型，它可以保存int16_t、int32_t、int64_t的整数值，并且保证集合中不会出现重复元素。

整数集合的每个元素都是contents数组的一个数据项，他们按照从小到大的顺序排列，并且不包含任何重复项。

length属性记录了contents数组的大小。

需要注意的是虽然contents数组声明为int8_t类型，但是实际上contents数组并不保存任何int8_t类型的值，其真正类型由encoding来决定。

压缩列表(ziplist)是Redis为了节省内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型数据结构，一个压缩列表可以包含任意多个节点(entry)，每个节点可以保存一个字节数组或一个整数值。

压缩列表的原理：压缩列表并不是对数据利用某种算法进行压缩的，而是将数据按照一定规则编码在一块连续的内存区域，目的是节省内存。

压缩列表的每个节点构成如下：

集合的数据是唯一的，插入之后再次插入时不会执行

(1)查询集合里面元素的数量

(2)从集合中获取数据

--如果count省略则随机获取一条数据

--如果count为其他大于1的整数，则获取对应条数据

--如果count对应的证书大于集合总数据的条数，则获取集合所有数据

(3)获取集合中的所有数据

(4)判断集合中是否存在某个元素

--如果数据存在，则返回1，如果数据不存在，则返回0

既属于A集合又属于B/其他集合，集合数量可以是多个，多个代表对应所有集合的交集

A集合与B/其他集合所包含的所有数据，如果数据一样则去重，集合数量可以是多个，多个代表对应所有集合的并集

只属于A（key1）集合，不属于其他集合的数据

以上就是关于redis队列什么意思全部的内容，包括:redis队列什么意思、Redis有哪些慢 *** 作、Redis的五种数据结构及其底层实现原理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！