Redis Stream类型的使用

最近在看 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、 >

如果 Redis 中某个 key 对应的值是一个列表（list），您可以使用以下命令对其进行 *** 作：

1 LPUSH/ RPUSH: 向列表左侧或右侧添加元素。

命令格式：

LPUSH key value1 [value2 valuen]

RPUSH key value1 [value2 valuen]

如：LPUSH mylist "redis" "mongodb" "mysql"

2 LPOP/RPOP: 从列表左侧或右侧d出元素，相当于删除列表头部或尾部的元素，并返回该元素的值。

命令格式：

LPOP key

RPOP key

如：LPOP mylist

3 LINDEX: 获取列表中指定索引位置的元素。

命令格式：

LINDEX key index

如：LINDEX mylist 0

4 LRANGE: 获取列表中指定范围内的所有元素。

命令格式：

LRANGE key start stop

如：LRANGE mylist 0 2

5 LLEN: 获取列表的长度（即其中元素的个数）。

命令格式：

LLEN key

如：LLEN mylist

6 LREM: 从列表中删除指定数量的元素。可以通过给定的 count 参数来控制删除相同元素的个数。

命令格式：

LREM key count value

如：LREM mylist 2 "redis"

希望这些命令能够帮助您 *** 作 Redis 中的列表。

导读：Redis是被广泛使用的基础软件之一。对于工程师和,架构师，运维人员来说，了解Redis的高可用方案和背后的原理，是必备的基础知识。本文作者深入分析了Redis高可用的方方面面，并且做了有效总结，相信对广大读者可以起到很好的领路作用。

作者 codedump codedumpinfo 博主，多年从事互联网服务器后台开发工作。可访问作者博客阅读 codedump 更多文章。

Redis中为了实现高可用（High Availability，简称HA），采用了如下两个方式：

Redis中主从节点复制数据有全量复制和部分复制之分。

全量复制使用snyc命令来实现，其流程是：

旧版本全量复制功能，其最大的问题是从服务器断线重连时，即便在从服务器上已经有一部分数据了，也需要进行全量复制，这样做的效率很低，于是新版本的Redis在这部分做了改进。

新版本Redis使用psync命令来代替sync命令，该命令既可以实现完整全同步也可以实现部分同步。

执行复制的双方，主从服务器，分别会维护一个复制偏移量：

主服务器内部维护了一个固定长度的先进先出队列做为复制积压缓冲区，其默认大小为1MB。

在主服务器进行命令传播时，不仅会将写命令同步到从服务器，还会将写命令写入复制积压缓冲区。

每个Redis服务器，都有其运行ID，运行ID由服务器在启动时自动生成，主服务器会将自己的运行ID发送给从服务器，而从服务器会将主服务器的运行ID保存起来。

从服务器Redis断线重连之后进行同步时，就是根据运行ID来判断同步的进度：

有了前面的准备，下面开始分析psync命令的流程：

前面两种情况主服务器收到psync命令之后，会出现以下三种可能：

Redis使用哨兵机制来实现高可用(HA)，其大概工作原理是：

以上将Redis节点分为两类：

以上是大体的流程，这个流程需要解决以下几个问题：

以下来逐个回答这些问题。

哨兵节点通过三个定时监控任务监控Redis数据节点的服务可用性。

每隔10秒，每个哨兵节点都会向主、从Redis数据节点发送info命令，获取新的拓扑结构信息。

Redis拓扑结构信息包括了：

这样，哨兵节点就能从info命令中自动获取到从节点信息，因此那些后续才加入的从节点信息不需要显式配置就能自动感知。

这一 *** 作实际上完成了两件事情： 发现新的哨兵节点：如果有新的哨兵节点加入，此时保存下来这个新哨兵节点的信息，后续与该哨兵节点建立连接。 交换主节点的状态信息，作为后续客观判断主节点下线的依据。

每隔1秒，每个哨兵节点向主、从数据节点以及其他sentinel节点发送ping命令做心跳探测，这个心跳探测是后续主观判断数据节点下线的依据。

上面三个监控任务中的第三个探测心跳任务，如果在配置的down-after-milliseconds之后没有收到有效回复，那么就认为该数据节点“主观下线（sdown）”。

为什么称为“主观下线”？因为在一个分布式系统中，有多个机器在一起联动工作，网络可能出现各种状况，仅凭一个节点的判断还不足以认为一个数据节点下线了，这就需要后面的“客观下线”。

当一个哨兵节点认为主节点主观下线时，该哨兵节点需要通过”sentinel is-master-down-by addr”命令向其他哨兵节点咨询该主节点是否下线了，如果有超过半数的哨兵节点都回答了下线，此时认为主节点“客观下线”。

当主节点客观下线时，需要选举出一个哨兵节点做为哨兵领导者，以完成后续选出新的主节点的工作。

这个选举的大体思路是：

可以看到，这个选举领导者的流程很像raft中选举leader的流程。

在剩下的Redis从节点中，按照以下顺序来选择新的主节点：

选择了新的主节点之后，还需要最后的流程让该节点成为新的主节点：

原文地址：

>

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