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

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

最近在精进学习Redis，边学边写

先赞后读，养成习惯

1、List类型使用说明

• list类型是用来存储多个有序的字符串的，支持存储2^32次方-1个元素。
• redis能够从链表的两端进行插入（pubsh）和弹出（pop）元素,充当队列或者栈
• 支持读取指定范围的元素集
• 读取指定下标的元素等

注意它是链表而不是数组。这意味着 list 的插入和删除操做很是快，时间复杂度为 O(1)，可是索引定位很慢，时间复杂度为 O(n)
另外当列表弹出了最后一个元素以后，该数据结构自动被删除，内存被回收。
复制代码

2、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定义了一个区间内的值将被保留下来。
这使它很是适合实现一个定长的链表

3、使用场景：链表用来作异步队列

链表经常使用来作异步队列使用

• 将须要延后处理的任务结构体序列化（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使用场景，有想到的小伙伴留言交流下❤️