Redis数据结构之string类型和list类型

        String是redis最基础和最常用的数据结构，其值最大能存储 512MB，可以是简单字符串、复杂的xml/json的字符串、二进制图像或者音频的字符串、以及可以是数字的字符串。String底层使用的是SDS，是Redis的一种基本数据结构，主要是用于存储字符串和整数。

    21  set命令  set key value

        用于设置给定key的值，如果key存储了其他值，覆盖写入，无视类型。

    22 get命令 get key

        获取指定key的值，如果key不存在返回nil

    23 getset命令 get key [value]

        该命令用于获取指定的key的旧值，然后按照新值对key进行赋值。当key中没有旧值的时候返回nil。

    24 mget命令 get key1 [key2 keyN]

        返回多个key的值，某个key不存在时返回nil

    25 decr命令 decr key

        对key对应的数字做减1 *** 作。如果key不存在，那么在 *** 作之前，这个key对应的值会被置为0。如果key有一个错误类型的value或者是一个不能表示成数字的字符串，就返回错误。

    26 incr命令 incr key

        对key对应的数字做减1 *** 作。如果key不存在，那么在 *** 作之前，这个key对应的值会被置为0。如果key有一个错误类型的value或者是一个不能表示成数字的字符串，就返回错误。

    27 append命令 append key value

    如果 key 已经存在，并且值为字符串，那么这个命令会把 value 追加到原来值（value）的结尾。 如果 key 不存在，那么它将首先创建一个空字符串的key，再执行追加 *** 作，这种情况 APPEND 将类似于 SET *** 作。返回append后字符串值（value）的长度。

    31 SDS动态字符串

        struct sdshdr {

            unsigned int len;

            unsigned int free;

            char buf[];

        }

        其中，buf表示数据空间，用于存储字符串；len表示buf中已占用的字节数；free表示空闲的字节数。

    32 新的SDS结构

        增加了一个flags来标识类型，用一个字节（8位）来存储，前3位表示字符串的类型；剩余5位，存储长度小于32的段字符串。

        创建 SDS 的大致流程是这样的：首先根据字符串长度计算得到 type，根据 type 计算头部所需长度，然后动态分配内存空间。

        注意：① 创建空字符串时，SDS_TYPE_5 被强制转换为 SDS_TYPE_8（原因是创建空字符串后，内容可能会频繁更新而引发扩容 *** 作，故直接创建为 sdshdr8）

                    ②长度计算有 +1 *** 作，因为结束符 \0 会占用一个长度的空间。

                    ③返回的是指向 buf 的指针 s。

    41 session共享

    42 计数器（商品浏览记录）

     43 访问限速

    list类型用来存储多个有序的字符串，列表当中的每一个字符看做一个元素，一个列表当中可以存储有一个或者多个元素，redis的list支持存储2^32次方-1个元素。

    Redis可以从两端push和pop元素，支持读取指定范围或者制定下表的元素。list是一种灵活的链式结构，可以充当队列或者栈的角色。

    list的元素是有序的，且列表内的元素是可以重复的。

    注意：Redis32以前，列表底层的编码是ziplist(压缩列表)和linkedlist(双向列表)实现的，因为双线列表占用的内存比压缩列表多，所以当创建新的列表键时，列表会优先考虑用压缩列表，只有在需要的时候才会转换到双向列表实现。32以后重新引入了一个quicklist，列表底层都是有quicklist实现，quicklist是一个由ziplist组成的双向列表，每个节点使用ziplist来存储数据。

       21 Lpush命令 lpush key value

        将一个或多个值插入到列表头部。 如果 key 不存在，则创建list，然后再插入数据 *** 作。 当 key 存在但不是列表类型时，返回一个错误。

    22 Rpush命令 rpush key value

        将一个或多个值从list的尾部插入

    23 Blpop命令 blpop key seconds

        Blpop是取出列表的第一个元素，如果list中没有元素则会一直等到到超时，或者发现有数据为止，seconds是指定多少秒返回。如没有数据，则返回nil。

        同理，Bropo为移除list列表的最后一个元素

    24 Linsert命令 linsert key before/after val1 val2

        在list列表的某一个元素前或者后插入另外一个元素。当指的的元素不存在时，不执行任何动作。如果列表不存在时，视为空列表，不执行任何动作。

    25 Lindex命令 lindex key index

        通过链表的下标获取列表中的元素，可以是-1表示链表最后一个元素，-2代表倒数第二个元素，没有返回nil

    26 Llen命令 llen key

        返回list的长度，如果list不存在，返回0

    27 Lrange命令

        返回指定list区间内的元素，区间以偏移量start和end决定。其中 0 表示列表的第一个元素， 1 表示列表的第二个元素，以此类推。 也可以使用负数下标，以 -1 表示列表的最后一个元素， -2 表示列表的倒数第二个元素，以此类推。

    51 队列秒杀抢购

        list类型的lpop和rpush（或者反过来，lpush和rpop）能实现队列的功能，故而可以用Redis的list类型实现简单的点对点的消息队列。不过不推荐在实战中这么使用，因为现在已经有Kafka、NSQ、RabbitMQ等成熟的消息队列了，它们的功能已经很完善了，除非是为了更深入地理解消息队列，不然没必要去重复造轮子。

    52 排行榜

        list类型的lrange命令可以分页查看队列中的数据。可将每隔一段时间计算一次的排行榜存储在list类型中。只有定时计算的排行榜才适合使用list类型存储，与定时计算的排行榜相对应的是实时计算的排行榜，list类型不能支持实时计算的排行榜。

redis只是提供一个高性能的、原子 *** 作的分布式队列实现。具体的业务还是得需要你自己定制。 你的需求实际上是一个变形的生产者-消费者实现。对于此类需求，主要是将请求和实际的处理过程解耦，一般都是采取异步的方式来通知请求方，这跟用不用

最近在看 redis 这方面的知识，发现在 redis5 中产生了一种新的数据类型 Stream ，它和 kafka 的设计有些类似，可以当作一个简单的消息队列来使用。

解释：

xadd 命令 返回的是数据的id, xx-yy (xx指的是毫秒数,yy指的是在这个毫秒内的第几条消息)

指定指定Stream的大小比模糊指定Stream的大小会稍微多少消耗一些性能。

~ 模糊指定流的大小，可以看到指定的是1，实际上已经到了3

使用redis的事务 *** 作，获取到同一毫秒产生的多条数据，时间戳一样，序列号不一样

-: 表示最小id的值

+: 表示最大id的值

(: 表示开区间

直接写 毫秒 不写后面的序列号即可。

start 和 end 的值写的一样即可获取单挑数据。

使用 count 进行限制

使用方式和 XRANGE 类似，略。

需求： 往Stream中加入3条消息，然后删除第2条消息

注意：

需要注意的是，我们从Stream中删除一个消息，这个消息并不是被真正的删除了，而是被 标记为删除 ，这个时候这个消息还是占据着内容空间的。如果所有Stream中所有的消息都被标记删除，这个时候才会回收内存空间。但是这个Stream并不会被删除。

查看Stream中元素的长度

注意：

如果 xlen 后方的 key 不存在则返回0，否则返回元素的个数。

上方的意思是，保留 stream-key 这个Stream中最后的2个消息。

minid 是删除比这个id小的数据，本地测试的时候 没有测试出来 ，略。

XREAD 只是读取消息，读取完之后并不会删除消息。 使用 XREAD 读取消息，是完全独立与消费者组的，多个客户端可以同时读取消息。

count 限制单次读取最后的消息，因为当前读取可能没有这么多。

即读取队列尾的下一个消息，在非阻塞模式下始终是 nil

注意：

1、创建Stream的名称是 stream-key

2、创建2个消息，aa和bb

$ 表示从最后一个元素消费，不包括Stream中的最后一个元素，即消费最新的消息。

1636362619125-0 某个消息的具体的ID,这个 g3 消费者组中的消息都是 大于> 这个id的消息。

也可以通过 xautoclaim 来实现。

1、 >

虽然消费者是异步处理消息，但是，消费者仍然需要按照生产者发送消息的顺序来处理消息，避免后发送的消息被先处理了。对于要求消息保序的场景来说，一旦出现这种消息被乱序处理的情况，就可能会导致业务逻辑被错误执行，从而给业务方造成损失。

消费者从消息队列读取消息时，有时会因为网络堵塞而出现消息重传的情况。此时，消费者可能会收到多条重复的消息。对于重复的消息，消费者如果多次处理的话，就可能造成一个业务逻辑被多次执行，如果业务逻辑正好是要修改数据，那就会出现数据被多次修改的问题了。

消费者在处理消息的时候，还可能出现因为故障或宕机导致消息没有处理完成的情况。此时，消息队列需要能提供消息可靠性的保证，也就是说，当消费者重启后，可以重新读取消息再次进行处理，否则，就会出现消息漏处理的问题了。

List 本身就是按先进先出的顺序对数据进行存取的，所以，如果使用 List 作为消息队列保存消息的话，就已经能满足消息保序的需求了。

生产者提供一个消息id，消费者要把已经处理过的消息 ID 号记录下来。当收到一条消息后，消费者程序就可以对比收到的消息 ID 和记录的已处理过的消息 ID，来判断当前收到的消息有没有经过处理。如果已经处理过，那么，消费者程序就不再进行处理了。

为了留存消息，List 类型提供了 BRPOPLPUSH 命令，这个命令的作用是让消费者程序从一个 List 中读取消息，同时，Redis 会把这个消息再插入到另一个 List（可以叫作备份 List）留存。这样一来，如果消费者程序读了消息但没能正常处理，等它重启后，就可以从备份 List 中重新读取消息并进行处理了。

在生产者往 List 中写入数据时，List 并不会主动地通知消费者有新消息写入，如果消费者想要及时处理消息，就需要在程序中不停地调用 RPOP 命令（比如使用一个 while(1) 循环）。如果有新消息写入，RPOP 命令就会返回结果，否则，RPOP 命令返回空值，再继续循环。所以，即使没有新消息写入 List，消费者也要不停地调用 RPOP 命令，这就会导致消费者程序的 CPU 一直消耗在执行 RPOP 命令上，带来不必要的性能损失。为了解决这个问题，Redis 提供了 BRPOP 命令。BRPOP 命令也称为阻塞式读取，客户端在没有读到队列数据时，自动阻塞，直到有新的数据写入队列，再开始读取新数据。和消费者程序自己不停地调用 RPOP 命令相比，这种方式能节省 CPU 开销。

发送消息日志

消费消息日志

Streams 是 Redis 专门为消息队列设计的数据类型，它提供了丰富的消息队列 *** 作命令。

XADD：插入消息，保证有序，可以自动生成全局唯一 ID；

XREAD：用于读取消息，可以按 ID 读取数据；

XREADGROUP：按消费组形式读取消息；

XPENDING ：XPENDING 命令可以用来查询每个消费组内所有消费者已读取但尚未确认的消息，

XACK：XACK 命令用于向消息队列确认消息处理已完成。

监听器

监听器容器

初始化消息队列(integral-queue)和消费者组(integral-group),执行RedisMqTestinitMessageQueue()即可

可参考List实现的处理方式

可使用RedisMqTestgetPendingQueue()获取未成功消费的消息队列进行处理

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)，每个节点可以保存一个字节数组或一个整数值。

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

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

以上就是关于Redis数据结构之string类型和list类型全部的内容，包括:Redis数据结构之string类型和list类型、redis 可以创建一个定长的队列吗、Redis Stream类型的使用等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！