1.redis源码阅读--跳表解析
2.redis源码学习-quicklist篇
3.[redis 组组件源码走读] maxmemory 数据淘汰策略
4.Redis源码解析：一条Redis命令是如何执行的？
5.分析SpringBoot 的Redis源码
6.Redis源码从哪里读起？

redis源码阅读--跳表解析

       跳表是 Redis 中实现 zset 和 set 功能的关键数据结构。通过在链表基础上构建多级索引，组组件跳表有效提升了查找效率，组组件且其实现相较于红黑树更为简洁，组组件无需大量精力来维持树的组组件平衡。跳表节点具有顺序排列的组组件qtcreator 源码特性，支持范围查询。组组件

       跳表的组组件构成包括头结点、尾节点、组组件长度以及索引层数。组组件每一个节点包含数据 robj、组组件分数 score 用于排序、组组件上一节点指针 prev 用于反向遍历，组组件以及多层索引信息 levels。组组件各层索引 skiplistlevel 包括该层索引中节点指向的组组件下一个节点指针 next 和间隔 span。节点的索引层数通过随机数生成，设计思路为使用第 n 级索引是使用第 n-1 级索引概率的 1/4，最多使用 级索引。使用如此设计可确保即便用到最高层级，所持数据量也足够大，无需担心索引不足。

       跳表按照 score 和 robj 的大小进行排序，因此节点有序，支持范围查找。插入节点时，首先找到新节点可以插入的位置，即比新节点小的最大节点。此过程从最高层索引开始，使用 update 数组记录各层索引中节点的前一节点位置，以及 rank 数组记录 update 节点到 header 的间隔 span。新节点插入后，更新 prev 指针、tail 指针、跳表长度等信息。

       删除节点同样遵循类似的逻辑，先查找节点的钉钉的源码前一个节点，然后删除目标节点。在删除过程中，需要检查节点的下一节点是否为待删除数据，并调整节点连接和更新跳表的 level 值。当某层索引中节点的 next 指针变为 nil 时，该层索引已无用，可将 level 减一。最后，更新跳表长度。

       虽然跳表概念看似复杂，但通过理解其多级索引机制，其余操作如范围查询、排名查询等将变得相对简单。在实际应用中，可通过阅读 Redis 源码中的 t_zset.c 和 redis.h 文件，了解跳表的具体实现。然而，更难的是将这些抽象概念转化为清晰、易于理解的文档，绘制图表对于深入理解跳表的逻辑非常有帮助。

redis源码学习-quicklist篇

       Redis源码中的quicklist是ziplist优化版的双端链表，旨在提高内存效率和操作效率。ziplist虽然内存使用率高，但查找和增删操作的最坏时间复杂度可能达到O(n^2)，这与Redis高效数据处理的要求不符。quicklist通过每个节点独立的ziplist结构，降低了更新复杂度，同时保持了内存使用率。

       quicklist的基本结构包括：头节点（head）、尾节点（tail）、entry总数（count）、节点总数（len）、容量指示（fill）、压缩深度（compress）、以及用于内存管理的多个指标源码公式bookmarks。节点结构包括双向链表的prev和next，ziplist的引用zl，ziplist的字节数sz、item数count、以及ziplist类型（raw或lzf压缩）和尝试压缩标志（attempted_compress）。

       核心操作函数如create用于初始化节点，insert则根据需求执行头插法或尾插法。delete则简单地从链表中移除节点，释放相关内存。quicklist的优化重点在于ziplist，理解了ziplist的工作原理，quicklist的数据结构理解就相对容易了。

[redis 源码走读] maxmemory 数据淘汰策略

       Redis 是一个内存数据库，通过配置 `maxmemory` 来限定其内存使用量。当 Redis 主库内存超出限制时，会触发数据淘汰机制，以减少内存使用量，直至达到限制阈值。

       当 `maxmemory` 配置被应用，Redis 会根据配置采用相应的数据淘汰策略。`volatile-xxx` 类型配置仅淘汰设置了过期时间的数据，而 `allkeys-xxx` 则淘汰数据库中所有数据。若 Redis 主要作为缓存使用，可选择 `allkeys-xxx`。

       数据淘汰时机发生在事件循环处理命令时。有多种淘汰策略可供选择，从简单到复杂包括：不淘汰数据（`noeviction`）、随机淘汰（`volatile-random`、`allkeys-random`）、采样淘汰（`allkeys-lru`、`volatile-lru`、`volatile-ttl`、`volatile-freq`）以及近似 LRU 和 LRU 策略（`volatile-lru` 和 `allkeys-lru`）。

       `noeviction` 策略允许读操作但禁止大多数写命令，返回 `oomerr` 错误，逐鹿泛目录 源码仅允许执行少量写命令，如删除命令 `del`、`hdel` 和 `unlink`。

       `volatile-random` 和 `allkeys-random` 机制相对直接，随机淘汰数据，策略相对暴力。

       `allkeys-lru` 策略根据最近最少使用（LRU）算法淘汰数据，优先淘汰最久未使用的数据。

       `volatile-lru` 结合了过期时间与 LRU 算法，优先淘汰那些最久未访问且即将过期的数据。

       `volatile-ttl` 策略淘汰即将过期的数据，而 `volatile-freq` 则根据访问频率（LFU）淘汰数据，考虑数据的使用热度。

       `volatile-lru` 和 `allkeys-lru` 策略通过采样来近似 LRU 算法，维护一个样本池来确定淘汰顺序，以提高淘汰策略的精确性。

       总结而言，Redis 的数据淘汰策略旨在平衡内存使用与数据访问需求，通过灵活的配置实现高效的数据管理。策略的选择应基于具体应用场景的需求，如数据访问模式、性能目标等。

Redis源码解析：一条Redis命令是如何执行的？

       作者：robinhzhang

       Redis，一个开源内存数据库，凭借其高效能和广泛应用，如缓存、消息队列和会话存储，本文将带你探索其命令执行的底层流程。本文将以源码解析的形式，逐层深入Redis的核心结构和命令执行过程，旨在帮助开发者理解实现细节，提升编程技术和设计意识。

       源码结构概览

       在学习Redis源代码之前，首先要了解其主要的组成部分：redisServer、redisClient、华尔街电玩城源码redisDb、redisObject以及aeEventLoop。这些结构体和事件模型构成了Redis的核心架构。

       redisServer：服务端运行的核心结构，包括监听socket、数据存储的redisDb列表和客户端连接信息。

       redisClient：客户端连接状态的存储，包括命令处理缓冲区、回复数据列表和数据库句柄。

       redisDb：键值对的数据存储，采用两个哈希表实现渐进式rehash。

       redisObject：存储对象的通用表示，包含引用计数和LRU时间，用于内存管理。

       aeEventLoop：事件循环，管理文件和时间事件的处理。

       核心流程详解

       Redis的执行流程从main函数开始，首先初始化配置和服务器组件，进入主循环处理事件。命令执行流程涉及redis启动、客户端连接、接收命令和返回结果四个步骤：

       启动阶段：创建socket服务器，注册可读事件，进入主循环。

       连接阶段：客户端连接后，接收并处理命令，创建客户端实例。

       命令阶段：客户端发送命令，服务端解析并调用对应的命令处理函数。

       结果阶段：处理命令后，根据协议格式构建回复并写回客户端。

       渐进式rehash与内存管理

       Redis的内存管理采用引用计数法，通过对象的refcount字段控制内存分配和释放。rehash操作在Redis 2.x版本引入，通过逐步迁移键值对，降低对单线程性能的影响。当负载达到阈值，会进行扩容，这涉及新表的创建和键值对的迁移。

       总结

       本文通过Redis源码分析，揭示了其命令执行的细节，包括启动流程、客户端连接、命令处理和结果返回，以及内存管理策略。这将有助于开发者深入理解Redis的工作原理，提升编程效率和设计决策能力。

分析SpringBoot 的Redis源码

       在Spring Boot 2.X版本中，官方简化了项目配置，如无需编写繁琐的web.xml和相关XML文件，只需在pom.xml中引入如spring-boot-starter-data-redis的starter包即可完成大部分工作，这极大地提高了开发效率。

       深入理解其原理，我们研究了spring-boot-autoconfigure和spring-boot-starter-data-redis的源码。首先，配置项在application.properties中的设置会被自动映射到名为RedisProperties的类中，此类由RedisAutoConfiguration类负责扫描和配置。该类会检测是否存在RedisOperations接口的实现，例如官方支持的Jedis或Lettuce，以此来决定使用哪个客户端。

       在RedisAutoConfiguration中，通过@Bean注解，它引入了LettuceConnectionConfiguration和JedisConnectionConfiguration，这两个配置类会创建RedisConnectionFactory实例。在注入RedisTemplate时，实际使用的会是第一个被扫描到的RedisConnectionFactory，这里通常是LettuceConnectionFactory，因为它们在@Import注解的导入顺序中位于前面。

       自定义starter时，可以模仿官方starter的结构，首先引入spring-boot-autoconfigure，然后创建自己的配置类（如MyRedisProperties）和操作模板类（如JedisTemplete）。在MyRedisAutoConfiguration中，你需要编写相关配置并确保在spring.factories文件中注册，以便Spring Boot在启动时扫描到你的自定义配置。

       以自定义my-redis-starter为例，项目结构包括引入的依赖，配置类的属性绑定，以及创建连接池和操作方法的实现。测试时，只需在Spring Boot项目中引入自定义starter，配置好相关参数，即可验证自定义starter的正确工作。

Redis源码从哪里读起？

       如果你正寻求理解Redis源码的路径，本文为你提供了一个全面的指南。Redis 是使用 C 语言构建的，因此，我们从 main 函数开始，深入探索其核心逻辑。在阅读过程中，我们应聚焦于从外部命令输入到内部执行流程的路径，逐步理解 Redis 的工作原理。

       理解事件机制对于深入 Redis 的核心至关重要。通过 Redis 的事件循环，我们可以实现单线程环境下的高效处理多任务的能力。这一机制允许 Redis 以线程安全的方式处理大量请求，同时在执行后台任务时保持响应速度。事件循环与系统提供的异步 I/O 多路复用机制相结合，确保了 CPU 资源的高效利用，避免了并发执行的复杂性。

       在讨论事件循环时，我们重点关注了两个阶段：初始化和事件处理。初始化阶段涉及配置和数据加载，而事件处理阶段则负责响应客户端请求、执行命令以及周期性任务的调度。通过事件循环，Redis 实现了在单一线程下处理多个请求的高效运行模式。

       理解 Redis 命令请求的处理流程是整个指南的关键部分。当客户端向 Redis 发送命令时，流程分为两个阶段：连接建立和命令执行与响应。连接建立阶段由事件循环触发，而命令执行与响应阶段则涉及读取客户端发送的数据，执行命令并返回结果。这一过程通过特定的回调函数实现，确保了命令处理的高效和线程安全。

       此外，我们还讨论了 Redis 的事件机制，即事件驱动程序库 ae.c，它在不同操作系统上支持多种 I/O 多路复用机制。在选择底层机制时，Redis 优先考虑后三种更现代、高效的方案，例如 macOS 上的 kqueue 和 Linux 上的 epoll。理解这些机制对于实现高性能网络服务至关重要。

       为了帮助读者在阅读 Redis 源码时构建清晰的思维路径，我们提供了一个树型图展示关键函数之间的调用关系。这张图基于 Redis 源码的 5.0 分支，详细地展示了初始化、事件处理、命令请求处理等关键流程的调用顺序。

       最后，本文提供的参考文献旨在为读者提供进一步学习的资源。对于希望深入理解 Redis 源码并学习 C 语言编程经验的读者，这些资源将起到重要作用。总的来说，本文旨在为那些希望从源头上理解 Redis 工作机制的技术爱好者提供一个全面、系统化的指南。

Redis 源码剖析 3 -- redisCommand

       Redis 使用 redisCommand 结构体处理命令请求，其内包含一个指向对应处理函数的 proc 指针。redisCommandTable 是一个存储所有 Redis 命令的数组，位于 server.c 文件中。此数组通过 populateCommandTable() 函数填充，该函数将 redisCommandTable 的内容添加到 server.commands 字典，将 Redis 支持的所有命令及其实现整合。

       populateCommandTable() 函数中包含 populateCommandTableParseFlags() 子函数，用于将 sflags 字符串转换为对应的 flags 值。lookupCommand*() 函数族负责从 server.commands 中查找相应的命令。

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相应更新。当积压缓冲区超过预设阈值，即复制积压缓冲区中的有效长度超过repl-backlog-size（默认1MB）时，主节点将清除已发送的缓冲区，释放内存。如果主节点写入命令频繁或从节点断线重连时间长，则需合理调整缓冲区大小（推荐值为2 * second * write_size_per_second）以保持增量复制的稳定运行。

       当最后一个从节点与主节点的连接断开超过repl-backlog-ttl（默认为秒）时，主节点将释放repl_backlog和复制积压缓冲区以确保资源的有效使用。不过需要注意的是，从节点的释放操作依赖于节点是否可能成为新的主节点，因此在最后处理逻辑上需保持谨慎。