Redis (二) -- List 数据类型

列表(List)通常有两种实现方案:链表和数组。
Redis 的列表是通过链表方式实现的,其优点是在列表头部或尾部的插入操作时间复杂度是 O(1) ;缺点是通过下标访问元素的效率不及数组列表。
如果需要频繁地访问一个很大集合的中间部分数据,可以采用 Sorted sets 数据结构。
 
小试牛刀
LPUSH 命令从左边(队列头)插入一个元素,RPUSH 命令从右边(队列尾)插入一个元素。LRANGE 命令从队列中取出元素:
127.0.0.1:6379> rpush mylist A
(integer) 1
127.0.0.1:6379> rpush mylist B
(integer) 2
127.0.0.1:6379> lpush mylist first
(integer) 3
127.0.0.1:6379> lrange mylist 0 -1
1) "first"
2) "A"
3) "B"
 
LRANGE 命令带两个参数,分别指定获取元素的起始下标和结束下标。下标都可以用负数,比如 -1 指定最后一个元素, -2 指定倒数第二个。
LPUSH 和 RPUSH 命令都可以一次插入多个元素:
127.0.0.1:6379> rpush mylist 1 2 3 4 5 'foo bar'
(integer) 6
127.0.0.1:6379> lrange mylist 0 -1
1) "1"
2) "2"
3) "3"
4) "4"
5) "5"
6) "foo bar"
127.0.0.1:6379> lpush mylist 11 12 13 14 15
(integer) 11
127.0.0.1:6379> lrange mylist 0 -1
 1) "15"
 2) "14"
 3) "13"
 4) "12"
 5) "11"
 6) "1"
 7) "2"
 8) "3"
 9) "4"
10) "5"
11) "foo bar"
 
LPOP 和 RPOP 两个命令可以从队列头(尾)中弹出元素:
127.0.0.1:6379> lrange mylist 0 -1
 1) "15"
 2) "14"
 3) "13"
 4) "12"
 5) "11"
 6) "1"
 7) "2"
 8) "3"
 9) "4"
10) "5"
11) "foo bar"
127.0.0.1:6379> rpop mylist
"foo bar"
127.0.0.1:6379> lrange mylist 0 -1
 1) "15"
 2) "14"
 3) "13"
 4) "12"
 5) "11"
 6) "1"
 7) "2"
 8) "3"
 9) "4"
10) "5"
127.0.0.1:6379> lpop mylist
"15"
127.0.0.1:6379> lrange mylist 0 -1
1) "14"
2) "13"
3) "12"
4) "11"
5) "1"
6) "2"
7) "3"
8) "4"
9) "5"
 
列表常规用法
列表结构用处多多,下面是两个典型场景:
  • 记录用户在社交网络的最近更新。
  • 采用生产者-消费者模式的进程间通信机制。
举例来说,两个流行的 Ruby 库 resque 和 sidekiq  都是基于 Redis 列表实现后台任务的。
Twitter 也是用 Redis 列表管理用户最近发表的微博消息。参见这个文章
 
Capped lists
很多时候我们的需求是保留列表中的最近 N 条记录,这时候可以使用 LTRIM 命令。LTRIM 命令跟 LRANGE 命令相似,不同的是 LTRIM 命令不是把范围内的元素回显,而是丢弃掉范围之外的元素。

 

127.0.0.1:6379> rpush mylist 1 2 3 4 5
(integer) 5
127.0.0.1:6379> ltrim mylist 0 2
OK
127.0.0.1:6379> lrange mylist 0 -1
1) "1"
2) "2"
3) "3"

 

上述命令告诉 Redis 仅保留下标 0 到 2 的元素,其余元素全部丢弃。

 

 

列表上的阻塞式操作
Redis 列表支持阻塞式访问操作,这使得它非常适合做进程间通信机制。
比如说我们的需求是一个进程不断把数据放入到列表中,另外一个进程从列表中读取数据执行任务。这是一个典型的生产者、消费者模式,可以这么实现:
1.生产者调用 LPUSH 命令把数据推到队列中
2.消费者调用 RPOP 命令从队列中读取并处理数据
 
这里其实有一个问题,就是当队列是空的时候,消费者每次调用 RPOP 命令得到的都是一个 NULL,这种情况下消费者不得不等待一段时间再次调用 RPOP 命令探查。这种轮询的方案有两个明显问题:
1.强迫 Redis 和客户端处理大量无用命令。(轮询期间每次 RPOP 返回的都只是 NULL)
2.增加了延迟,轮询一定会有间隔时间,比如间隔时间是一秒钟,那么平均获取到数据的延迟就是 500 毫秒。
不巧的是上述两个问题是此消彼长的关系,属于不可调和矛盾。
因此 Redis 引入了 BRPOP 和 BLPOP 命令,他们是与 RPOP 和 LPOP 对应的阻塞版本。
127.0.0.1:6379> brpop tasks 5
1) "tasks"
2) "do_something"
 
上述命令的含义是:等待 tasks 列表中的元素,如果五秒后还没有,就结束等待,返回 NULL。
超时时间指定为 0 表示一直等待;也可以一次指定监听多个列表:
127.0.0.1:6379> brpop tasks tasks2 0
1) "tasks2"
2) "do_something"
 
关于 BRPOP 命令,下面几点需要注意:
1. 客户端是按序服务的,就是多个客户端同时等待一个列表,如果列表中有值,优先返回给最先进入等待状态的客户端;
2. 返回值跟 RPOP 不一样,是一个两个元素的数组,第一个元素是列表 key 的名字,第二个元素才是列表的值;
3. 超时时间到了,会返回 NULL。
 
自动创建和删除 keys
上面的那些例子中,我们从来没手动创建 key,列表为空的时候也没有手动删除 key,实际上列表 key 的创建和删除操作都是 Redis 内部自动执行的。
不仅列表是这样,Redis 对其他集合类型的数据类型都是这么处理的。
 
关于 Redis key 的自动创建销毁有下面三条基本原则:
1. 向聚合数据类型中添加一个元素,如果目标 key 不存在,先创建一个空的聚合数据类型,再添加元素;
2. 从聚合类型中删除一个元素,如果删除后集合为空,则自动销毁对应的 key;
3. 对空集合调用类似 LLEN 这样的只读命令,或者删除元素命令,Redis 会返回给你一个看起来像这个 key 存在并且握着一个空集合的结果。
 
第一条规则的例子如下:
127.0.0.1:6379> del mylist
(integer) 1
127.0.0.1:6379> lpush mylist 1 2 3
(integer) 3
127.0.0.1:6379> set foo bar
OK
127.0.0.1:6379> lpush foo 1 2 3
(error) WRONGTYPE Operation against a key holding the wrong kind of value
 
现在来验证一下第二条规则:
127.0.0.1:6379> lpush mylist 1 2 3
127.0.0.1:6379> exists mylist
(integer) 1
127.0.0.1:6379> lpop mylist
"3"
127.0.0.1:6379> lpop mylist
"2"
127.0.0.1:6379> lpop mylist
"1"
127.0.0.1:6379> exists mylist
(integer) 0
 
接下来验证第三条规则:
127.0.0.1:6379> del mylist
(integer) 0
127.0.0.1:6379> llen mylist
(integer) 0
127.0.0.1:6379> lpop mylist
(nil)
 
翻译自:http://redis.io/topics/data-types-intro
 
 
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值