Redis 列表阻塞命令的实现
前言
在 Redis 的 列表(list) 命令中，有一些命令是阻塞模式的，比如：BRPOP, BLPOP, BRPOPLPUSH, 这些命令都有可能造成客户端的阻塞。下面总结一下 Redis 实现阻塞和取消阻塞的过程。
阻塞过程
当一个阻塞原语的处理目标为空键时， 执行该阻塞原语的客户端就会被阻塞。有以下步骤：
1：将客户端的状态设为“正在阻塞”， 并记录阻塞这个客户端的各个键，以及阻塞的最长时限(timeout) 等数据；
2：将客户端的信息记录到 server.db[i]->blocking_keys 中(其中 i 为客户端所使用的数据库号码)；
3：继续维持客户端和服务器之间的网络连接，但不再向客户端传送任何信息，造成客户端阻塞；
note: step2 中 service.db[i]->blocking_keys 是一个字典，键是那些造成客户端阻塞的键， 值是一个链表，链表里保存了所有因这个键而被阻塞的客户端，如下图所示：
阻塞的取消过程
阻塞的取消有三种方法：
【1】被动脱离：有其它客户端为造成阻塞的键推入了新元素；
【2】主动脱离：到达执行阻塞原语时设定的最大阻塞时间(timeout)；
【3】强制脱离：客户端强制终止和服务端的连接，或者服务器停机；
被动脱离
阻塞因 LPUSH, RPUSH, LINSERT 等添加命令而被取消，这三个添加新元素的命令，在底层都有一个 pushGenericCommand 的函数实现(在下方源码部分增加的 TODO 标志标识关键步骤）：
void lpushCommand(redisClient *c) { pushGenericCommand(c,REDIS_HEAD); } void rpushCommand(redisClient *c) { pushGenericCommand(c,REDIS_TAIL); }
下面是 pushGenericCommand 函数的源码实现(在下方源码部分增加的 TODO 标志标识关键步骤)：
/*----------------------------------------------------------------------------- * List Commands *----------------------------------------------------------------------------*/ void pushGenericCommand(redisClient *c, int where) { int j, waiting = 0, pushed = 0; // 取出列表对象 robj *lobj = lookupKeyWrite(c->db,c->argv[1]); // 如果列表对象不存在，那么可能有客户端在等待这个键的出现 int may_have_waiting_clients = (lobj == NULL); if (lobj && lobj->type != REDIS_LIST) { addReply(c,shared.wrongtypeerr); return; } // 将列表状态设置为就绪 if (may_have_waiting_clients) signalListAsReady(c,c->argv[1]); //TODO 1: 如果有 client 可能被阻塞，则新加 readyList 到 service.ready_Keys 的字典中的相应链表中 // 遍历所有输入值，并将它们添加到列表中 for (j = 2; j < c->argc; j++) { //TODO 2: 此处把新 push 的值加入到对应 key 的列表中 // 编码值 c->argv[j] = tryObjectEncoding(c->argv[j]); // 如果列表对象不存在，那么创建一个，并关联到数据库 if (!lobj) { lobj = createZiplistObject(); dbAdd(c->db,c->argv[1],lobj); } // 将值推入到列表 listTypePush(lobj,c->argv[j],where); pushed++; } // 返回添加的节点数量 addReplyLongLong(c, waiting + (lobj ? listTypeLength(lobj) : 0)); // 如果至少有一个元素被成功推入，那么执行以下代码 if (pushed) { char *event = (where == REDIS_HEAD) ? "lpush" : "rpush"; // 发送键修改信号 signalModifiedKey(c->db,c->argv[1]); // 发送事件通知 notifyKeyspaceEvent(REDIS_NOTIFY_LIST,event,c->argv[1],c->db->id); } server.dirty += pushed; }
pushGenericCommand 函数主要做了两件事情：
【1】向 readyList 添加到服务器；
【2】将新元素 value 添加到该 key 中
到此处为止，被该 key 阻塞的客户端还没有任何一个被解除阻塞状态，为了做到这一点，Redis 的主进程在执行完 pushGenericCommand 函数后，会继续调用 handleClientsBlockedOnLists 函数，该函数的源码如下(在下方源码部分增加的 TODO 标志标识关键步骤)：
/* This function should be called by Redis every time a single command, * a MULTI/EXEC block, or a Lua script, terminated its execution after * being called by a client. * * 这个函数会在 Redis 每次执行完单个命令、事务块或 Lua 脚本之后调用。 //TODO 0: NOTICE * * All the keys with at least one client blocked that received at least * one new element via some PUSH operation are accumulated into * the server.ready_keys list. This function will run the list and will * serve clients accordingly. Note that the function will iterate again and * again as a result of serving BRPOPLPUSH we can have new blocking clients * to serve because of the PUSH side of BRPOPLPUSH. * * 对所有被阻塞在某个客户端的 key 来说，只要这个 key 被执行了某种 PUSH 操作 * 那么这个 key 就会被放到 serve.ready_keys 去。 * * 这个函数会遍历整个 serve.ready_keys 链表， * 并将里面的 key 的元素弹出给被阻塞客户端， * 从而解除客户端的阻塞状态。 * * 函数会一次又一次地进行迭代， * 因此它在执行 BRPOPLPUSH 命令的情况下也可以正常获取到正确的新被阻塞客户端。 */ void handleClientsBlockedOnLists(void) { // 遍历整个 ready_keys 链表 while(listLength(server.ready_keys) != 0) { list *l; /* Point server.ready_keys to a fresh list and save the current one * locally. This way as we run the old list we are free to call * signalListAsReady() that may push new elements in server.ready_keys * when handling clients blocked into BRPOPLPUSH. */ // 备份旧的 ready_keys ，再给服务器端赋值一个新的 l = server.ready_keys; server.ready_keys = listCreate(); while(listLength(l) != 0) { //TODO 1: 不断取出 server.ready_keys 的所有元素(可能对应多个不同的阻塞 Key) // 取出 ready_keys 中的首个链表节点 listNode *ln = listFirst(l); // 指向 readyList 结构 readyList *rl = ln->value; /* First of all remove this key from db->ready_keys so that * we can safely call signalListAsReady() against this key. */ // 从 ready_keys 中移除就绪的 key dictDelete(rl->db->ready_keys,rl->key); /* If the key exists and it's a list, serve blocked clients * with data. */ // 获取键对象，这个对象应该是非空的，并且是列表 robj *o = lookupKeyWrite(rl->db,rl->key); if (o != NULL && o->type == REDIS_LIST) { dictEntry *de; /* We serve clients in the same order they blocked for * this key, from the first blocked to the last. */ // 取出所有被这个 key 阻塞的客户端 de = dictFind(rl->db->blocking_keys,rl->key); if (de) { list *clients = dictGetVal(de); int numclients = listLength(clients); while(numclients--) { //TODO 2： 不断取出因为等待该 key 被阻塞的客户端 // 取出客户端 listNode *clientnode = listFirst(clients); redisClient *receiver = clientnode->value; // 设置弹出的目标对象（只在 BRPOPLPUSH 时使用） robj *dstkey = receiver->bpop.target; // 从列表中弹出元素 // 弹出的位置取决于是执行 BLPOP 还是 BRPOP 或者 BRPOPLPUSH int where = (receiver->lastcmd && receiver->lastcmd->proc == blpopCommand) ? REDIS_HEAD : REDIS_TAIL; robj *value = listTypePop(o,where); //TODO 3： 从该 key 已添加的元素中 pop 出第一个元素，并用于阻塞客户端的返回值 // 还有元素可弹出（非 NULL） if (value) { /* Protect receiver->bpop.target, that will be * freed by the next unblockClient() * call. */ if (dstkey) incrRefCount(dstkey); // 取消客户端的阻塞状态 unblockClient(receiver); //TODO 4: 从 service.blocking_keys 中移除对应阻塞的客户端 // 将值 value 推入到造成客户度 receiver 阻塞的 key 上 if (serveClientBlockedOnList(receiver, rl->key,dstkey,rl->db,value, where) == REDIS_ERR) { /* If we failed serving the client we need * to also undo the POP operation. */ listTypePush(o,value,where); } if (dstkey) decrRefCount(dstkey); decrRefCount(value); } else { // 如果执行到这里，表示还有至少一个客户端被键所阻塞 // 这些客户端要等待对键的下次 PUSH break; } } } // 如果列表元素已经为空，那么从数据库中将它删除 if (listTypeLength(o) == 0) dbDelete(rl->db,rl->key); /* We don't call signalModifiedKey() as it was already called * when an element was pushed on the list. */ } /* Free this item. */ decrRefCount(rl->key); zfree(rl); listDelNode(l,ln); } listRelease(l); /* We have the new list on place at this point. */ } }
handleClientsBlockedOnLists 函数主要执行如下操作：
【1】如果 service.ready_keys 不为空，那么弹出该链表的表头元素，并取出其中的 readyList 值；
【2】根据 readyList 值中保存的 key 和 db, 在 service.blocking_keys 中查找所有因为该 key 而被阻塞的客户端(以链表形式保存)；
【3】如果 Key 不为空，那么从 Key 的列表中弹出一个元素，并获取客户端链表的第一个客户端，然后将被弹出元素作为被阻塞的客户端的返回值；
【4】根据 readyList 结构的属性，删除 service.blocking_keys 中相应的客户端数据，取消客户端的阻塞状态；
【5】继续执行步骤 【3】和 【4】，知道 key 没有元素可弹出，或者因为 key 而阻塞的客户端都取消阻塞为止；
【6】继续执行步骤 【1】，直到 ready_keys 字典所有链表里的所有 readyList 结构都被处理完为止；
主动脱离
阻塞因超过最大等待时间而被取消。当客户端被阻塞时，所有造成它阻塞的键，以及阻塞的最长时限都会被记录在客户端里面，并且盖客户端的状态会被设置为”正在阻塞“。每次 Redis 服务器常规操作函数(redis.c/serverCron) 执行时，程序都会检查所有连接到服务器的客户端，查看哪些处于”正在阻塞“状态的客户端时限是否已经过期，如果是的话，就给客户端返回一个空白回复，然后撤销对客户端的阻塞。下面是相关源码：
void clientsCron(void) { /* Make sure to process at least 1/(server.hz*10) of clients per call. * * 这个函数每次执行都会处理至少 1/server.hz*10 个客户端。 * * Since this function is called server.hz times per second we are sure that * in the worst case we process all the clients in 10 seconds. * * 因为这个函数每秒钟会调用 server.hz 次， * 所以在最坏情况下，服务器需要使用 10 秒钟来遍历所有客户端。 * * In normal conditions (a reasonable number of clients) we process * all the clients in a shorter time. * * 在一般情况下，遍历所有客户端所需的时间会比实际中短很多。 */ // 客户端数量 int numclients = listLength(server.clients); // 要处理的客户端数量 int iterations = numclients / (server.hz * 10); // 至少要处理 50 个客户端 if (iterations < 50) iterations = (numclients < 50) ? numclients : 50; while (listLength(server.clients) && iterations--) { redisClient *c; listNode *head; /* Rotate the list, take the current head, process. * This way if the client must be removed from the list it's the * first element and we don't incur into O(N) computation. */ // 翻转列表，然后取出表头元素，这样一来上一个被处理的客户端会被放到表头 // 另外，如果程序要删除当前客户端，那么只要删除表头元素就可以了 listRotate(server.clients); head = listFirst(server.clients); c = listNodeValue(head); /* The following functions do different service checks on the client. * The protocol is that they return non-zero if the client was * terminated. */ // 检查客户端，并在客户端超时时关闭它 if (clientsCronHandleTimeout(c)) continue; // 根据情况，缩小客户端查询缓冲区的大小 if (clientsCronResizeQueryBuffer(c)) continue; } }
阻塞的取消策略
当程序添加一个新的被阻塞客户端到 server.blocking_keys 字典的链表中时，他将客户端放在链表的最后，而当 handleClientsBlockedOnLists 取消客户端的阻塞时候，它从链表的最前面开始取消阻塞；这个链表形成了一个 FIFO 队列，最先被阻塞的客户端总是最先脱离阻塞状态，Redis 文档称这种模式为先阻塞先服务(FBFS, first-block-first-server)。
参考内容：
[1]:The Design and Implementation of Redis 黄健宏
