Redisbook学习笔记(3)数据类型之列表
REDIS_LIST(列表)是LPUSH、LRANGE等命令的操作对象,它使用REDIS_ENCODING_ZIPLIST和REDIS_ENCODING_LINKEDLIST这两种方式编码:编码的选择创建新列表时Redis
REDIS_LIST (列表) 是LPUSH 、LRANGE 等命令的操作对象, 它使用
REDIS_ENCODING_ZIPLIST 和REDIS_ENCODING_LINKEDLIST 这两种方式编码:
编码的选择
创建新列表时Redis 默认使用REDIS_ENCODING_ZIPLIST 编码,当以下任意一个条件被满足
时,列表会被转换成REDIS_ENCODING_LINKEDLIST 编码:
试图往列表新添加一个字符串值, 且这个字符串的长度超过
server.list_max_ziplist_value (默认值为64 )。
ziplist 包含的节点超过server.list_max_ziplist_entries (默认值为512 )。
列表命令的实现
因为两种底层实现的抽象方式和列表的抽象方式非常接近,所以列表命令几乎就是通过一对一
地映射到底层数据结构的操作来实现的。
我们将焦点放在BLPOP 、BRPOP 和BRPOPLPUSH 这个几个阻塞命令的实现原理上。
阻塞的条件
BLPOP 、BRPOP 和BRPOPLPUSH 三个命令都可能造成客户端被阻塞,以下将这些命令统
称为列表的阻塞原语。
阻塞原语并不是一定会造成客户端阻塞:
只有当这些命令被用于空列表时,它们才会阻塞客户端。
如果被处理的列表不为空的话,它们就执行无阻塞版本的LPOP 、RPOP 或RPOPLPUSH
命令。
作为例子,以下流程图展示了BLPOP 决定是否对客户端进行阻塞过程:
阻塞
当一个阻塞原语的处理目标为空键时,执行该阻塞原语的客户端就会被阻塞。
阻塞一个客户端需要执行以下步骤:
1. 将客户端的状态设为“正在阻塞” ,并记录阻塞这个客户端的各个键,以及阻塞的最长时限
(timeout)等数据。
2. 将客户端的信息记录到server.db[i]->blocking_keys 中(其中i 为客户端所使用的数
据库号码)。
3. 继续维持客户端和服务器之间的网络连接,但不再向客户端传送任何信息,造成客户端
阻塞。
步骤2 是将来解除阻塞的关键,server.db[i]->blocking_keys 是一个字典,字典的键是那
些造成客户端阻塞的键,而字典的值是一个链表,链表里保存了所有因为这个键而被阻塞的客
户端(被同一个键所阻塞的客户端可能不止一个):
在上图展示的blocking_keys 例子中,client2 、client5 和client1 三个客户端就正被
key1 阻塞,而其他几个客户端也正在被别的两个key 阻塞。
当客户端被阻塞之后,脱离阻塞状态有以下三种方法:
1. 被动脱离:有其他客户端为造成阻塞的键推入了新元素。
2. 主动脱离:到达执行阻塞原语时设定的最大阻塞时间。
3. 强制脱离:客户端强制终止和服务器的连接,或者服务器停机。
以下内容将分别介绍被动脱离和主动脱离的实现方式。
阻塞因LPUSH 、RPUSH 、LINSERT 等添加命令而被取消
通过将新元素推入造成客户端阻塞的某个键中,可以让相应的客户端从阻塞状态中脱离出来
(取消阻塞的客户端数量取决于推入元素的数量)。
LPUSH 、RPUSH 和LINSERT 这三个添加新元素到列表的命令, 在底层都由一个
pushGenericCommand 的函数实现,这个函数的运作流程如下图:
当向一个空键推入新元素时,pushGenericCommand 函数执行以下两件事:
1. 检查这个键是否存在于前面提到的server.db[i]->blocking_keys 字典里,如果是的
话,那么说明有至少一个客户端因为这个key 而被阻塞,程序会为这个键创建一个
redis.h/readyList 结构,并将它添加到server.ready_keys 链表中。
2. 将给定的值添加到列表键中。
readyList 结构的定义如下:
typedef struct readyList { redisDb *db; robj *key; } readyList;readyList 结构的key 属性指向造成阻塞的键,而db 则指向该键所在的数据库。
举个例子,假设某个非阻塞客户端正在使用0 号数据库,而这个数据库当前的blocking_keys
属性的值如下:
如果这时客户端对该数据库执行PUSH key3 value ,那么pushGenericCommand 将创建一个
db 属性指向0 号数据库、key 属性指向key3 键对象的readyList 结构,并将它添加到服务器
server.ready_keys 属性的链表中:
在我们这个例子中,到目前为止,pushGenericCommand 函数完成了以下两件事:
1. 将readyList 添加到服务器。
2. 将新元素value 添加到键key3 。
虽然key3 已经不再是空键,但到目前为止,被key3 阻塞的客户端还没有任何一个被解除阻塞
状态。
为了做到这一点,Redis 的主进程在执行完pushGenericCommand 函数之后,会继续调用
handleClientsBlockedOnLists 函数,这个函数执行以下操作:
1. 如果server.ready_keys 不为空, 那么弹出该链表的表头元素, 并取出元素中的
readyList 值。
2. 根据readyList 值所保存的key 和db ,在server.blocking_keys 中查找所有因为key
而被阻塞的客户端(以链表的形式保存)。
3. 如果key 不为空,那么从key 中弹出一个元素,并弹出客户端链表的第一个客户端,然
后将被弹出元素返回给被弹出客户端作为阻塞原语的返回值。
4. 根据readyList 结构的属性,删除server.blocking_keys 中相应的客户端数据,取消
客户端的阻塞状态。
5. 继续执行步骤3 和4 ,直到key 没有元素可弹出,或者所有因为key 而阻塞的客户端都
取消阻塞为止。
6. 继续执行步骤1 ,直到ready_keys 链表里的所有readyList 结构都被处理完为止。
上一篇: ob_start()求教解决思路
推荐阅读