Redis 实战之客户端属性

客户端属性

  • 套接字描述符
  • 名字
  • 标志
  • 输入缓冲区
  • 命令与命令参数
  • 命令的实现函数
  • 输出缓冲区
  • 身份验证
  • 时间
  • 总结

客户端状态包含的属性可以分为两类:

一类是比较通用的属性, 这些属性很少与特定功能相关, 无论客户端执行的是什么工作, 它们都要用到这些属性。
另外一类是和特定功能相关的属性, 比如操作数据库时需要用到的 db 属性和 dictid 属性, 执行事务时需要用到的 mstate 属性, 以及执行 WATCH 命令时需要用到的 watched_keys 属性, 等等。

套接字描述符

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

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 域显示了服务器连接客户端所使用的套接字描述符:

redis> CLIENT listaddr=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 ...

名字

在默认情况下, 一个连接到服务器的客户端是没有名字的。

比如在下面展示的 CLIENT_LIST 命令示例中, 两个客户端的 name 域都是空白的:

redis> CLIENT listaddr=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 ...

使用CLIENT_SETNAME 命令可以为客户端设置一个名字, 让客户端的身份变得更清晰。

以下展示的是客户端执行 CLIENT_SETNAME 命令之后的客户端列表:

redis> CLIENT listaddr=127.0.0.1:53428 fd=6 name=message_queue age=2093 idle=0 ...
addr=127.0.0.1:53469 fd=7 name=user_relationship age=855 idle=2 ...

其中,第一个客户端的名字是 message_queue , 我们可以猜测它是负责处理消息队列的客户端; 第二个客户端的名字是 user_relationship , 我们可以猜测它为负责处理用户关系的客户端。

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

typedef struct redisClient {// ...robj *name;// ...} redisClient;

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

标志

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

typedef struct redisClient {// ...int flags;// ...} redisClient;

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

flags = <flag>

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

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 文件里面。

PUBSUB 命令和 SCRIPT LOAD 命令的特殊性

通常情况下, 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 命令复制给所有从服务器。

以下是一些 flags 属性的例子:

# 客户端是一个主服务器
REDIS_MASTER# 客户端正在被列表命令阻塞
REDIS_BLOCKED# 客户端正在执行事务,但事务的安全性已被破坏
REDIS_MULTI | REDIS_DIRTY_CAS# 客户端是一个从服务器,并且版本低于 Redis 2.8
REDIS_SLAVE | REDIS_PRE_PSYNC# 这是专门用于执行 Lua 脚本包含的 Redis 命令的伪客户端
# 它强制服务器将当前执行的命令写入 AOF 文件,并复制给从服务器
REDIS_LUA_CLIENT | REDIS_FORCE_AOF | REDIS_FORCE_REPL

输入缓冲区

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

typedef struct redisClient {// ...sds querybuf;// ...} redisClient;

举个例子, 如果客户端向服务器发送了以下命令请求:

SET key value

那么客户端状态的 querybuf 属性将是一个包含以下内容的 SDS 值:

*3\r\n$3\r\nSET\r\n$3\r\nkey\r\n$5\r\nvalue\r\n

图13-4 展示了这个 SDS 值以及 querybuf 属性的样子:
在这里插入图片描述
输入缓冲区的大小会根据输入内容动态地缩小或者扩大, 但它的最大大小不能超过 1 GB , 否则服务器将关闭这个客户端。

命令与命令参数

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

typedef struct redisClient {// ...robj **argv;int argc;// ...} redisClient;

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

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

命令的实现函数

当服务器从协议内容中分析并得出 argv 属性和 argc 属性的值之后, 服务器将根据项 argv[0] 的值, 在命令表中查找命令所对应的命令实现函数。
当程序在命令表中成功找到 argv[0] 所对应的 redisCommand 结构时, 它会将客户端状态的 cmd 指针指向这个结构:

typedef struct redisClient {// ...struct redisCommand *cmd;// ...} redisClient;

之后,服务器就可以使用 cmd 属性所指向的 redisCommand 结构, 以及 argv 、 argc 属性中保存的命令参数信息, 调用命令实现函数, 执行客户端指定的命令。
针对命令表的查找操作不区分输入字母的大小写, 所以无论 argv[0] 是 “SET” 、 “set” 、或者 "SeT , 等等, 查找的结果都是相同的。

输出缓冲区

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

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

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

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 链表和一个或多个字符串对象组成:

typedef struct redisClient {// ...list *reply;// ...} redisClient;

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

身份验证

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

typedef struct redisClient {// ...int authenticated;// ...} redisClient;

如果authenticated 的值为 0 , 那么表示客户端未通过身份验证; 如果 authenticated 的值为 1 , 那么表示客户端已经通过了身份验证。
当客户端 authenticated 属性的值为 0 时, 除了 AUTH 命令之外, 客户端发送的所有其他命令都会被服务器拒绝执行:

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

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

# authenticated 属性的值从 0 变为 1
redis> AUTH 123321
OKredis> PING
PONGredis> SET msg "hello world"
OK

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

关于服务器身份验证的更多信息可以参考示例配置文件对 requirepass 选项的相关说明。

时间

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

typedef struct redisClient {// ...time_t ctime;time_t lastinteraction;time_t obuf_soft_limit_reached_time;// ...} redisClient;

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

redis> CLIENT listaddr=127.0.0.1:53428 ... age=1242 ...

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

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

redis> CLIENT listaddr=127.0.0.1:53428 ... idle=12 ...

obuf_soft_limit_reached_time 属性记录了输出缓冲区第一次到达软性限制(soft limit)的时间, 稍后介绍输出缓冲区大小限制的时候会详细说明这个属性的作用。

总结

服务器状态结构使用 clients 链表连接起多个客户端状态, 新添加的客户端状态会被放到链表的末尾。
客户端状态的 flags 属性使用不同标志来表示客户端的角色, 以及客户端当前所处的状态。
输入缓冲区记录了客户端发送的命令请求, 这个缓冲区的大小不能超过 1 GB 。
命令的参数和参数个数会被记录在客户端状态的 argv 和 argc 属性里面, 而 cmd 属性则记录了客户端要执行命令的实现函数。
客户端有固定大小缓冲区和可变大小缓冲区两种缓冲区可用, 其中固定大小缓冲区的最大大小为 16 KB , 而可变大小缓冲区的最大大小不能超过服务器设置的硬性限制值。
输出缓冲区限制值有两种, 如果输出缓冲区的大小超过了服务器设置的硬性限制, 那么客户端会被立即关闭; 除此之外, 如果客户端在一定时间内, 一直超过服务器设置的软性限制, 那么客户端也会被关闭。
当一个客户端通过网络连接连上服务器时, 服务器会为这个客户端创建相应的客户端状态。 网络连接关闭、 发送了不合协议格式的命令请求、 成为 CLIENT_KILL 命令的目标、 空转时间超时、 输出缓冲区的大小超出限制, 以上这些原因都会造成客户端被关闭。
处理 Lua 脚本的伪客户端在服务器初始化时创建, 这个客户端会一直存在, 直到服务器关闭。
载入 AOF 文件时使用的伪客户端在载入工作开始时动态创建, 载入工作完毕之后关闭。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.hqwc.cn/news/669509.html

如若内容造成侵权/违法违规/事实不符,请联系编程知识网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

PSFR-GAN复现

写在前面&#xff1a;本博客仅作记录学习之用&#xff0c;部分图片来自网络&#xff0c;如需引用请注明出处&#xff0c;同时如有侵犯您的权益&#xff0c;请联系删除&#xff01; 文章目录 前言快速开始安装依赖权重下载及复原 训练网络数据集训练脚本 代码详解训练BaseOptio…

Windows平台通过MobaXterm远程登录安装在VMware上的Linux系统(CentOS)

MobaXterm是一个功能强大的远程计算工具&#xff0c;它提供了一个综合的远程终端和图形化的X11服务器。MobaXterm旨在简化远程计算任务&#xff0c;提供了许多有用的功能&#xff0c;使远程访问和管理远程服务器变得更加方便&#xff0c;它提供了一个强大的终端模拟器&#xff…

Python深度学习基于Tensorflow(1)Numpy基础

numpy的重要性不言而喻&#xff0c;一般不涉及到GPU/TPU计算&#xff0c;都是用numpy&#xff0c;常见的np就是这个玩意。其特点就是快&#xff01;其实如果不涉及到深度学习&#xff0c;还有一个库是很重要的&#xff0c;scipy&#xff0c;集成了很多的东西。 安装和导入如下…

【考研数学】只做《1800》和真题,能不能考90分?

网上的经验贴推荐的习题册&#xff0c;说自己刷完以后最后考了130 你以为自己也能和大佬一样&#xff0c;刷完数学也能考那么高 但实际上很多人是1800、660、880刷题刷下来最后考了四五十的 他们也不会在网上说 刷题多少&#xff0c;或者是刷哪一本习题册并不能衡量你最后能…

你真的知道Show Master Status吗?

欢迎来到我的博客&#xff0c;代码的世界里&#xff0c;每一行都是一个故事 你真的知道Show Master Status吗&#xff1f; 前言输出字段展示file详解Position详解Binlog_Do_DBBinlog_Ignore_DBExecuted_Gtid_Set 前言 在数据库的世界里&#xff0c;每一个字段都像是一个谜团&a…

【NI国产替代】USB-4432 102.4 kS/s , 100 dB , 0.8 Hz AC/DC耦合,5输入声音与振动设备

102.4 kS/s , 100 dB , 0.8 Hz AC/DC耦合&#xff0c;5输入声音与振动设备 USB-4432专为声音和振动应用而设计。输入通道集成了用于加速度计和麦克风的集成电子压电(IEPE)信号调理功能&#xff0c;并具有内置的抗混叠滤波器&#xff0c;可自动调整至采样率。第五个输入通道不提…

强烈推荐gradle统一版本管理新方式version catalogs

https://developer.android.google.cn/build/migrate-to-catalogs?hlzh-cn#groovy 以前都是通过自定义config.gradle, 然后apply它&#xff0c;有一个弊端就是无法提示新版本可以升级。比如这个&#xff1a; 在gradle7.0 preview了新功能&#xff0c;现在默认稳定了。 尝试…

论文笔记:DeepMove: Predicting Human Mobility with Attentional Recurrent Networks

WWW 2018 1 Intro 根据对百万级用户群的研究&#xff0c;93%的人类移动是可预测的。 早期的mobility预测方法大多基于模式的。 首先从轨迹中发现预定义的移动模式(顺序模式、周期模式)然后基于这些提取的模式预测未来位置。最近的发展转向基于模型的方法进行流动性预测。 利用…

C语言结构体类型

C语言结构体类型 个人主页&#xff1a;大白的编程日记 个人主页&#xff1a;C语言学习之路 文章目录 C语言结构体类型前言一.结构体1.1结构体类型的声明1.2结构体变量的创建和初始化1.3结构成员访问操作符1.4结构的特殊声明1.5 结构的自引用 二.结构体内存对齐2.1对齐规则2.2内…

UDP 的报文结构

一.UDP的报文结构 1.UDP的简单介绍 UDP是传输层协议&#xff0c;它是无连接,不可靠传输,面向数据报,全双工 1.无连接&#xff1a;UDP是一种无连接的传输协议&#xff0c;通信双方不需要在发送数据之前建立连接。相比之下&#xff0c;TCP是面向连接的协议&#xff0c;在传输数…

基于大模型(LLM)相互协商的情感分析

Sentiment Analysis through LLM Negotiations https://arxiv.org/abs/2311.01876https://arxiv.org/abs/2311.01876 1.概述 在情感分析任务中,传统的单一大型语言模型(LLM)通常只通过单轮输出来做出决策。这种方法的主要缺点是无法完美应对需要深入推理的复杂语言现象,…

[Java、Android面试]_22_APP启动流程(中频问答)

欢迎查看合集&#xff1a; Java、Android面试高频系列文章合集 本人今年参加了很多面试&#xff0c;也有幸拿到了一些大厂的offer&#xff0c;整理了众多面试资料&#xff0c;后续还会分享众多面试资料。 整理成了面试系列&#xff0c;由于时间有限&#xff0c;每天整理一点&am…