【Redis-04】Redis命令在客户端与服务器之间的执行流程

本文详细阐述了Redis服务器的初始化过程、客户端的创建与状态管理,以及命令从客户端发送到服务器的接收、解析、执行和返回机制,展示了两者之间的交互过程。
摘要由CSDN通过智能技术生成

 Redis本质上是一个数据结构服务器,支持键值对类型存储的内存管理系统,可以用作数据库、缓存和消息中间件,在我日常的开发中,基本上使用redis作为缓存中间件。

 在Redis中有两个重要的角色,一个是服务器server,一个是客户端client,他们是一对多的关系,服务器会保存每个与之相连接的客户端的状态信息。本文会从这两个角色,分析客户端和服务器中一些比较重要的属性结构,以及一个命令从客户端发送到服务器接受、处理并返回的实现原理。

1.Server服务器

 Redis服务器启动后,需要经过一些列的初始化及配置的设置,之后就可以接收客户端的命令请求,进行相关操作了,那么服务器初始化的整个过程,主要包含以下几步

  1. 初始化服务器的状态参数:这里主要是创建redisServer这个结构体的实例变量server,并为server中的属性赋值,以存储服务器的状态,但是这里设置的都是一些简单的整数或者字符串等等,比如服务器的运行id,端口号,持久化的触发条件等等,较为复杂的结构不会在这里设置,这一步通过 initServerConfig函数处理。
  2. 载入用户配置项:这一步会载入用户通过命令参数或者配置文件设置的服务器状态信息,对server变量中的相关属性进行修改。
  3. 初始化服务器数据结构:这一步会执行除第一步之外相对复杂的数据结构,如server.clients链表、db数组、server.lua客户端等等,之所以与第一步分开,是因为这一步的结构体的创建可能与第二步用户配置的参数有关,这一步会通过initServer函数处理。经过此步之后,会执行两个重要的步骤,一是服务端创建监听套接字,并关联应答事件处理器,等待客户端的连接;二是开始执行serverCron这个时间事件函数。
  4. 还原数据库状态:载入AOF或者RDB持久化的目标文件,如果AOF持久化开启,服务器使用AOF文件还原数据库的状态,否则使用RDB的持久化文件还原。
  5. 执行事件循环:这里是开始执行主函数中的文件事件和时间事件函数。redis主函数一旦开始执行后,会找要最近一次需要执行的时间事件,计算当前时间与这个时间事件的时差,在这个时间段内会阻塞等待文件事件,并关联事件处理器去处理,由于命令函数处理时间长短无法确定,所以时间事件的实际处理时间,通常会比它本身设定的执行时间会稍微晚一些。
    在这里插入图片描述

2.Client客户端

2.1 客户端创建

 客户端首次创建,连接到服务器之后,会向服务器发送命令,并得到相应的结果和回复。在redis中,客户端可以分为三种类型:一种是负责执行Lua脚本的伪客户端,一种是用来加载aof文件的伪客户端,还有一种就是通过网络连接的普通客户端。

 对于通过网络与redis服务器连接的普通客户端和lua脚本的客户端,服务器都会创建相对应的client 结构,用于记录他们的状态信息,我们先看下客户端在redisServer结构中是如何保存的:

struct redisServer {
    ...
    // 存放普通客户端的列表
    list *clients;			/* List of active clients */
    // 存放lua脚本客户端
    client *lua_client;   	/* The "fake client" to query Redis from Lua */
    ...
};

 看这段源码,redisServer是表示redis服务器的结构,在这其中clients是一个链表,链表中每个节点代表与之连接的客户端client,新增加的客户端会添加到列表的末尾。而lua_client指针指向了代表lua脚本的伪客户端(fake client: 伪造的客户端)。
在这里插入图片描述

2.2 客户端状态

 通过以上,我们了解到clients链表中每个节点都代表一个客户端client,那么在redis中,client会保存客户端(这里指的是普通的网络客户端)的哪些状态信息呢,看如下源码:

typedef struct client {
    ...
    // fd是每个客户端连接的标识
    int fd;                 /* Client socket. */
    // 这个记录的是客户端的名称,默认没有名称
    robj *name;             /* As set by CLIENT SETNAME. */
    // 记录了客户端的角色和相关状态
    int flags;              /* Client flags: CLIENT_* macros. */
    // 客户端状态的输入缓冲区,保存客户端的命令请求
    sds querybuf;           /* Buffer we use to accumulate client queries. */
    // 下面这两个是解析出来的命令和参数
    int argc;               /* Num of arguments of current command. */
    robj **argv;            /* Arguments of current command. */
    // 一个是根据argv[0]解析出来的命令,一个是最后一次执行的命令
    struct redisCommand *cmd, *lastcmd;  /* Last command executed. */
    // 下面两个是输出缓冲区(固定缓冲区大小)
    int bufpos;
    char buf[PROTO_REPLY_CHUNK_BYTES];
    // 下面这个是可变缓冲区,链表,节点是字符串对象
    list *reply;            /* List of reply objects to send to the client */
    // 身份验证标识
    int authenticated;      /* When requirepass is non-NULL. */
    ...
} client;

 客户端状态包含但不限于以下信息:

  • fd 属性表示客户端套接字描述符,取值:-1表示伪客户端(Lua客户端),普通客户端的值≥0;
  • name 指针指向sds的字符串对象,表示客户端名称,默认客户端是没有名称的,可以使用client setname命令设置;
  • flags 属性用于表示客户端角色及目前的状态,角色信息如主服务器或者从服务器,或者伪客户端,状态信息比如当前客户端正处于阻塞状态、执行事务的状态、aof强制写入的状态等。
  • querybuf 属性是输入缓冲区,用于保存客户端发送的命令,是一个sds的对象结构,用redis命令协议的方式保存,大小不能超过1GB;
  • argv+argc 两个属性,用于对客户端命令进行解析后保存,argv属性是一个数组,每一项都是字符串对象,保存命令及命令的参数,argv[0]始终保存要执行的命令,argc属性记录了argv数组的长度。
  • cmd 指针是解析argv[0]得到的命令实现函数,通过查询redis命令表获得的,使用redisCommand结构保存。
  • buf和reply 表示输出缓冲区,输出缓冲区包含固定大小和可变大小的缓冲区,buf是固定的,reply是可变的。简短的内容回复一般保存在buf中,而较长的字符串或者链表等结构保存在reply中。
  • authenticated 表示身份验证标识,0是未通过,1表示通过,只有服务器开启了身份认证功能时才会使用。
  • 和时间有关的属性:
    • ctime 这个记录了客户端创建的时间戳
    • lastinteraction 这个记录了客户端和服务器最后一次交互的时间(互相发送命令),用来记录客户端的空转时长。

 以上部分信息可以通过命令client list查询,获取的就是当前服务端所有正在连接的客户端信息。

2.3 客户端断开

  • 用来加载aof文件的伪客户端,redis服务器启动之初创建,在完成aof文件的载入后关闭;
  • 负责执行Lua脚本的伪客户端,在redis服务器启动后整个生命周期都是存在的,直到服务器停止运行;
  • 通过网络连接的普通客户端,服务器会给此类客户端创建文件事件的处理器,并保存每个客户端的状态。客户端在遇到几种情况后会关闭,比如网络断开、发送了不合格协议的命令请求,空转时间超时,输入/输出缓冲区超出限制等等,生命周期也随之结束。

 以上就是客户端整个生命周期的状态描述,下面我们来看一下,一个命令从客户端发送,到服务器执行后返回,整个过程都执行了哪些操作。

3 命令执行过程

 一个命令从发送到处理并回复的过程,客户端和服务器都执行了很多操作。简单来看,就是客户端发送命令,如get key;服务器接收命令,并转化成相关函数操作,得到结果,然后发送给客户端;客户端接收数据并呈现给用户。在这一个流程中,具体包含哪些细节呢?

  1. 用户在客户端输入命令,客户端对命令进行协议转换,并发送给服务器;
  2. 服务器通过监听套接字,获取命令协议内容,存储到当前客户端的输入缓冲区。
  3. 对命令解析,分别存放到argv属性(命令+参数)和argc(argv数组长度)中。
  4. 根据argv[0]在命令表中查找对应的实现命令,并存放到当前客户端的cmd属性中。
  5. 执行命令前的状态检查,包含cmd指针是否有实现、客户端是否进行了身份验证,是否进行最大内存校验等等,确保命令执行的安全和可行性。
  6. 调用cmd指向的命令实现函数,执行操作,获得回复数据后存储到当前客户端的输出缓冲区里面。
  7. 关联客户端套接字的命令回复处理器,将数据返回,并清空客户端输出缓冲区。
  8. 客户端接收到协议格式的命令回复后,对结果进行转换,并打印成用户可读的形式。

4 图示

 综上,使用流程图来表示以上客户端与服务器的加载过程,以及命令的实现流程,如下图:
在这里插入图片描述

  • 24
    点赞
  • 19
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值