Redis（二）：命令集构建及关键属性源码解析

上一篇文章，我们从框架层面，主要介绍了redis的启动过程，以及主要的命令处理流程逻辑。这些更多的都是些差不多的道理，而要细了解redis，则需要更细节的东西。

今天我们稍微内围的角度，来看看几个命令执行的重要方法，深入理解下redis的魅力所在。

首先，我们通过上一章知道，processCommand 是其业务主要入口,我们再来回顾下:

零、redis中的几个关键数据结构

1. redisServer

redisServer 是redis中最大的全局变量，负责保存客户端，配置信息，db 等等各种重要信息。各函数之间通信，也是隐藏的使用 redisServer 进行通信。它的定义是在 server.h 中，而 实例化则是在 server.c 中。

2. redisObject

java有万事万物皆对象的说法，而redis中也可以用 一切皆 redisObject 来描述，可以说是最通用的redis数据结构。

3. redisDb

redisDb 是redis作为数据库的主要存储模型，承载了所有的业务数据存储。单从这点来说，要实现一个数据库貌似很简单，但实际却是很难。

4. client

每一个客户端连接，就是一个 client 实例，其中包含许多全局引用信息。比如解析完客户端请求之后，会把参数，数据库指针都放到 client 中。

一、命令查找 dict

当一个请求发到redis服务器后，我们将其数据解析出来，自然先要明白命令是哪个，然后才知道如何处理它。我们看一下，redis是如何查找具体的处理命令的？

综上，可以看出一个 命令的查找过程，其实就是一个hash字典的查找过程。做的比较特别的优化是，进行rehash时，只做部分rehash,将停顿时间最大可能减小。使用 两个hash表进行互相替换，来保证数据的完整性。

hash表是个很有用的数据结构，上面是对对于命令的查找使用，但是对于后面的 kv 的查找，同样可以使用 dict 这种结构，所以后续对其他命令的解析时，只需注意其特有的处理方式即可。

二、溯源: 命令的添加

要想实现如上的查找，我们有必要了解下其是在何时添加的。下面，我们来看看，这些命令是如何写入到 server.commands 中的。

以上，自然就是一个 hash 表插入数据过程，然后 server.commands 就有数据了，请求进来自然就可以处理了。

三、命令集的定义

在server.c的头部，就有一个数组，专门用于定义各个命令的处理方法，并最终被初始化到 server.commands 中。

可以说，核心功能都是在这里定义的哟（小手册），如果想自己添加功能，也是从这里开始，然后去实现它。其中，lua的调用则直接使用 eval进行即可。

四、执行命令的模板方法

调用真正命令之前，之后，会各种判断，才可以进行命令的调用。这也是数据库的与简单函数调用的差别之一。

四、响应客户端

响应客户端可以使用addReply(), 当然还有其他简化版本, 道理一致。

将数据写入到 c->buf 后，又是谁向客户端写出了结果呢？

要么是有一个后台线程一直写，要么是在下一次循环的时候再主动写，你觉得呢？( 请参考: server.clients_pending_write )