redis学习笔记三：单机数据库

Posted on | In

redisDB

简介

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

    // ...

    // 数据库键空间，保存着数据库中的所有键值对
    dict *dict;

    // ...

} redisDb;

里面的字典结构被称为 key space

好像就没什么好讲的了毕竟dict结构前面夜看到过emmmm，放张图吧

读写时的维护操作

  • 在读取一个键之后（读操作和写操作都要对键进行读取）， 服务器会根据键是否存在， 以此来更新服务器的键空间命中（hit）次数或键空间不命中（miss）次数， 这两个值可以在 INFO stats 命令的 keyspace_hits 属性和 keyspace_misses 属性中查看。
  • 在读取一个键之后， 服务器会更新键的 LRU （最后一次使用）时间， 这个值可以用于计算键的闲置时间， 使用命令 OBJECT idletime 命令可以查看键 key 的闲置时间。

lru这个对象里提到过，可以计算闲置时间也可以用于一些算法的内存回收，hit数的作用则尚且不明确

  • 如果有客户端使用 WATCH 命令监视了某个键， 那么服务器在对被监视的键进行修改之后， 会将这个键标记为脏（dirty）， 从而让事务程序注意到这个键已经被修改过， 《事务》一章会详细说明这一点。
  • 服务器每次修改一个键之后， 都会对脏（dirty）键计数器的值增一， 这个计数器会触发服务器的持久化以及复制操作执行， 《RDB 持久化》、《AOF 持久化》和《复制》这三章都会说到这一点。
  • 如果服务器开启了数据库通知功能， 那么在对键进行修改之后， 服务器将按配置发送相应的数据库通知， 本章稍后讨论数据库通知功能的实现时会详细说明这一点。

这三个后面回提到的东西先记下，等提到再callback吧

持久化

一切的开始之前先讲一下redis持久化是个什么东西（也是四处看博客的总结而已）

像我们的mysql这种db是不需要持久化的，它本来就是存储在硬盘里的数据，经过关机重启之类的操作不会丢也不会怎么滴

但是redis是一种内存的存储，内存这种东西在重启之后会直接清空，在服务器进程结束重新启动之后需要持久化来恢复原来的redis存储。方案有两种，一个是RDB，一个是AOF

RDB

RDB就是将某一时刻的数据集，用一种非常紧凑的格式的文件，保存下来（有点像快照）

但是很明显，如果没执行一次写操作就同步rdb，那效率就过于离谱了，可以用于数据集的备份甚至是版本控制

上面是一个RDB文件的结构，下面是里面的一个数据库的结构

SELECTDB 常量的长度为 1 字节， 当读入程序遇到这个值的时候， 它知道接下来要读入的将是一个数据库号码

下面是key_value_pairs的结构

  1. 如果没有过期时间的话前两格没有，直接从类型开始
  2. TYPE 记录了 value 的类型， 长度为 1 字节，也就是上面对象里面对象类型或者底层编码，比如REDIS_RDB_TYPE_STRING

键值对value结构

https://www.w3cschool.cn/hdclil/yohs7ozt.html

啊一个一个写感觉也没有必要，里面保存的其实就是前面讲到的对象结构，要用的或者关心的时候回来看一眼吧，包括具体的保存结构，压缩方案之类的

TBD

RDB的产生和update逻辑是什么样子的？

AOF

append only file

AOF文件会把所有的写入动作都存进一个文件，并在服务器启动时，通过重新执行这些命令来还原数据集。

命令追加

就是客户端每做一个会改变存储的操作：比如set或者update，就会追加一个操作到缓冲区

文件写入

redis的eventloop，在每次接收客户端请求进行操作之后，都会考虑是否将aof缓冲区（aof_buf）的文件写入和保存到aof文件里

flushAppendOnlyFile 函数的行为由服务器配置的 appendfsync 选项的值来决定

appendfsync 选项的值 flushAppendOnlyFile 函数的行为
always 将 aof_buf 缓冲区中的所有内容写入并同步到 AOF 文件。
everysec 将 aof_buf 缓冲区中的所有内容写入到 AOF 文件， 如果上次同步 AOF 文件的时间距离现在超过一秒钟， 那么再次对 AOF 文件进行同步， 并且这个同步操作是由一个线程专门负责执行的。
no 将 aof_buf 缓冲区中的所有内容写入到 AOF 文件， 但并不对 AOF 文件进行同步， 何时同步由操作系统来决定。

文件写入数据丢失问题

aof操作是写在内存缓冲区的，那么如果突然宕机了又改怎么办

不同的函数配置丢失的数据就不一样，always最多丢失的就是一个eventloop内的缓冲区指令。everysec丢失的是一秒的指令，no则会丢失上次同步之后写入的所有的数据

但是相反，always因为每次写入之后都要同步，所以写入效率是最低的，no无需执行同步操作，所以写入效率自然也快很多

aof可以很好地解决数据同步和避免数据丢失的问题，但是同时aof的文件大小会随着redis运行的时长变得非常非常非常离谱=》怎样把rdb和aof组合？

事件

背景

io多路复用：i/o multiplexing

简单一点来说就和我们go channel的select逻辑很像，只不过从同时监听多个channel变成了同时监听多个fd，不需要一个线程一个fd这么消耗资源还不好维护

select 和 epoll的区别：后面再说吧不属于redis范畴

Reactor模式

用多路复用的规则去监听事件，监听到了之后就扔给handler去处理事件（简单来说就是这样

文件事件

发现了redis设计与实现这本书一个诡异的问题，经常是上来连这个东西是什么干什么用的都不解释就哐哐哐一顿原理输出

文件事件是redis服务端通过socket连接客户端，并且处理客户端操作的抽象

  1. 每个套接字执行连接，读取，写入，关闭等操作
  2. 每个操作产生一个文件事件，被io多路复用程序写入队列扔给分派器
    1. 因为io多路复用本质是个block逻辑，所以只有一个套接字内的文件事件都结束了，多路复用程序才会执行下一次event loop并且把下一个套接字的事件扔进队列
  3. 分派器会根据文件事件类型调度不同的处理器去处理

多路复用的函数都是套了linux epoll，select之类的 函数

Redis 为文件事件编写了多个处理器， 这些事件处理器分别用于实现不同的网络通讯需求， 比如说：

  • 为了对连接服务器的各个客户端进行应答， 服务器要为监听套接字关联连接应答处理器。
  • 为了接收客户端传来的命令请求， 服务器要为客户端套接字关联命令请求处理器。
  • 为了向客户端返回命令的执行结果， 服务器要为客户端套接字关联命令回复处理器。
  • 当主服务器和从服务器进行复制操作时， 主从服务器都需要关联特别为复制功能编写的复制处理器。
  • 等等。

在这些事件处理器里面， 服务器最常用的要数与客户端进行通信的连接应答处理器、 命令请求处理器和命令回复处理器。

AE_READABLE 事件和 AE_WRITABLE 事件的概念是说，这个socket本身是可读的还是可写的，比如建立连接，读取指令就是readable事件，向socket写入返回结果，就是writable事件（感觉书里把它写复杂了

备注：

I/O 多路复用程序允许服务器同时监听套接字的 AE_READABLE 事件和 AE_WRITABLE 事件， 如果一个套接字同时产生了这两种事件， 那么文件事件分派器会优先处理 AE_READABLE 事件， 等到 AE_READABLE 事件处理完之后， 才处理 AE_WRITABLE 事件。

这也就是说， 如果一个套接字又可读又可写的话， 那么服务器将先读套接字， 后写套接字。

时间事件

时间事件是redis内部的另一种事件类型，时间事件可以实现定时或周期两种逻辑

服务器将所有时间事件都放在一个无序链表中，每当时间事件执行器运行时，它就遍历整个链表，查找所有已到达的时间事件，并调用相应的事件处理器。

上面讲到的处理持久化aof的逻辑，就是在一个叫serverCron的函数里执行的，而有一个时间事件就是执行serverCron函数。

持续运行的Redis服务器需要定期对自身的资源和状态进行检查和调整，从而确保服务器可以长期、稳定地运行，这些定期操作由redis.c/serverCron函数负责执行，它的主要工作包括：

更新服务器的各类统计信息，比如时间、内存占用、数据库占用情况等

清理数据库中的过期键值对。

关闭和清理连接失效的客户端

尝试进行AOF或RDB持久化操作

如果服务器是主服务器，那么对从服务器进行定期同步

如果处于集群模式，对集群进行定期同步和连接测

客户端

这里的客户端指的是在服务器内，每个连接的客户端都会被用redisClient结构体保存下来

客户端属性

1
2
> CLIENT list
id=-1498257551710864375 addr=9.137.217.100:51572 fd=96 name= cmd=ping age=99963 idle=21 proxy=3062a189cc80bde541b30efc7a5721c37c89df49
  • fd: 套接字描述符，普通客户端fd>0，伪客户端fd=-1，伪客户端处理的命令请求来源于 AOF 文件或者 Lua 脚本， 而不是网络， 所以这种客户端不需要套接字连接， 自然也不需要记录套接字描述符。
  • name：客户端名称，正常情况下客户端名称都是么有的，使用 CLIENT_SETNAME 命令可以为客户端设置一个名字
  • flags：客户端的身份和状态-具体以后再看文档吧
  • age：客户端的连接时间（s）

客户端命令执行

  1. 客户端发出的命令会被放到redisClient的输入缓冲区 querybuf，querybuf的大小是动态的，但是如果超过1个G客户端就会自动断开，but redis-cli 终端默认只能输入 4095 个字符，用脚手架倒是不会超过就是了
  2. 分析存在缓冲区的命令，并且把命令解析之后存在 argc 和 argv里面，其中argc负责记录argv的长度，argv[0] 默认是command，后面是按顺序输入的参数（这倒就是普通的读输入逻辑

  1. 根据argv[0] 的command，在命令表找到对应的redisCommand，并且把客户端的cmd指针指向对应的redisCommand，之后客户端就可以执行command命令

  1. 执行命令所得的命令回复会被保存在客户端状态的输出缓冲区里面，客户端的缓冲区有两种，固定大小缓冲区和可变大小缓冲区。简单来说就是固定大小缓冲区是自带默认的，大小默认是16kb。如果返回很大固定大小缓冲区塞不下就会用到可变大小缓冲区，可变大小缓冲区的数据结构是个链表

服务器

这个是抄书的一个，上面讲过的客户端发送命令到收到ok的大致过程：（大家都知道就是了

那么从客户端发送 SET KEY VALUE 命令到获得回复 OK 期间， 客户端和服务器共需要执行以下操作：

  1. 客户端向服务器发送命令请求 SET KEY VALUE 。
  2. 服务器接收并处理客户端发来的命令请求 SET KEY VALUE ， 在数据库中进行设置操作， 并产生命令回复 OK 。
  3. 服务器将命令回复 OK 发送给客户端。
  4. 客户端接收服务器返回的命令回复 OK ， 并将这个回复打印给用户观看。

中间的细节：不想写感觉除了上一节写的东西之外也就是多讲了一些细节，比如参数校验，身份验证还有一些执行之后的后续工作，有需要再看吧

总结

如果说上一个章节是介绍了redis在内存中保存的数据结构的话，这个章节介绍的就是redis服务器是怎么运行的，包括持久化存储逻辑，事件处理，客户端连接，处理客户端请求等（感觉这本书意外地写得挺清楚