2008iis网站建设,谷歌seo博客,江门关键词按天优化,网站流量不够目录 一、字符串
1、字符串编码
2、编码的选择
二、哈希表
1、字典编码的哈希表
2、压缩列表编码的哈希表
3、编码的选择
4、哈希命令的实现
三、列表
1、 编码的选择
2、 列表命令的实现
3、阻塞的条件
4、 阻塞
5、 阻塞因 LPUSH 、RPUSH 、LINSERT 等添加命令而…目录 一、字符串
1、字符串编码
2、编码的选择
二、哈希表
1、字典编码的哈希表
2、压缩列表编码的哈希表
3、编码的选择
4、哈希命令的实现
三、列表
1、 编码的选择
2、 列表命令的实现
3、阻塞的条件
4、 阻塞
5、 阻塞因 LPUSH 、RPUSH 、LINSERT 等添加命令而被取消
6、 先阻塞先服务(FBFS)策略
7、 阻塞因超过最大等待时间而被取消 一、字符串
REDIS_STRING (字符串)是 Redis 使用得最为广泛的数据类型它除了是 SET 、GET 等命令 的操作对象之外数据库中的所有键以及执行命令时提供给 Redis 的参数都是用这种类型 保存的。
1、字符串编码
字符串类型分别使用 REDIS_ENCODING_INT 和 REDIS_ENCODING_RAW 两种编码: REDIS_ENCODING_INT 使用 long 类型来保存 long 类型值。 REDIS_ENCODING_RAW 则使用 sdshdr 结构来保存 sds (也即是 char* )、long long 、 double 和 long double 类型值。 换句话来说在 Redis 中只有能表示为 long 类型的值才会以整数的形式保存其他类型 的整数、小数和字符串都是用 sdshdr 结构来保存。 2、编码的选择
新创建的字符串默认使用 REDIS_ENCODING_RAW 编码在将字符串作为键或者值保存进数据库时程序会尝试将字符串转为 REDIS_ENCODING_INT 编码。 3.2.3 字符串命令的实现Redis 的字符串类型命令基本上是通过包装 sds 数据结构的操作函数来实现的没有什么需 要说明的地方。
二、哈希表
REDIS_HASH (哈希表) 是 HSET 、 HLEN 等命令的操作对象它使用REDIS_ENCODING_ZIPLIST 和 REDIS_ENCODING_HT 两种编码方式: 1、字典编码的哈希表
当哈希表使用字典编码时程序将哈希表的键(key)保存为字典的键将哈希表的值(value)保存为字典的值。
哈希表所使用的字典的键和值都是字符串对象。
下图展示了一个包含三个键值对的哈希表: 2、压缩列表编码的哈希表
当使用 REDIS_ENCODING_ZIPLIST 编码哈希表时程序通过将键和值一同推入压缩列表从而 形成保存哈希表所需的键 -值对结构:
新添加的 key-value 对会被添加到压缩列表的表尾。 当进行查找/删除或更新操作时程序先定位到键的位置然后再通过对键的位置来定位值的位置。
3、编码的选择
创建空白哈希表时程序默认使用 REDIS_ENCODING_ZIPLIST 编码当以下任何一个条件被满
足时程序将编码从切换为 REDIS_ENCODING_HT : • 哈希表中某个键或某个值的长度大于 server.hash_max_ziplist_value (默认值为 64)。 • 压缩列表中的节点数量大于server.hash_max_ziplist_entries(默认值为512)。
4、哈希命令的实现
哈希类型命令的实现全都是对字典和压缩列表操作函数的包装以及几个在两种编码之间进行转换的函数没有特别要讲解的地方。
三、列表
REDIS_LIST (列表) 是 LPUSH 、 LRANGE 等命令的操作对象它使用
REDIS_ENCODING_ZIPLIST 和 REDIS_ENCODING_LINKEDLIST 这两种方式编码: 1、 编码的选择
创建新列表时 Redis 默认使用 REDIS_ENCODING_ZIPLIST 编码当以下任意一个条件被满足时列表会被转换成 REDIS_ENCODING_LINKEDLIST 编码: • 试 图 往 列 表 新 添 加 一 个 字 符 串 值 且 这 个 字 符 串 的 长 度 超 过server.list_max_ziplist_value (默认值为 64 )。 • ziplist 包含的节点超过 server.list_max_ziplist_entries (默认值为 512 )。
2、 列表命令的实现
因为两种底层实现的抽象方式和列表的抽象方式非常接近所以列表命令几乎就是通过一对一地映射到底层数据结构的操作来实现的。 既然这些映射都非常直观这里就不做赘述了在以下的内容中我们将焦点放在 BLPOP 、BRPOP 和 BRPOPLPUSH 这个几个阻塞命令的实现原理上。
3、阻塞的条件
BLPOP 、BRPOP 和 BRPOPLPUSH 三个命令都可能造成客户端被阻塞以下将这些命令统 称为列表的阻塞原语。
阻塞原语并不是一定会造成客户端阻塞:
• 只有当这些命令被用于空列表时它们才会阻塞客户端。
• 如果被处理的列表不为空的话它们就执行无阻塞版本的 LPOP 、RPOP 或 RPOPL- PUSH 命令。
作为例子以下流程图展示了 BLPOP 决定是否对客户端进行阻塞过程: 4、 阻塞 当一个阻塞原语的处理目标为空键时执行该阻塞原语的客户端就会被阻塞。 阻塞一个客户端需要执行以下步骤:
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. 强制脱离:客户端强制终止和服务器的连接或者服务器停机。
以下内容将分别介绍被动脱离和主动脱离的实现方式。
5、 阻塞因 LPUSH 、RPUSH 、LINSERT 等添加命令而被取消
通过将新元素推入造成客户端阻塞的某个键中可以让相应的客户端从阻塞状态中脱离出来(取消阻塞的客户端数量取决于推入元素的数量)。 LPUSH 、RPUSH 和 LINSERT 这三个添加新元素到列表的命令在底层都由一个
pushGenericCommand 的函数实现这个函数的运作流程如下图:
当向一个空键推入新元素时pushGenericCommand 函数执行以下两件事:
1. 检查这个键是否存在于前面提到的 server.db[i]-blocking_keys 字典里如果是的 话那么说明有至少一个客户端因为这个 key 而被阻塞程序会为这个键创建一个 redis.h/readyList 结构并将它添加到 server.ready_keys 链表中。
2. 将给定的值添加到列表键中。 readyList 结构的定义如下:
readyList 结构的 key 属性指向造成阻塞的键而 db 则指向该键所在的数据库。
typedef struct readyList { redisDb *db;robj *key;
} readyList;
举个例子假设某个非阻塞客户端正在使用 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 函数这个函数执行以下操作: 如果 server.ready_keys 不为空那么弹出该链表的表头元素并取出元素中的 readyList 值。 根据readyList值所保存的key和db在server.blocking_keys中查找所有因为key 而被阻塞的客户端(以链表的形式保存)。 如果key不为空那么从key中弹出一个元素并弹出客户端链表的第一个客户端然 后将被弹出元素返回给被弹出客户端作为阻塞原语的返回值。 根据readyList结构的属性删除server.blocking_keys中相应的客户端数据取消 客户端的阻塞状态。 继续执行步骤 3 和 4 直到 key 没有元素可弹出或者所有因为 key 而阻塞的客户端都 取消阻塞为止。 继续执行步骤 1 直到 ready_keys 链表里的所有 readyList 结构都被处理完为止。用一段伪代码描述以上操作可能会更直观一些: def handleClientsBlockedOnLists(): # 执行直到 ready_keys 为空while server.ready_keys ! NULL: # 弹出链表中的第一个 readyListrl server.ready_keys.pop_first_node() # 遍历所有因为这个键而被阻塞的客户端for client in all_client_blocking_by_key(rl.key, rl.db):# 只要还有客户端被这个键阻塞就一直从键中弹出元素# 如果被阻塞客户端执行的是 BLPOP 那么对键执行 LPOP # 如果执行的是 BRPOP 那么对键执行 RPOPelement rl.key.pop_element()if element NULL:# 键为空跳出 for 循环# 余下的未解除阻塞的客户端只能等待下次新元素的进入了 breakelse:# 清除客户端的阻塞信息 server.blocking_keys.remove_blocking_info(client) # 将元素返回给客户端脱离阻塞状态 client.reply_list_item(element) 6、 先阻塞先服务(FBFS)策略 值得一提的是当程序添加一个新的被阻塞客户端到 server.blocking_keys 字典的链表中 时它将该客户端放在链表的最后而当 handleClientsBlockedOnLists 取消客户端的阻塞 时它从链表的最前面开始取消阻塞:这个链表形成了一个 FIFO 队列最先被阻塞的客户端 总值最先脱离阻塞状态Redis 文档称这种模式为先阻塞先服务(FBFSfirst-block-first-serve)。 举个例子在下图所示的阻塞状况中如果客户端对数据库执行 PUSH key3 value 那么只有 client3 会被取消阻塞client6 和 client4 仍然阻塞;如果客户端对数据库执行 PUSH key3 value1 value2 那么 client3 和 client4 的阻塞都会被取消而客户端 client6 依然处于 阻塞状态: 7、 阻塞因超过最大等待时间而被取消
前面提到过当客户端被阻塞时所有造成它阻塞的键以及阻塞的最长时限会被记录在客户端里面并且该客户端的状态会被设置为“正在阻塞” 。
每次 Redis 服务器常规操作函数(server cron job)执行时程序都会检查所有连接到服务器 的客户端查看那些处于“正在阻塞”状态的客户端的最大阻塞时限是否已经过期如果是的话 就给客户端返回一个空白回复然后撤销对客户端的阻塞。
可以用一段伪代码来描述这个过程:
def server_cron_job(): # 其他操作 ...# 遍历所有已连接客户端for client in server.all_connected_client:# 如果客户端状态为“正在阻塞”并且最大阻塞时限已到达 if client.state BLOCKING and \client.max_blocking_timestamp current_timestamp(): # 那么给客户端发送空回复, 脱离阻塞状态client.send_empty_reply()# 并清除客户端在服务器上的阻塞信息server.blocking_keys.remove_blocking_info(client)
# 其他操作 ...
