【好公式指标源码】【android源码编译依赖】【尚硅谷源码安装】redis 源码 pdf
1.Redis源码学习(28)-Redis中有序集合对象类型的实现（下）
2.Redis源码解析：一条Redis命令是如何执行的？
3.Redis7.0源码阅读：哈希表扩容、缩容以及rehash
4.redis7.0源码阅读：Redis中的IO多线程（线程池）
5.[redis 源码走读] maxmemory 数据淘汰策略
6.Redis 主从复制 - 源码梳理
Redis源码学习(28)-Redis中有序集合对象类型的实现（下）
Redis提供了删除有序集合中元素的命令ZREM，其可以删除不存在的成员，执行成功后返回被删除元素的数量。这个操作是通过zremCommand函数实现的，它首先查找对应的好公式指标源码有序集合，然后循环调用zsetDel进行删除，当集合成员减为0时，会从内存数据库中移除。 除此之外，Redis还有一组命令ZREMRANGEBYRANK、ZREMRANGEBYSCORE与ZREMRANGEBYLEX，用于根据排名、分值或字典顺序批量删除有序集合成员。它们都通过zremrangeGenericCommand函数，结合不同删除类型接口来执行操作。 有序集合的集合操作包括ZUNIONSTORE和ZINTERSTORE，用于计算交集和并集，支持权重参数和聚合方式（默认SUM）。操作完成后，destination集合会被覆盖。 区间获取命令如ZRANGE和ZREVRANGE，以及ZRANGEBYSCORE和ZREVRANGEBYSCORE，提供了基于排序和分值的区间成员获取功能，通过genericZrangebyscoreCommand函数实现。 ZRANGEBYLEX和ZREVRANGEBYLEX命令则基于字典顺序获取区间成员，同样有类似的实现基础。 Redis的ZCOUNT和ZLEXCOUNT命令分别用于计算指定分值区间内的成员数量，前者根据底层编码选择不同的计算策略，后者仅在所有成员分值相同时有效。 统计元素个数的ZCARD命令，通过zsetLength接口获取，而ZSCORE用于获取指定成员的分值，不存在或成员不存在则返回nil。 排名操作ZRANK和ZREVRANK由zrankGenericCommand实现，利用zsetRank接口获取元素排名。 有序集合的android源码编译依赖弹出数据操作ZPOPMIN和ZPOPMAX，以及阻塞版本BZPOPMIN和BZPOPMAX，通过genericZpopCommand函数处理，根据集合非空状态决定是否阻塞。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的工作原理，提升编程效率和设计决策能力。Redis7.0源码阅读：哈希表扩容、缩容以及rehash
当哈希值相同发生冲突时，Redis 使用链表法解决，将冲突的键值对通过链表连接，但随着数据量增加，冲突加剧，查找效率降低。负载因子衡量冲突程度，负载因子越大，龙语密码源码冲突越严重。为优化性能，Redis 需适时扩容，将新增键值对放入新哈希桶，减少冲突。
扩容发生在 setCommand 部分，其中 dictKeyIndex 获取键值对索引，判断是否需要扩容。_dictExpandIfNeeded 函数执行扩容逻辑，条件包括：不在 rehash 过程中，哈希表初始大小为0时需扩容，或负载因子大于1且允许扩容或负载因子超过阈值。
扩容大小依据当前键值对数量计算，如哈希表长度为4，实际有9个键值对，扩容至（最小的2的n次幂大于9）。子进程存在时，dict_can_resize 为0，反之为1。fork 子进程用于写时复制，确保持久化操作的稳定性。
哈希表缩容由 tryResizeHashTables 判断负载因子是否小于0.1，条件满足则重新调整大小。此操作在数据库定时检查，且无子进程时执行。
rehash 是为解决链式哈希效率问题，通过增加哈希桶数量分散存储，减少冲突。dictRehash 函数完成这一任务，移动键值对至新哈希表，使用位运算优化哈希计算。渐进式 rehash 通过分步操作，减少响应时间，适应不同负载情况。定时任务检测服务器空闲时，进行大步挪动哈希桶。吕梁溯源码印刷
在 rehash 过程中，数据查询首先在原始哈希表进行，若未找到，则在新哈希表中查找。rehash 完成后，哈希表结构调整，原始表指向新表，新表内容返回原始表，实现 rehash 结果的整合。
综上所述，Redis 通过哈希表的扩容、缩容以及 rehash 动态调整哈希桶大小，优化查找效率，确保数据存储与检索的高效性。这不仅提高了 Redis 的性能，也为复杂数据存储与管理提供了有力支持。
redis7.0源码阅读：Redis中的IO多线程（线程池）
Redis服务端处理客户端请求时，采用单线程模型执行逻辑操作，然而读取和写入数据的操作则可在IO多线程模型中进行。在Redis中，命令执行发生在单线程环境中，而数据的读取与写入则通过线程池进行。一个命令从客户端接收，解码成具体命令，根据该命令生成结果后编码并回传至客户端。 Redis配置文件redis.conf中可设置开启IO多线程。通过设置`io-threads-do-reads yes`开启多线程，同时配置`io-threads 2`来创建两个线程，其中一个是主线程，另一个为IO线程。在网络处理文件networking.c中，`stopThreadedIOIfNeeded`函数会判断当前需要执行的命令数是否超过线程数，若少于线程数，则不开启多线程模式，便于调试。 要进入IO多线程模式，运行redis-server命令，然后在调试界面设置断点在networking.c的`readQueryFromClient`函数中。使用redis-cli输入命令时，可以观察到两个线程在运行，一个为主线程，另一个为IO线程。 相关视频推荐帮助理解线程池在Redis中的应用，包括手写线程池及线程池在后端开发中的实际应用。学习资源包括C/C++ Linux服务器开发、后台架构师技术等领域，需要相关资料可加入交流群获取免费分享。 在Redis中，IO线程池实现中，主要包括以下步骤：读取任务的处理通过`postponeClientRead`函数，判断是否启用IO多线程模式，将任务加入到待执行任务队列。
主线程执行`postponeClientRead`函数，将待读客户端任务加入到读取任务队列。在多线程模式下，任务被添加至队列中，由IO线程后续执行。
多线程读取IO任务`handleClientsWithPendingReadsUsingThreads`通过解析协议进行数据读取，与写入任务的多线程处理机制相似。
多线程写入IO任务`handleClientsWithPendingWritesUsingThreads`包括判断是否需要启动IO多线程、负载均衡分配任务到不同IO线程、启动IO子线程执行写入操作、等待IO线程完成写入任务等步骤。负载均衡通过将任务队列中的任务均匀分配至不同的线程消费队列中，实现无锁化操作。
线程调度部分包含开启和关闭IO线程的功能。在`startThreadedIO`中，每个IO线程持有锁，若主线程释放锁，线程开始工作，IO线程标识设置为活跃状态。而在`stopThreadedIO`中，若主线程获取锁，则IO线程等待并停止，IO线程标识设置为非活跃状态。[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主从复制机制中的核心组件之一——复制积压缓冲区（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源码学习-ziplist篇
Redis源码学习-ziplist篇
ziplist是Redis中一种高效压缩的链表结构，用于存储字符串或整数。它并非传统的链表，而是连续内存块组成，通过移动地址偏移量实现next和last操作，内存利用率高但复杂性较大。 ziplist的实现独特，没有明确的struct，仅通过首地址获取其信息。结构包含header、entrys和end三部分。header部分记录首尾地址，entrys中每个entry有entry-header、entry-encoding和entry-data，prevlength记录上一个节点长度，entry-encoding用于区分整数和字符串，entry-data存储实际内容。对于长度超过的字符串，会进行压缩编码。 ziplist创建简单，使用zmalloc分配内存。insert和delete操作可能引发连锁更新，当新节点插入或原有节点删除时，需要调整相邻节点的prevlength，最坏情况下时间复杂度为O(n^2)。find函数则直接遍历，通过skip参数优化查找性能，特别是在上层容器如hash结构中。 总结来说，ziplist通过连续内存优化内存使用，但其维护复杂性源于插入和删除操作时的连锁更新，find函数利用skip优化查找性能。
