1.redis7.0源码阅读：Redis中的源码IO多线程（线程池）
2.Redis源码阅读（1）——zmalloc
3.Redis 又双叒叕改开源协议了，微软提前推出高性能替代方案 Garnet
4.Redis 修改radix tree 源码解析
5.Spring Data Redis切换底层Jedis 和 Lettuce实现
6.Scrapy—redis动态变化redis_key
redis7.0源码阅读：Redis中的IO多线程（线程池）
Redis服务端处理客户端请求时，采用单线程模型执行逻辑操作，源码然而读取和写入数据的修改操作则可在IO多线程模型中进行。在Redis中，源码命令执行发生在单线程环境中，修改看源码学js而数据的源码读取与写入则通过线程池进行。一个命令从客户端接收，修改解码成具体命令，源码根据该命令生成结果后编码并回传至客户端。修改 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源码阅读（1）——zmalloc
zmalloc是一个简化内存分配的库，包含以下API函数：zmalloc
zcalloc
zrealloc
zfree
zstrdup
zmalloc_used_memory
zmalloc_set_oom_handler
zmalloc_get_rss
zmalloc_get_allocator_info
zmalloc_get_private_dirty
zmalloc_get_smap_bytes_by_field
zmalloc_get_memory_size
zlibc_free
其中，zmalloc用于分配内存，zcalloc在分配内存的同时初始化为0，zrealloc用于重新分配内存，zfree用于释放内存，zstrdup用于复制字符串并分配内存，zmalloc_used_memory用于获取已分配内存的大小，zmalloc_set_oom_handler用于设置内存溢出处理器，zmalloc_get_rss用于获取当前进程的内存使用量，zmalloc_get_allocator_info用于获取分配器信息，zmalloc_get_private_dirty用于获取私有脏数据，zmalloc_get_smap_bytes_by_field用于获取指定字段的内存使用量，zmalloc_get_memory_size用于获取内存大小，zlibc_free用于释放内存。 在zmalloc中，宏函数update_zmalloc_stat_alloc用于更新used_memory的值。这个宏函数中的if语句用于补齐分配的内存字节数到sizeof(long)，但是我不太理解5.0源码中为什么atomicIncr使用的是__n而不是直接对_n进行操作。测试发现，used_memory的值并未对齐到8，那么if语句的存在意义何在呢？ 同样地，update_zmalloc_stat_free宏函数用于更新已释放内存的统计信息。与update_zmalloc_stat_alloc相比，虽然malloc_usable_size已经返回精确的字节数，但update_zmalloc_stat_alloc为何不直接使用atomicIncr更新used_memory呢？在Unstable分支中，已有开发者对此进行了优化。Redis 又双叒叕改开源协议了，微软提前推出高性能替代方案 Garnet
Redis 商业公司 CEO Rowan Trollope 在官方博客宣布了一个重大变化：Redis 核心软件将从 BSD 3-Clause 许可证过渡至 RSALv2 或 SSPLv1 双重许可证模式，从 Redis v7.4 版本开始，覆盖所有后续版本。新的许可证模式为 Redis 带来全新的使用框架，同时可能影响开源生态。
BSD 3-Clause 许可证，是一种宽松的开源许可证，允许源代码的自由使用、修改和分发。然而，RSALv2 和 SSPLv1 却并未获得 OSI 的心似源码正式认可。这种改变意味着 Redis 已不再是标准的开源软件。官网更新为“Redis 是源可用软件”。这并非 Redis 首次调整许可证策略。早在 年，Redis 已将部分模块许可证改为结合 Apache v2.0 和 Commons Clause 的许可证，引发社区争议。 年，Redis Labs 回应社区反馈，修改为 RSAL，允许自由使用模块，但要求基于这些模块的产品或服务获得商业许可证。 年 月，Redis 再度调整，将一些模块改为 RSAL 和商业许可证并行，以应对云服务提供商使用开源软件的商业模式问题。
此次修改许可证的目的是回应云厂商的商业模式，确保他们为 Redis 的开发提供支持。Redis 核心项目依然保持宽松的 BSD 3-Clause 许可证，这稳定了厂商的信心。CEO 表示，此变更将使 Redis 保持领先的数据模型、处理引擎和开发者功能。然而，许可证的改变可能对使用新版本 Redis 源代码的“竞争性产品”产生影响。
与此同时，微软推出基于兼容协议的高性能 Redis 替代方案 Garnet。Garnet 是一个高性能缓存存储系统，针对现代硬件进行了优化，能够更好地利用处理器缓存和网络特性，提供卓越的吞吐量和延迟性能。此外，国内公司如阿里云的 Tair 和 的 Pika，也开发了与 Redis 相似功能的替代品，提供了更灵活的许可证选择。
Hacker News 社区对这些变化进行了讨论，包括许可证的灵活性与商业化的平衡问题。讨论涉及开源软件的商业化途径，如“open core”模式，但同时也关注许可证变更对开源生态和开发者的影响。面对开源与商业化之间的挑战，寻求一种既符合宽松开源许可证，又能适用于复杂程序的模式，成为当前软件行业关注的焦点。
Redis radix tree 源码解析
Redis 实现了不定长压缩前缀的 radix tree，用于集群模式下存储 slot 对应的所有 key 信息。本文解析在 Redis 中实现 radix tree 的核心内容。
核心数据结构的定义如下：
每个节点结构体 (raxNode) 包含了指向子节点的指针、当前节点的 key 的长度、以及是softnms源码py否为叶子节点的标记。
以下是插入流程示例：
场景一：仅插入 "abcd"。此节点为叶子节点，使用压缩前缀。
场景二：在 "abcd" 之后插入 "abcdef"。从 "abcd" 的父节点遍历至压缩前缀，找到 "abcd" 空子节点，插入 "ef" 并标记为叶子节点。
场景三：在 "abcd" 之后插入 "ab"。ab 为 "abcd" 的前缀，插入 "ab" 为子节点，并标记为叶子节点。同时保留 "abcd" 的前缀结构。
场景四：在 "abcd" 之后插入 "abABC"。ab 为前缀，创建 "ab" 和 "ABC" 分别为子节点，保持压缩前缀结构。
删除流程则相对简单，找到指定 key 的叶子节点后，向上遍历并删除非叶子节点。若删除后父节点非压缩且大小大于1，则需处理合并问题，以优化树的高度。
合并的条件涉及：删除节点后，检查父节点是否仍为非压缩节点且包含多个子节点，以此决定是否进行合并操作。
结束语：云数据库 Redis 版提供了稳定可靠、性能卓越、可弹性伸缩的数据库服务，基于飞天分布式系统和全SSD盘高性能存储，支持主备版和集群版高可用架构。提供全面的容灾切换、故障迁移、在线扩容、性能优化的数据库解决方案，欢迎使用。
Spring Data Redis切换底层Jedis 和 Lettuce实现
Spring Data Redis提供了对Redis操作的高级抽象，支持Jedis和Lettuce两种连接方式。通过简单的配置即可连接Redis并切换连接方式。具体步骤如下：
引入Redis依赖使用Spring Boot的spring-boot-starter-data-redis。
自定义配置类设置Key和Value的序列化。
修改Redis连接配置，可自由切换单节点、哨兵模式和集群模式。
注入RedisTemplate后，即可操作Redis。RedisTemplate具有两个泛型。
源码分析部分，从Redis自动配置类RedisAutoConfiguration开始，它引入了两个连接Redis配置类：LettuceConnectionConfiguration和JedisConnectionConfiguration。期货大盘源码这两个配置类通过条件注解控制是否生效，如果生效，则会使用相应的依赖生成RedisConnectionFactory的Bean。引入Lettuce依赖时，能通过io.lettuce.core.RedisClient找到类，说明默认使用Lettuce。若无Jedis相关依赖，则当前配置类无效。
切换连接方式至Jedis有两种方式：利用@ConditionalOnClass注解排除Lettuce依赖，或利用@ConditionalOnProperty注解修改配置文件中的spring.redis.client-type为jedis。第一种方式优点在于不加载多余的依赖包，推荐使用。第二种方式则可通过配置文件自由切换连接方式。
本文由OpenWrite平台发布。请按照上述步骤进行Spring Data Redis的使用和连接方式切换。
Scrapy—redis动态变化redis_key
对于有一定Scrapy经验的人来说，scrapy_redis组件常用于分布式开发和部署。它具有分布式爬取、分布式数据处理、Scrapy即插即用组件等优势，支持多个spider工程共享redis的requests队列，以及通过启动多个处理程序共享item队列进行数据持久化。
然而，某些业务场景下，redis_key非动态性和不符合业务需求的url拼接问题使得scrapy_redis使用并不顺手，甚至无法适应业务需求。为解决这一问题，通过修改源码的方式使得redis_key动态变化，并实现url自由拼接，成为了一种有效的解决策略。
在具体实现中，我们需要关注框架的make_request_from_data方法，这一方法主要用于url拼接和获取任务所需参数，是实现动态变化的关键。接下来的重点在于修改next_requests方法，这是对动态redis_key适应的关键修改步骤。这一部分的修改需要仔细阅读代码注释，确保理解其逻辑，耐心进行调整。
start_requests方法的修改则主要涉及到初始化数据库链接，确保整体流程的顺畅进行。最后，将修改后的代码打包为docker镜像部署到k8s上，实现高效稳定的服务。
对于在这一过程中遇到困难的朋友，可以加入交流群进行讨论，共同解决问题。同时，希望大家能为这一创新实践点赞，给予支持和鼓励，推动更多开发者在Scrapy框架上进行更深入的探索和优化。
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 的性能，也为复杂数据存储与管理提供了有力支持。
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
