皮皮网

1.[redis 单s单源码走读] maxmemory 数据淘汰策略
2.Redis 主从复制 - 源码梳理
3.Redis源码解析：一条Redis命令是如何执行的？
4.Redis源码从哪里读起？
5.Redis radix tree 源码解析
6.深度解析单线程的 Redis 如何做到每秒数万 QPS 的超高处理能力！

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

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

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

       数据淘汰时机发生在事件循环处理命令时。线程线程有多种淘汰策略可供选择，源码原理从简单到复杂包括：不淘汰数据（`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 算法，维护一个样本池来确定淘汰顺序，以提高淘汰策略的php源码获取网站源码精确性。

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

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和复制积压缓冲区以确保资源的有效使用。不过需要注意的是，从节点的释放操作依赖于节点是否可能成为新的主节点，因此在最后处理逻辑上需保持谨慎。

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

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 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 如何做到每秒数万 QPS 的超高处理能力！

       大家好，我是飞哥！

       在网络编程中，提到高性能，很多人会想到多线程。但实际上，服务器端仅需单线程便可实现极高处理能力，Redis 就是这一模式的杰出代表，能够支撑每秒数万 QPS 的性能。今天，我们将深入探讨 Redis 核心网络模块的实现，揭示它是如何实现如此高性能的。

       本文转自个人技术公众号「开发内功修炼」，关注以获取飞哥最新深度文章。同时，分享我撰写的电子书《理解了实现再谈网络性能》。该书正处于出版流程中。需要电子版的朋友可点击下载，或添加我本人: zhangyanfei，获取《理解了实现再谈网络性能》的链接。

       一、理解多路复用原理

       在开始介绍 Redis 之前，让我们先简单介绍下 epoll。

       在传统的同步阻塞网络编程模型中，进程线程的高开销是影响性能的根本原因。单个进程或线程只能处理一个用户请求，犹如一个人只能看管一只羊。当面对成千上万的请求时，这种模式的成本非常高。

       性能提升的关键在于让众多请求复用同一个进程或线程，这就是多路复用。多路指的是众多用户连接，复用指的是对进程或线程的高效利用。以羊群为例，只需一名牧羊人即可管理。

       实现多路复用需要特殊的 socket 事件管理机制，其中 epoll 是最高效和典型的方案。它的工作原理类似于一只牧羊犬，负责管理与进程或线程复用相关的 socket 事件。

       二、Redis 服务启动与初始化

       理解了 epoll 的基本原理后，我们将探索 Redis 如何具体实现这一机制。通过 Github 即可获取 Redis 源码，我们关注 5.0.0 版本中的单线程版本实现。

       整个 Redis 服务的核心入口位于 src/server.c 文件中，主要集中在 initServer 和 aeMain 函数。在 initServer 这个关键函数内，Redis 执行了以下三项重要操作。

       2.1 创建 epoll 对象

       在 aeCreateEventLoop 函数中创建 epoll 对象，然后将其保存在 redisServer 的 aeEventLoop 成员中。接下来，我们深入了解 aeCreateEventLoop 的具体逻辑。

       在 eventLoop 对象中，eventLoop->events 数组用于保存各种事件处理器。真正创建 epoll 对象的过程发生在 ae_epoll.c 文件的 aeApiCreate 函数中，通过调用 epoll_create 实现。

       2.2 绑定监听服务端口

       Redis 的 listen 过程发生在 listenToPort 函数中，通过 bind 和 listen 系统调用完成。

       Redis 支持多个端口，listenToPort 函数内部使用循环调用 anetTcpServer，逐步展开调用直到执行 bind 和 listen。

       2.3 注册事件回调函数

       initServer 函数中，Redis 调用 aeCreateEventLoop 创建 epoll 对象后，通过 listenToPort 进行服务端口绑定。接着，调用 aeCreateFileEvent 注册 accept 事件处理器。

       在 aeCreateFileEvent 函数中，Redis 为 listen socket 上的新用户连接注册了 acceptTcpHandler 作为读回调函数，负责处理新连接请求。

       三、Redis 事件处理循环

       在上一节中，我们了解了 Redis 的启动初始化过程。接下来，Redis 将进入 aeMain 开始真正的用户请求处理。

       aeMain 函数是一个无休止的循环，每次循环中执行如下关键操作。

       3.1 epoll_wait 发现事件

       Redis 通过 epoll_wait 统一发现和管理可读（包括 listen socket 上的 accept 事件）、可写事件，并管理 timer 事件。

       每当发现特定事件发生，epoll_wait 调用相应注册的事件处理函数进行处理。aeProcessEvents 函数封装了 epoll_wait 的逻辑。

       3.2 处理新连接请求

       假设现在有新用户连接到达。listen socket 上的 rfileProc 注册的 acceptTcpHandler 负责处理新连接请求。在 acceptTcpHandler 中，主要完成接收连接、创建客户端连接对象和注册读事件处理器。

       anetTcpAccept 负责调用 accept 接收新连接，acceptCommonHandler 为连接创建客户端连接对象，createClient 注册读事件处理器。

       3.3 处理客户连接上的可读事件

       当用户发送命令时，Redis 通过 epoll_wait 发现可读事件后，调用已注册的读处理函数 readQueryFromClient。

       在 readQueryFromClient 中，Redis 处理命令并将其转换为内部数据结构，如执行 GET 命令并从内存中查找值。

       四、高性能 Redis 网络原理总结

       Redis 服务器通过单线程实现高处理能力，每秒可达到数万 QPS，这主要得益于对 Linux 多路复用机制 epoll 的高效利用。

       Redis 的核心逻辑集中于 initServer 和 aeMain 两个关键函数，理解这些函数是掌握 Redis 网络原理的基础。

       总结 Redis 的网络核心模块，包括启动服务和事件循环处理，对于深入理解网络编程大有裨益。相信通过本文的介绍，您对网络编程的理解将会更加深入。

       快来分享这篇文章给您的技术好友吧！

       最后，分享我撰写的电子书《理解了实现再谈网络性能》，该书正处于出版流程中。电子版下载地址或添加我本人: zhangyanfei，获取《理解了实现再谈网络性能》的链接。

Redis 源码剖析 3 -- redisCommand

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

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