《Redis 设计与实现:客户端》

Redis 服务器是典型的一对多服务器程序:一个服务器可以与多个客户端建立网络连接,每个客户端可以向服务器发送命令请求,而服务器则接收并处理客户端发送的命令请求,并向客户端返回命令回复。

通过使用由 I/O 多路复用技术实现的文件事件处理器,Redis 服务器使用单线程单进程的方式来处理命令请求,并与多个客户端进行网络通信。

对于每个与服务器进行连接的客户端,服务器都为这些客户端建立了相应的 redis.h/redisClient 结构(客户端状态),这个结构保存了客户端当前的状态信息,以及执行相关功能时需要用到的数据结构:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
/* With multiplexing we need to take per-client state.
* Clients are taken in a linked list. */
typedef struct redisClient {
uint64_t id; /* Client incremental unique ID. */
int fd;
redisDb *db;
int dictid;
robj *name; /* As set by CLIENT SETNAME */
sds querybuf;
size_t querybuf_peak; /* Recent (100ms or more) peak of querybuf size */
int argc;
robj **argv;
struct redisCommand *cmd, *lastcmd;
int reqtype;
int multibulklen; /* number of multi bulk arguments left to read */
long bulklen; /* length of bulk argument in multi bulk request */
list *reply;
unsigned long reply_bytes; /* Tot bytes of objects in reply list */
int sentlen; /* Amount of bytes already sent in the current
buffer or object being sent. */
time_t ctime; /* Client creation time */
time_t lastinteraction; /* time of the last interaction, used for timeout */
time_t obuf_soft_limit_reached_time;
int flags; /* REDIS_SLAVE | REDIS_MONITOR | REDIS_MULTI ... */
int authenticated; /* when requirepass is non-NULL */
int replstate; /* replication state if this is a slave */
int repl_put_online_on_ack; /* Install slave write handler on ACK. */
int repldbfd; /* replication DB file descriptor */
off_t repldboff; /* replication DB file offset */
off_t repldbsize; /* replication DB file size */
sds replpreamble; /* replication DB preamble. */
long long reploff; /* replication offset if this is our master */
long long repl_ack_off; /* replication ack offset, if this is a slave */
long long repl_ack_time;/* replication ack time, if this is a slave */
long long psync_initial_offset; /* FULLRESYNC reply offset other slaves
copying this slave output buffer
should use. */
char replrunid[REDIS_RUN_ID_SIZE+1]; /* master run id if this is a master */
int slave_listening_port; /* As configured with: SLAVECONF listening-port */
int slave_capa; /* Slave capabilities: SLAVE_CAPA_* bitwise OR. */
multiState mstate; /* MULTI/EXEC state */
blockingState bpop; /* blocking state */
list *watched_keys; /* Keys WATCHED for MULTI/EXEC CAS */
dict *pubsub_channels; /* channels a client is interested in (SUBSCRIBE) */
list *pubsub_patterns; /* patterns a client is interested in (SUBSCRIBE) */
sds peerid; /* Cached peer ID. */

/* Response buffer */
int bufpos;
char buf[REDIS_REPLY_CHUNK_BYTES];
} redisClient;

Redis 服务器状态结构的 clients 属性是一个链表,这个链表保存了所有与服务器连接的客户端的状态结构,对客户端执行批量操作,或者查找某个指定的客户端,都可以通过遍历 clients 链表来完成:

1
2
3
4
5
6
7
8
9
10
struct redisServer {

// ...

// 一个链表,保存了所有客户端状态
list *clients;

// ...

}

1. 客户端属性

1.1 套接字描述符

客户端状态的 fd 属性记录了客户端正在使用的套接字描述符:

1
2
3
4
5
6
7
8
9
typedef struct redisClient {

// ...

int fd;

// ...

} redisClient;

根据客户端类型的不同,fd 属性的值可以是 -1 或者是大于 -1 的整数:

  • 伪客户端(fake client)的 fd 属性的值为 -1 :伪客户端处理的命令请求来源于 AOF 文件或者 Lua 脚本,而不是网络,所以这种客户端不需要套接字连接,自然也不需要记录套接字描述符。目前 Redis 服务器会在两个地方用到伪客户端,一个用于载入 AOF 文件并还原数据库状态,而另一个则用于执行 Lua 脚本中包含的 Redis 命令。
  • 普通客户端的 fd 属性的值为大于 -1 的整数:普通客户端使用套接字来与服务器进行通讯,所以服务器会用 fd 属性来记录客户端套接字的描述符。因为合法的套接字描述符不能是 -1 ,所以普通客户端的套接字描述符的值必然是大于 -1 的整数。

执行 CLIENT_LIST 命令可以列出目前所有连接到服务器的普通客户端,命令输出中的 fd 域显示了服务器连接客户端所使用的套接字描述符:

1
2
3
4
redis> CLIENT list

addr=127.0.0.1:53428 fd=6 name= age=1242 idle=0 ...
addr=127.0.0.1:53469 fd=7 name= age=4 idle=4 ...

1.2 名字

在默认情况下,一个连接到服务器的客户端是没有名字的。使用 CLIENT_SETNAME 命令可以为客户端设置一个名字,让客户端的身份变得更清晰。

客户端的名字记录在客户端状态的 name 属性里面:

1
2
3
4
5
6
7
8
9
typedef struct redisClient {

// ...

robj *name;

// ...

} redisClient;

如果客户端没有为自己设置名字,那么相应客户端状态的 name 属性指向 NULL 指针;相反地,如果客户端为自己设置了名字,那么 name 属性将指向一个字符串对象,而该对象就保存着客户端的名字。

1.3 标志

客户端的标志属性 flags 记录了客户端的角色(role),以及客户端目前所处的状态:

1
2
3
4
5
6
7
8
9
typedef struct redisClient {

// ...

int flags;

// ...

} redisClient;

flags 属性的值可以是单个标志:

1
flags = <flag>

也可以是多个标志的二进制或,比如:

1
flags = <flag1> | <flag2> | ...

每个标志使用一个常量表示,一部分标志记录了客户端的角色:

  • 在主从服务器进行复制操作时,主服务器会成为从服务器的客户端,而从服务器也会成为主服务器的客户端。REDIS_MASTER 标志表示客户端代表的是一个主服务器,REDIS_SLAVE 标志表示客户端代表的是一个从服务器。
  • REDIS_PRE_PSYNC 标志表示客户端代表的是一个版本低于 Redis 2.8 的从服务器,主服务器不能使用 PSYNC 命令与这个从服务器进行同步。这个标志只能在 REDIS_SLAVE 标志处于打开状态时使用。
  • REDIS_LUA_CLIENT 标识表示客户端是专门用于处理 Lua 脚本里面包含的 Redis 命令的伪客户端。

而另外一部分标志则记录了客户端目前所处的状态:

  • REDIS_MONITOR 标志表示客户端正在执行 MONITOR 命令。
  • REDIS_UNIX_SOCKET 标志表示服务器使用 UNIX 套接字来连接客户端。
  • REDIS_BLOCKED 标志表示客户端正在被 BRPOPBLPOP 等命令阻塞。
  • REDIS_UNBLOCKED 标志表示客户端已经从 REDIS_BLOCKED 标志所表示的阻塞状态中脱离出来, 不再阻塞。 REDIS_UNBLOCKED 标志只能在 REDIS_BLOCKED 标志已经打开的情况下使用。
  • REDIS_MULTI 标志表示客户端正在执行事务。
  • REDIS_DIRTY_CAS 标志表示事务使用 WATCH 命令监视的数据库键已经被修改, REDIS_DIRTY_EXEC 标志表示事务在命令入队时出现了错误,以上两个标志都表示事务的安全性已经被破坏,只要这两个标记中的任意一个被打开,EXEC 命令必然会执行失败。这两个标志只能在客户端打开了 REDIS_MULTI 标志的情况下使用。
  • REDIS_CLOSE_ASAP 标志表示客户端的输出缓冲区大小超出了服务器允许的范围,服务器会在下一次执行 serverCron 函数时关闭这个客户端,以免服务器的稳定性受到这个客户端影响。积存在输出缓冲区中的所有内容会直接被释放,不会返回给客户端。
  • REDIS_CLOSE_AFTER_REPLY 标志表示有用户对这个客户端执行了 CLIENT_KILL 命令,或者客户端发送给服务器的命令请求中包含了错误的协议内容。服务器会将客户端积存在输出缓冲区中的所有内容发送给客户端,然后关闭客户端。
  • REDIS_ASKING 标志表示客户端向集群节点(运行在集群模式下的服务器)发送了 ASKING 命令。
  • REDIS_FORCE_AOF 标志强制服务器将当前执行的命令写入到 AOF 文件里面,REDIS_FORCE_REPL 标志强制主服务器将当前执行的命令复制给所有从服务器。执行 PUBSUB 命令会使客户端打开 REDIS_FORCE_AOF 标志,执行 SCRIPT_LOAD 命令会使客户端打开 REDIS_FORCE_AOF 标志和 REDIS_FORCE_REPL 标志。
  • 在主从服务器进行命令传播期间,从服务器需要向主服务器发送 REPLICATION ACK 命令,在发送这个命令之前,从服务器必须打开主服务器对应的客户端的 REDIS_MASTER_FORCE_REPLY 标志,否则发送操作会被拒绝执行。

以上提到的所有标志都定义在 redis.h 文件里面。

通常情况下,Redis 只会将那些对数据库进行了修改的命令写入到 AOF 文件,并复制到各个从服务器:如果一个命令没有对数据库进行任何修改,那么它就会被认为是只读命令,这个命令不会被写入到 AOF 文件,也不会被复制到从服务器。

以上规则适用于绝大部分 Redis 命令,但 PUBSUB 命令和 SCRIPT_LOAD 命令是其中的例外。

PUBSUB 命令虽然没有修改数据库,但 PUBSUB 命令向频道的所有订阅者发送消息这一行为带有副作用,接收到消息的所有客户端的状态都会因为这个命令而改变。因此,服务器需要使用 REDIS_FORCE_AOF 标志,强制将这个命令写入 AOF 文件,这样在将来载入 AOF 文件时,服务器就可以再次执行相同的 PUBSUB 命令,并产生相同的副作用。

SCRIPT_LOAD 命令的情况与 PUBSUB 命令类似:虽然 SCRIPT_LOAD 命令没有修改数据库,但它修改了服务器状态,所以它是一个带有副作用的命令,服务器需要使用 REDIS_FORCE_AOF 标志,强制将这个命令写入 AOF 文件,使得将来在载入 AOF 文件时,服务器可以产生相同的副作用。

另外,为了让主服务器和从服务器都可以正确地载入 SCRIPT_LOAD 命令指定的脚本,服务器需要使用 REDIS_FORCE_REPL 标志,强制将 SCRIPT_LOAD 命令复制给所有从服务器。

1.4 输入缓冲区

客户端状态的输入缓冲区用于保存客户端发送的命令请求:

1
2
3
4
5
6
7
8
9
typedef struct redisClient {

// ...

sds querybuf;

// ...

} redisClient;

输入缓冲区的大小会根据输入内容动态地缩小或者扩大,但它的最大大小不能超过 1 GB ,否则服务器将关闭这个客户端。

1.5 命令与命令参数

在服务器将客户端发送的命令请求保存到客户端状态的 querybuf 属性之后, 服务器将对命令请求的内容进行分析,并将得出的命令参数以及命令参数的个数分别保存到客户端状态的 argv 属性和 argc 属性:

1
2
3
4
5
6
7
8
9
10
11
typedef struct redisClient {

// ...

robj **argv;

int argc;

// ...

} redisClient;

argv 属性是一个数组,数组中的每个项都是一个字符串对象:其中 argv[0] 是要执行的命令,而之后的其他项则是传给命令的参数。

argc 属性则负责记录 argv 数组的长度。

1.6 命令的实现函数

当服务器从协议内容中分析并得出 argv 属性和 argc 属性的值之后,服务器将根据项 argv[0] 的值, 在命令表中查找命令所对应的命令实现函数。

命令表是一个字典,字典的键是一个 SDS 结构,保存了命令的名字,字典的值是命令所对应的 redisCommand 结构,这个结构保存了命令的实现函数、命令的标志、命令应该给定的参数个数、命令的总执行次数和总消耗时长等统计信息。

当程序在命令表中成功找到 argv[0] 所对应的 redisCommand 结构时,它会将客户端状态的 cmd 指针指向这个结构:

1
2
3
4
5
6
7
8
9
typedef struct redisClient {

// ...

struct redisCommand *cmd;

// ...

} redisClient;

之后,服务器就可以使用 cmd 属性所指向的 redisCommand 结构,以及 argvargc 属性中保存的命令参数信息,调用命令实现函数,执行客户端指定的命令。

针对命令表的查找操作不区分输入字母的大小写。

1.7 输出缓冲区

执行命令所得的命令回复会被保存在客户端状态的输出缓冲区里面,每个客户端都有两个输出缓冲区可用,一个缓冲区的大小是固定的,另一个缓冲区的大小是可变的:

  • 固定大小的缓冲区用于保存那些长度比较小的回复,比如 OK 、简短的字符串值、整数值、错误回复,等等。
  • 可变大小的缓冲区用于保存那些长度比较大的回复,比如一个非常长的字符串值,一个由很多项组成的列表,一个包含了很多元素的集合,等等。

客户端的固定大小缓冲区由 bufbufpos 两个属性组成:

1
2
3
4
5
6
7
8
9
10
11
typedef struct redisClient {

// ...

char buf[REDIS_REPLY_CHUNK_BYTES];

int bufpos;

// ...

} redisClient;

buf 是一个大小为 REDIS_REPLY_CHUNK_BYTES 字节的字节数组,而 bufpos 属性则记录了 buf 数组目前已使用的字节数量。

REDIS_REPLY_CHUNK_BYTES 常量目前的默认值为 16*1024 ,也即是说,buf 数组的默认大小为 16 KB 。

buf 数组的空间已经用完,或者回复因为太大而没办法放进 buf 数组里面时,服务器就会开始使用可变大小缓冲区。

可变大小缓冲区由 reply 链表和一个或多个字符串对象组成:

1
2
3
4
5
6
7
8
9
typedef struct redisClient {

// ...

list *reply;

// ...

} redisClient;

通过使用链表来连接多个字符串对象,服务器可以为客户端保存一个非常长的命令回复,而不必受到固定大小缓冲区 16 KB 大小的限制。

1.8 身份验证

客户端状态的 authenticated 属性用于记录客户端是否通过了身份验证:

1
2
3
4
5
6
7
8
9
typedef struct redisClient {

// ...

int authenticated;

// ...

} redisClient;

如果 authenticated 的值为 0 ,那么表示客户端未通过身份验证;如果 authenticated 的值为 1, 那么表示客户端已经通过了身份验证。

当客户端 authenticated 属性的值为 0 时,除了 AUTH 命令之外,客户端发送的所有其他命令都会被服务器拒绝执行:

1
2
3
4
5
redis> PING
(error) NOAUTH Authentication required.

redis> SET msg "hello world"
(error) NOAUTH Authentication required.

当客户端通过 AUTH 命令成功进行身份验证之后, 客户端状态 authenticated 属性的值就会从 0 变为 1,这时客户端就可以像往常一样向服务器发送命令请求了。

authenticated 属性仅在服务器启用了身份验证功能时使用:如果服务器没有启用身份验证功能的话, 那么即使 authenticated 属性的值为 0 (这是默认值),服务器也不会拒绝执行客户端发送的命令请求。

1.9 时间

最后,客户端还有几个和时间有关的属性:

1
2
3
4
5
6
7
8
9
10
11
12
13
typedef struct redisClient {

// ...

time_t ctime;

time_t lastinteraction;

time_t obuf_soft_limit_reached_time;

// ...

} redisClient;

ctime 属性记录了创建客户端的时间,这个时间可以用来计算客户端与服务器已经连接了多少秒—— CLIENT_LIST 命令的 age 域记录了这个秒数:

1
2
3
redis> CLIENT list

addr=127.0.0.1:53428 ... age=1242 ...

lastinteraction 属性记录了客户端与服务器最后一次进行互动(interaction)的时间,这里的互动可以是客户端向服务器发送命令请求,也可以是服务器向客户端发送命令回复。

lastinteraction 属性可以用来计算客户端的空转(idle)时间,也即是,距离客户端与服务器最后一次进行互动以来,已经过去了多少秒—— CLIENT_LIST 命令的 idle 域记录了这个秒数:

1
2
3
redis> CLIENT list

addr=127.0.0.1:53428 ... idle=12 ...

obuf_soft_limit_reached_time 属性记录了输出缓冲区第一次到达软性限制(soft limit)的时间。

2. 客户端的创建与关闭

2.1 创建普通客户端

如果客户端是通过网络连接与服务器进行连接的普通客户端,那么在客户端使用 connect 函数连接到服务器时,服务器就会调用连接事件处理器,为客户端创建相应的客户端状态,并将这个新的客户端状态添加到服务器状态结构的 clients 链表的末尾。

2.2 关闭普通客户端

一个普通客户端可以因为多种原因而被关闭:

  • 如果客户端进程退出或者被杀死,那么客户端与服务器之间的网络连接将被关闭,从而造成客户端被关闭。
  • 如果客户端向服务器发送了带有不符合协议格式的命令请求,那么这个客户端也会被服务器关闭。
  • 如果客户端成为了 CLIENTKILL 命令的目标,那么它也会被关闭。
  • 如果用户为服务器设置了 timeout 配置选项,那么当客户端的空转时间超过 timeout 选项设置的值时,客户端将被关闭。不过 timeout 选项有一些例外情况:如果客户端是主服务器(打开了 REDIS_MASTER标志),从服务器(打开了 REDIS_SLAVE标志),正在被 BLPOP 等命令阻塞(打开了 REDIS_BLOCKED 标志),或者正在执行 SUBSCRIBEPSUBSCRIBE 等订阅命令,那么即使客户端的空转时间超过了 timeout 选项的值,客户端也不会被服务器关闭。
  • 如果客户端发送的命令请求的大小超过了输入缓冲区的限制大小(默认为 1 GB),那么这个客户端会被服务器关闭。
  • 如果要发送给客户端的命令回复的大小超过了输出缓冲区的限制大小,那么这个客户端会被服务器关闭。

为了避免客户端的回复过大,占用过多的服务器资源,服务器会时刻检查客户端的输出缓存区的大小,并在缓存区的大小超出范围时,执行相应的限制操作。

服务器使用两种模式来限制客户端的输出缓冲区的大小:

  • 硬性限制(hard limit):如果输出缓冲区的大小超过了硬性限制所设置的大小,那么服务器立即关闭客户端。
  • 软性限制(soft limit):如果输出缓冲区的大小超过了软性限制所设置的大小,但还没超过硬性限制,那么服务器将使用客户端状态结构的 obuf_soft_limit_reached_time 属性记录下客户端到达软性限制的起始时间;之后服务器会继续监视客户端,如果输出缓冲区的大小一直超出软性限制,并且持续时间超过服务器设定的时长,那么服务器将关闭客户端;相反地,如果输出缓冲区的大小在指定时间之内,不再超出软性限制,那么客户端就不会被关闭,并且 obuf_soft_limit_reached_time 属性的值也会被清零。

使用 client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>,可以为普通客户端、从服务器客户端、发布/订阅客户端分别设置不同的软性限制和硬性限制。

2.3 Lua 脚本的伪客户端

服务器会在初始化时创建负责执行 Lua 脚本中包含的 Redis 命令的伪客户端,并将这个伪客户端关联在服务器状态结构的 lua_client 属性中:

1
2
3
4
5
6
7
8
9
struct redisServer {

// ...

redisClient *lua_client;

// ...

}

lua_client 伪客户端在服务器运行的整个生命期中会一直存在,只有服务器被关闭时,这个客户端才会被关闭。

2.4 AOF 文件的伪客户端

服务器在载入 AOF 文件时,会创建用于执行 AOF 文件包含的 Redis 命令的伪客户端,并在载入完成之后,关闭这个伪客户端。