1.redis源码阅读--跳表解析
2.Redis 码图主从复制 - 源码梳理
3.Redis radix tree 源码解析
4.redis源码解读(一):事件驱动的io模型,为什么,码图是码图什么,怎么做
redis源码阅读--跳表解析
跳表是码图 Redis 中实现 zset 和 set 功能的关键数据结构。通过在链表基础上构建多级索引,码图跳表有效提升了查找效率,码图go map 源码且其实现相较于红黑树更为简洁,码图无需大量精力来维持树的码图平衡。跳表节点具有顺序排列的码图特性,支持范围查询。码图
跳表的码图构成包括头结点、尾节点、码图长度以及索引层数。码图每一个节点包含数据 robj、码图分数 score 用于排序、码图上一节点指针 prev 用于反向遍历,以及多层索引信息 levels。各层索引 skiplistlevel 包括该层索引中节点指向的下一个节点指针 next 和间隔 span。节点的索引层数通过随机数生成,设计思路为使用第 n 级索引是使用第 n-1 级索引概率的 1/4,最多使用 级索引。使用如此设计可确保即便用到最高层级,所持数据量也足够大,无需担心索引不足。
跳表按照 score 和 robj 的大小进行排序,因此节点有序,支持范围查找。插入节点时,首先找到新节点可以插入的位置,即比新节点小的最大节点。此过程从最高层索引开始,使用 update 数组记录各层索引中节点的前一节点位置,以及 rank 数组记录 update 节点到 header 的间隔 span。新节点插入后,更新 prev 指针、cmake源码包卸载tail 指针、跳表长度等信息。
删除节点同样遵循类似的逻辑,先查找节点的前一个节点,然后删除目标节点。在删除过程中,需要检查节点的下一节点是否为待删除数据,并调整节点连接和更新跳表的 level 值。当某层索引中节点的 next 指针变为 nil 时,该层索引已无用,可将 level 减一。最后,更新跳表长度。
虽然跳表概念看似复杂,但通过理解其多级索引机制,其余操作如范围查询、排名查询等将变得相对简单。在实际应用中,可通过阅读 Redis 源码中的 t_zset.c 和 redis.h 文件,了解跳表的具体实现。然而,更难的是将这些抽象概念转化为清晰、易于理解的文档,绘制图表对于深入理解跳表的逻辑非常有帮助。
Redis 主从复制 - 源码梳理
本文主要剖析Redis主从复制机制中的核心组件之一——复制积压缓冲区(Replication Buffer),旨在为读者提供一个对Redis复制流程和缓冲区机制深入理解的平台,以下内容仅基于Redis版本7.0.,若读者在使用过程中发现偏差,欢迎指正。
复制积压缓冲区在逻辑上可理解为一个容量最大的位整数,其初始值为1,由offset、master_repl_offset和repl_backlog-histlen三个变量共同决定缓冲区的有效范围。offset表示缓冲区内命令起始位置,网金脱机源码master_repl_offset代表结束位置,二者之间的长度由repl_backlog-histlen表示。
每当主节点执行写命令,新生成的积压缓冲区大小增加,同时增加master_repl_offset和repl_backlog-histlen的值,直至达到预设的最大容量(默认为1MB)。一旦所有从节点接收到命令并确认同步无误,缓冲区内过期的命令将被移除,并调整offset和histlen以维持积压区容量的稳定性。
为实现动态分配,复制积压缓冲区被分解成多个block,以链表形式组织。每个block采用引用计数管理策略,初始值为0,每当增加或删除从节点对block的引用时,计数值相应增减。新生成block时,将master_repl_offset+1设置为block的repl_offset值,并将写入命令拷贝至缓冲区内,与此同时,master_repl_offset和repl_backlog-histlen增加。
通过循环遍历所有从节点,为每个从节点设置ref_repl_buf_node指向当前block或最后一个block,确保主从复制能够准确传递命令。当主节点接收到从节点的连接请求时,将开始填充积压缓冲区。在全量复制阶段,从slave-replstate为WAIT_BGSAVE_START至ONLINE,表示redis从后台进程开始执行到完成RDB文件传输和加载,命令传播至此阶段正式开始。
针对每个从节点,主节点从slave-ref_block_pos开始发送积压缓冲区内的命令,每发送成功,slave-ref_block_pos相应更新。ktv预订系统源码当积压缓冲区超过预设阈值,即复制积压缓冲区中的有效长度超过repl-backlog-size(默认1MB)时,主节点将清除已发送的缓冲区,释放内存。如果主节点写入命令频繁或从节点断线重连时间长,则需合理调整缓冲区大小(推荐值为2 * second * write_size_per_second)以保持增量复制的稳定运行。
当最后一个从节点与主节点的连接断开超过repl-backlog-ttl(默认为秒)时,主节点将释放repl_backlog和复制积压缓冲区以确保资源的有效使用。不过需要注意的是,从节点的释放操作依赖于节点是否可能成为新的主节点,因此在最后处理逻辑上需保持谨慎。
Redis radix tree 源码解析
Redis 实现了不定长压缩前缀的 radix tree,用于集群模式下存储 slot 对应的所有 key 信息。本文解析在 Redis 中实现 radix tree 的核心内容。
核心数据结构的定义如下:
每个节点结构体 (raxNode) 包含了指向子节点的指针、当前节点的 key 的长度、以及是否为叶子节点的标记。
以下是插入流程示例:
场景一:仅插入 "abcd"。此节点为叶子节点,使用压缩前缀。
场景二:在 "abcd" 之后插入 "abcdef"。从 "abcd" 的父节点遍历至压缩前缀,找到 "abcd" 空子节点,插入 "ef" 并标记为叶子节点。
场景三:在 "abcd" 之后插入 "ab"。ab 为 "abcd" 的前缀,插入 "ab" 为子节点,并标记为叶子节点。同时保留 "abcd" 的前缀结构。
场景四:在 "abcd" 之后插入 "abABC"。ab 为前缀,创建 "ab" 和 "ABC" 分别为子节点,保持压缩前缀结构。
删除流程则相对简单,强势来袭指标源码找到指定 key 的叶子节点后,向上遍历并删除非叶子节点。若删除后父节点非压缩且大小大于1,则需处理合并问题,以优化树的高度。
合并的条件涉及:删除节点后,检查父节点是否仍为非压缩节点且包含多个子节点,以此决定是否进行合并操作。
结束语:云数据库 Redis 版提供了稳定可靠、性能卓越、可弹性伸缩的数据库服务,基于飞天分布式系统和全SSD盘高性能存储,支持主备版和集群版高可用架构。提供全面的容灾切换、故障迁移、在线扩容、性能优化的数据库解决方案,欢迎使用。
redis源码解读(一):事件驱动的io模型,为什么,是什么,怎么做
Redis作为一个高性能的内存数据库,因其出色的读写性能和丰富的数据结构支持,已成为互联网应用不可或缺的中间件之一。阅读其源码,可以了解其内部针对高性能和分布式做的种种设计,包括但不限于reactor模型(单线程处理大量网络连接),定时任务的实现(面试常问),分布式CAP BASE理论的实际应用,高效的数据结构的实现,其次还能够通过大神的代码学习C语言的编码风格和技巧,让自己的代码更加优雅。
下面进入正题:为什么需要事件驱动的io模型
我们可以简单地将一个服务端程序拆成三部分,接受请求->处理请求->返回结果,其中接收请求和处理请求便是我们常说的网络io。那么网络io如何实现呢,首先我们介绍最基础的io模型,同步阻塞式io,也是很多同学在学校所学的“网络编程”。
使用同步阻塞式io的单线程服务端程序处理请求大致有以下几个步骤
其中3,4步都有可能使线程阻塞(6也会可能阻塞,这里先不讨论)
在第3步,如果没有客户端请求和服务端建立连接,那么服务端线程将会阻塞。如果redis采用这种io模型,那主线程就无法执行一些定时任务,比如过期key的清理,持久化操作,集群操作等。
在第4步,如果客户端已经建立连接但是没有发送数据,服务端线程会阻塞。若说第3步所提到的定时任务还可以通过多开两个线程来实现,那么第4步的阻塞就是硬伤了,如果一个客户端建立了连接但是一直不发送数据,服务端便会崩溃,无法处理其他任何请求。所以同步阻塞式io肯定是不能满足互联网领域高并发的需求的。
下面给出一个阻塞式io的服务端程序示例:
刚才提到,阻塞式io的主要问题是,调用recv接收客户端请求时会导致线程阻塞,无法处理其他客户端请求。那么我们不难想到,既然调用recv会使线程阻塞,那么我们多开几个几个线程不就好了,让那些没有阻塞的线程去处理其他客户端的请求。
我们将阻塞式io处理请求的步骤改造下:
改造后,我们用一个线程去做accept,也就是获取已经建立的连接,我们称这个线程为主线程。然后获取到的每个连接开一个新的线程去处理,这样就能够将阻塞的部分放到新的线程,达到不阻塞主线程的目的,主线程仍然可以继续接收其他客户端的连接并开新的线程去处理。这个方案对高并发服务器来说是一个可行的方案,此外我们还可以使用线程池等手段来继续优化,减少线程建立和销毁的开销。
将阻塞式io改为多线程io:
我们刚才提到多线程可以解决并发问题,然而redis6.0之前使用的是单线程来处理,之所以用单线程,官方给的答复是redis的瓶颈不在cpu,既然不在cpu那么用单线程可以降低系统的复杂度,避免线程同步等问题。如何在一个线程中非阻塞地处理多个socket,进而实现多个客户端的并发处理呢,那就要借助io多路复用了。
io多路复用是操作系统提供的另一种io机制,这种机制可以实现在一个线程中监控多个socket,返回可读或可写的socket,当一个socket可读或可写时再去操作它,这样就避免了对某个socket的阻塞等待。
将多线程io改为io多路复用:
什么是事件驱动的io模型(Reactor)
这里只讨论redis用到的单线程Reactor模型
事件驱动的io模型并不是一个具体的调用,而是高并发服务器的一种抽象的编程模式。
在Reactor模型中,有三种事件:
与这三种事件对应的,有三种handler,负责处理对应的事件。我们在一个主循环中不断判断是否有事件到来(一般通过io多路复用获取事件),有事件到来就调用对应的handler去处理时间。
听着玄乎,实际上也就这一张图:
事件驱动的io模型在redis中的实现
以下提及的源码版本为 5.0.8
文字的苍白的,建议参照本文最后的方法下载代码,自己调试下
整体框架
redis-server的main方法在 src/server.c 最后,在main方法中,首先进行一系列的初始化操作,最后进入进入Reactor模型的主循环中:
主循环在aeMain函数中,aeMain函数传入的参数 server.el ,是一个 aeEventLoop 类型的全局变量,保存了主循环的一些状态信息,包括需要处理的读写事件、时间事件列表,epoll相关信息,回调函数等。
aeMain函数中,我们可以看到当 eventLoop->stop 标志位为0时,while循环中的内容会被重复执行,每次循环首先会调用beforesleep回调函数,然后处理时间。beforesleep函数在main函数中被注册,会进行集群状态更新、AOF落盘等任务。
之所以叫beforesleep,是因为aeProcessEvents函数中包含了获取事件和处理事件的逻辑,其中获取读写事件时通过epoll_wait实现,会将线程阻塞。
在aeProcessEvents函数中,处理读写事件和时间事件,参数flags定义了需要处理的事件类型,我们可以暂时忽略这个参数,认为读写时间都需要处理。
aeProcessEvents函数的逻辑可以分为三个部分,首先获取距离最近的时间事件,这一步的目的是为了确定epoll_wait的超时时间,并不是实际处理时间事件。
第二个部分为获取读写事件并处理,首先调用epoll_wait,获取需要处理的读写事件,超时时间为第一步确定的时间,也就是说,如果在超时时间内有读写事件到来,那么处理读写时间,如果没有读写时间就阻塞到下一个时间事件到来,去处理时间事件。
第三个部分为处理时间事件。
事件注册与获取
上面我们讲了整体框架,了解了主循环的大致流程。接下来我们来看其中的细节,首先是读写事件的注册与获取。
redis将读、写、连接事件用结构aeFileEvent表示,因为这些事件都是通过epoll_wait获取的。
事件的具体类型通过mask标志位来区分。aeFileEvent还保存了事件处理的回调函数指针(rfileProc、wfileProc)和需要读写的数据指针(clientData)。
既然读写事件是通过epoll io多路复用实现,那么就避不开epoll的三部曲 epoll_create epoll_ctrl epoll_wait,接下来我们看下redis对epoll接口的封装。
我们之前提到aeMain函数的参数是一个 aeEventLoop 类型的全局变量,aeEventLoop中保存了epoll文件描述符和epoll事件。在aeApiCreate函数(src/ae_epoll.c)中,会调用epoll_create来创建初始化epoll文件描述符和epoll事件,调用关系为 main -> initServer -> aeCreateEventLoop -> aeApiCreate
调用epoll_create创建epoll后,就可以添加需要监控的文件描述符了,需要监控的情形有三个,一是监控新的客户端连接连接请求,二是监控客户端发送指令,也就是读事件,三是监控客户端写事件,也就是处理完了请求写回结果。
这三种情形在redis中被抽象为文件事件,文件事件通过函数aeCreateFileEvent(src/ae.c)添加,添加一个文件事件主要包含三个步骤,通过epoll_ctl添加监控的文件描述符,指定回调函数和指定读写缓冲区。
最后是通过epoll_wait来获取事件,上文我们提到,在每次主循环中,首先根据最近到达的时间事件来计算epoll_wait的超时时间,然后调用epoll_wait获取事件,再处理事件,其中获取事件在函数aeApiPoll(src/ae_epoll.c)中。
获取到事件后,主循环中会逐个调用事件的回调函数来处理事件。
读写事件的实现
写累了,有空补上……
如何使用vscode调试redis源码
编译出二进制程序
这一步有可能报错:
jemalloc是内存分配的一种更高效的实现,用于代替libc的默认实现。这里报错找不到jemalloc,我们只需要将其替换成libc默认实现就好:
如果报错:
我们可以在src目录找到一个脚本名为mkreleasehdr.sh,其中包含创建release.h的逻辑,将报错信息网上翻可以发现有一行:
看来是这个脚本没有执行权限,导致release.h没有成功创建,我们需要给这个脚本添加执行权限然后重新编译:
2. 创建调试配置(vscode)
创建文件 .vscode/launch.json,并填入以下内容:
然后就可以进入调试页面打断点调试了,main函数在 src/server.c