python使用redis在实际场景使用_redis精进 – list的使用和应用场景

redis精进 – list的使用和应用场景

最近在精进学习Redis，边学边写先赞后读，养成习惯

一、List类型使用说明list类型是用来存储多个有序的字符串的，支持存储2^32次方-1个元素。

redis可以从链表的两端进行插入(pubsh)和弹出(pop)元素,充当队列或者栈

支持读取指定范围的元素集

读取指定下标的元素等注意它是链表而不是数组。这意味着 list 的插入和删除操作非常快，时间复杂度为 O(1)，但是索引定位很慢，时间复杂度为 O(n)

另外当列表弹出了最后一个元素之后，该数据结构自动被删除，内存被回收。

二、String类型常用命令：

右边进左边出：队列#进入队列

>rpush books python java golang

(integer) 3

#队列长度

>llen books

(integer) 3

#取出队列

>lpop books

"python"

>lpop books

"java"

>lpop books

"golang"

>lpop books

(nil)

右边进右边出：栈#入栈

>rpush books python java golang

(integer) 3

#出栈

>rpop books

"golang"

>rpop books

"java"

>rpop books

"python"

>rpop books

(nil)

慢操作

慢操作

lindex 相当于 Java 链表的get(int index)方法，它需要对链表进行遍历，性能随着参数index增大而变差。>rpush books python java golang

(integer) 3

>lindex books 1 # O(n) 慎用

"java"

>lrange books 0 -1 # 获取所有元素，O(n) 慎用

1) "python"

2) "java"

3) "golang"

>ltrim books 1 0 # O(n) 慎用 这其实是清空了整个列表，因为区间范围长度为负

OK

>llen books

(integer) 0

ltrim 和字面意思不太一样，与其说去除不如说保留。因为 ltrim 两个参数start_index和end_index定义了一个区间内的值将被保留下来。

这使它非常适合实现一个定长的链表

三、使用场景：链表用来做异步队列

链表常用来做异步队列使用将需要延后处理的任务结构体序列化(JSON)成字符串塞进 Redis 的列表

另一个线程从这个列表中轮询数据进行处理。

lpush + lpop = stack 先进后出的栈

lpush + rpop = queue 先进先出的队列

lpush + ltrim = capped collection 有限集合

lpush + brpop = message queue 消息队列

Redis 队列绕不开的消息丢失问题

一般借助List来实现消息队列:通过命令LPUSH(BLPUSH)把消息入队

通过命令RPOP(BRPOP)获取消息。

但这种方式实现的队列是不安全的。

因为RPOP(BRPOP)命令的特性：移除list的队尾元素(消息)并返回给客户端。这时该元素只存在于客户端的上下文中，redis服务器中没有这个元素.

如果客户端在处理元素的过程崩溃了，那么这个元素就永远丢失了。这种情况导致：客户端虽然成功收到了消息，但是却没有处理它。

试图抢救一下

那怎么来实现一个更安全的队列呢？

可以试试redis的RPOPLPUSH (或者其阻塞版本的 BRPOPLPUSH)命令。

具体是操作是：在A队列推出元素(并删除)时，保存元素到 B队列。

如果处理 元素 的客户端奔溃了，还可以在B队列找到redis>RPUSH mylist "one"

(integer) 1

redis>RPUSH mylist "two"

(integer) 2

redis>RPUSH mylist "three"

(integer) 3

redis>RPOPLPUSH mylist myotherlist

"three"

redis>LRANGE mylist 0 -1

1) "one"

2) "two"

redis>LRANGE myotherlist 0 -1

1) "three"

redis>

这种方法存在两个问题，多个消费者同时将消息转存入第二个队列，第二队列会出现( 已执行、未执行 )消息堆积

假设你的消息很特别，内容不会重复，你可以通过lrem a 0 "元素"函数找到并删除消息，另外启动的那个专门处理第二个队列的client面对的队列中的信息数量必须很小，如果很大client处理不过来又不能使用并发，因为使用并发必须将消息pop出队列2，如果pop出队列2，那就又回到了我们本来要绕开的问题。

最后

所以折腾试试，发现redislist做消费者确认ACK麻烦

不能重复消费，一旦消费就会被删除

队列不去重

因此对于一致性要求高的场景，队列建议使用Redis 5的 Stream 或者 RocketMQ。

目前还没发现特别适合redis list使用场景，有想到的小伙伴留言交流下❤️

https://juejin.im/post/5df77d8bf265da33f718b654