1.redis6Դ?码分????
2.读懂Redis：从源码分析其跳表实现
3.Redis 源码分析字典（dict）
4.Redis源码从哪里读起？
5.Redis Client-side Caching实现剖析与源码解读
6.编译实战 | 手摸手教你在Windows环境下运行Redis6.x
redis6Դ?????
深入分析redis之listpack，取代ziplist？ 本文参考源码版本:redis6.2 从ziplist到quicklist，码分再到listpack结构，码分可以看出，码分redis设计这些数据结构的码分初衷都是为了高效使用内存。 ziplist设计出的码分棋盘源码开发紧凑型数据块可以有效利用内存，但在更新上，码分由于每一个entry都保留了前一个entry的码分prevlen长度，因此在插入或者更新时可能会出现连锁更新，码分这是码分一个影响效率的大问题。 接着设计出「链表+ziplist」组成的码分quicklist结构来避免单个ziplist过大，可以有效降低连锁更新的码分影响面。但quicklist本质上不能完全避免连锁更新问题。码分 因此，码分设计出与ziplist完全不同的码分内存紧凑型结构listpack，继续往下看～一、listpack是什么？
listpack也叫紧凑列表，它的特点就是用一块连续的内存空间来紧凑地保存数据，同时为了节省内存空间，listpack列表项使用了多种编码方式，来表示不同长度的数据，这些数据包括整数和字符串。 Redis源码对于listpack的解释为A lists of strings serialization format，一个字符串列表的序列化格式，也就是将一个字符串列表进行序列化存储。Redis listpack可用于存储字符串或者整型二、原理分析
1. 结构
listpack由4部分组成：total Bytes、Num Elem、Entry以及End。Entry为listpack中的具体元素，其内容可以为字符串或者整型，每个Entry由3部分组成： 从组成上可以看出，和ziplist列表项类似，listpack列表项也包含了元数据信息和数据本身。不过，为了避免ziplist引起的连锁更新问题，listpack中的每个列表项不再像ziplist列表项那样，保存其前一个列表项的长度，它只会包含三个方面内容，分别是当前元素的编码类型(encoding)、元素数据(data)，以及编码类型和元素数据这两部分的长度(len)。 其中type和tot-len一定有值；有时data可能会缺失，因为对于一些小的元素可以直接将data放在type字段中。 element-tot-len记录了这个Entry的长度(encoding + data)，注意并不包括element-tot-len自身长度，占用的字节数小于等于5。在整型存储中，并不实际存储负数，而是美溯源码燕窝将负数转换为正数进行存储。2. 编码方式
encoding-type是理解数据类型的基础，为了节省内存空间，listpack针对不同的数据做了不同的编码：小的数字：表示7位无符号整型，后7位为数据。
小的字符串：6位字符串长度，后6位为字符串长度，再之后则是字符串内容（0 ~ bytes）。
多字节编码：如果第一个字节的最高2bit被设置为1，采用以下两种编码方式；如果第一个字节的最高4bit被设置为1，将采用以下几种方式编码。
3. listpack避免连锁更新的实现方式
在listpack中，因为每个列表项只记录自己的长度，而不会像ziplist中的列表项那样，会记录前一项的长度。所以，当在listpack中新增或修改元素时，实际上只会涉及每个列表项自己的操作，而不会影响后续列表项的长度变化，这就避免了连锁更新。4. 查询
正向查询通过直接移动到第一个entry列表项开始，反向查询通过element-tot-len的特殊编码方式，从当前列表项起始位置的指针开始，向左逐个字节解析，得到前一项的element-tot-len值，从而得出entry的总长度。三、初始化、增删改操作、遍历操作、读取元素
listpack提供了初始化、增删改操作、遍历操作、读取元素的接口。初始化时，会创建一个空的listpack，分配的大小默认是6个字节，其中4个字节记录listpack的总字节数，2个字节记录元素数量。 增删改操作分别通过插入、删除、替换元素实现。遍历操作通过接口实现，获取每个entry的首地址，读取元素则通过lpGet接口实现。总结
ziplist、quicklist和listpack是redis不断迭代优化的产物。ziplist的不足主要在于查找效率降低，新增或修改数据时内存空间需要重新分配，导致连锁更新问题，快乐红指标源码影响访问性能。quicklist通过链表结构降低内存分配，但增加了内存开销。listpack沿用ziplist紧凑型内存布局，进一步避免连锁更新问题。 可以看出，这些数据结构的设计旨在提高内存使用效率和访问性能，通过不断优化以适应不同场景的需求。读懂Redis：从源码分析其跳表实现
要深入理解Redis中跳表的奥秘，首先，我们从理想化的跳表概念开始。跳表作为一种多层级有序链表，旨在提供高效的有序集合操作，如zrange和zrevrange。它的设计旨在通过空间换时间，以O(log_2 n)的时间复杂度进行查找，但删除和增加操作可能导致结构变动，这在理想情况下需要复杂的重构。
Redis在实践中对跳表进行了优化，以牺牲一定程度的复杂性来节省内存。它限制了跳表的最高层级为，并根据节点数量和字符串长度选择是否使用跳表。Redis的跳表设计重点在于第一个层级的元素，这使得范围查询极其高效，而这是其他数据结构难以比拟的特性。
当添加新元素到zset对象时，会根据特定条件（zset_max_ziplist_entries和zset_max_ziplist_value）决定是否转换为跳表。通过配置Redis的配置文件，用户可以调整这些参数以适应不同的需求。
总的来说，Redis的跳表实现是内存与性能之间的一种平衡，它在有序集合操作中发挥着关键作用，同时为高效查询提供了基础。对于希望系统学习C/C++、Linux系统和深入理解高性能存储的读者，可以关注我们的公众号《Lion 莱恩呀》获取更多技术内容，包括白金学习卡，覆盖基础架构、golang云原生等领域。
Redis 源码分析字典（dict）
Redis 的内部字典世界：从哈希表到高效管理的深度解析
Redis，作为开源的高性能键值存储系统，其内部实现的字典数据结构是其核心组件之一。这个数据结构采用自定义的哈希表——dictEntry，巧妙地存储和管理着键值对。让我们一起深入理解这一强大工具的运作机制。
首先，Redis的字典是基于哈希表的，通过哈希函数将键转换为数组索引，实现高效查找。溯源码燕窝角dictEntry结构巧妙地封装了键（key）、值（value）以及指向下一个节点的指针，构成了数据存储的基本单元。同时，dict包含一系列操作函数，包括哈希计算、键值复制、比较以及销毁操作，这些函数的指针类型（dictType）和实际数据结构共同构建了其高效性能。
在字典的管理中，rehash是一个关键概念，它标志着哈希表的重新分布过程。rehash标志是一个计数器，用于跟踪当前哈希表实例的状态，确保在负载过高时进行扩容。当ht_used[0]非零，且满足特定条件（如元素数量超过初始桶数），服务器会触发resize操作，这通常在serverCron定时任务中进行，以避免磁盘I/O竞争。
rehash过程中，Redis采取渐进式策略，通过dictRehash函数，逐个移动键值对到新哈希表，确保操作的线程安全。为了避免长时间阻塞，这个过程被分散到函数中，并通过serverCron定时任务，以毫秒级的步长进行，确保在无磁盘写操作时进行。
在处理过期键时，dictRehashMilliseconds()函数扮演重要角色，它在rehash时监控时间消耗，确保性能。rehash过程中，dictAdd负责插入新哈希表，而dictFind和dictDelete则需处理ht_table[0]和ht_table[1]的键值对。
Redis的默认哈希算法采用SipHash，保证了数据的分布均匀性。在持久化时，负载因子默认设置为5，而rehash后，数据结构会采用迭代器的形式，分为安全和非安全两种，以满足不同场景的需求。
在实际操作中，如keysCommand，会选择安全模式以避免重复遍历，而在处理大规模数据时，138改单源码如scan命令，可能需要使用非安全模式，但需注意可能带来的问题。
总的来说，Redis的字典数据结构是其高效性能的基石，通过精细的哈希管理、rehash策略以及迭代器设计，确保了在高并发和频繁操作下的稳定性和性能。深入理解这些内部细节，对于优化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 Client-side Caching实现剖析与源码解读
Redis的Client-side Caching是一种通过在客户端存储本地缓存来减轻服务器负载和网络负担的策略。当数据访问频繁且以读取为主时，这种策略能提升性能，减少Redis服务的压力和响应延迟。
在Redis 6.0之前，客户端缓存的一个挑战在于数据更新时如何同步。例如，当user:的username从Alice变更为Bob时，需要确保客户端缓存的更新同步。为解决这个问题，Redis 6引入了key失效主动通知，简化了客户端缓存的实现，并提高其可靠性。
Redis客户端缓存支持两种模式：默认模式和广播模式。默认模式下，服务器会记录每个客户端关注的键，当键被修改时发送失效通知，但会消耗服务器内存；而广播模式则不占用内存，客户端订阅特定前缀以接收通知。
使用OPTIN选项，客户端可以选择性地缓存特定键，减少服务器内存负担和无效消息量。相反，OPTOUT选项将默认缓存键，但允许指定不缓存的键。客户端需要明确指定缓存行为，这可能增加网络交互但减少服务器负载。
在处理连接失效问题时，客户端需确保及时处理失效消息，以避免数据缓存错误。同时，合理配置Redis的内存限制，以防止内存溢出。
最后，源码层面，Redis通过开启或关闭tracking功能来实现Client-side Caching，包括记录读取的键、在命令处理后发送invalidate消息以及根据模式向客户端发送消息。理解这些细节有助于深入理解和优化Redis的缓存策略。
编译实战 | 手摸手教你在Windows环境下运行Redis6.x
哈喽大家好啊，我是没事就愿意瞎捣鼓的Hydra。
不知道有没有小伙伴像我一样，平常开发中用的是windows操作系统，有时候想装点什么软件，一看只支持linux系统，无奈要么启动虚拟机、要么装在云服务器上。
这不前几天又是这样，刚想用一下Redis 6.x版本来尝试一下新特性，打开官网一看，好家伙我直呼内行，果然不支持windows系统：
不过虽然redis的官网上不提供windows版本下载，但是这也难不倒我这个面向百度编程的小能手，一番查找后让我找到了微软在github上维护的几个可以在windows上运行的redis版本：
项目的git地址是/MicrosoftArchive/redis/releases，我翻了一下，微软维护了2.x和3.x的多个windows版本redis，不过比较遗憾，在维护到3.0.正式版本后就放弃了更新。
不过问题不大，眼看微软撂挑子不干了，波兰的热心市民 Tomasz Poradowski 先生这时候站出来，继续开始提供可以在windows上运行的4.x和5.x版本的redis，并且从年到年一干就是5年。
项目git地址是/tporadowski/redis/releases，没错，其实我本地环境运行的redis-5.0.9就是以前从这里下载的，而且绿色版使用起来真的是干净又卫生，所以我强烈建议大家给这位老哥来一个Star支持一下。
不过绕了这么一大圈，我的问题还是没有解决啊，既然没有现成的可以在windows上运行的redis6.x版本，那我们干脆就来自己编译一个吧。
首先介绍一下我们今天要用到的工具Cygwin，先简单看一下它的官网 /，上面很清晰的解释了几个容易引起大家混淆的问题：
先解释了cygwin是什么：
再纠正了大家的常见误区：
其实可以用一句话来概括一下它的功能，cygwin是一个可运行于原生windows系统上的POSIX兼容环境，可以通过重新编译将linux应用移植到windows中。
好了，这样简单了解一下cygwin的功能对我们来说暂时就足够了，下面我们看看如何使用它来编译windows版本redis。
下面我们先进行编译工具Cygwin的下载和安装，在它的官网上就可以直接下载，完成后就可以开始安装了。下面我会贴出一些需要特殊配置的步骤，如果没有特殊说明的话，那么直接痛快的点击下一步就可以了。
网络连接配置这里选择第二项，也就是直接连接，不需要任何代理方式：
在选择下载源这一步，先手动输入User URL，添加阿里云的镜像/cygwin，点击add后再选择我们刚才添加的这个源，然后点击下一步：
接下来选择需要下载安装的组件包，我们只需要下载我们编译相关的模块即可。先通过上面的搜索框进行定位，选择安装Devel模块下面的make、gcc-core，gcc-g++，以及Libs模块下的libgcc1 、libgccpp1，然后点击New这一列的Skip，选择要安装的版本号，全部添加完成后点击下一步：
接下来会自动进行下载上面选择的模块，等待全部下载结束后安装就完成了：
安装完成后，我们运行Cygwin Terminal，通过命令检测可以看到Status为OK，表示cygwin运行正常：
准备好编译工具后，我们接下来先下载redis6.x版本的源码，6.0.的下载地址为：
download.redis.io/relea...
cygwin安装完成后，会在它的安装路径的home目录下，创建一个以你登录系统的用户名来命名的目录，我们把下载完成后的压缩包放到这个cygwin\home\${ user}目录下，在cygwin命令行中先执行解压命令：
使用下面的命令先切换到解压后的根目录，然后执行编译和安装：
点击回车，然后就开始漫长的等待吧，不得不说编译和安装的过程真的很慢，我这大概花了分钟才全部完成。
不出意外的最后果然出现了意外，报了两个Error，不过貌似没有什么太大影响，切换到src目录下，就已经可以看到编译完成后已经生成了6个exe可执行文件了：
但是如果这个时候双击redis-server.exe尝试进行启动的话，那么就会报错提示缺少dll动态链接库：
我们可以在cygwin的bin目录下找到这个文件，为了方便，把可执行文件、动态链接库文件、redis配置文件拷贝到一个单独的目录下再次尝试启动：
这次能够正常启动成功，我们再使用客户端连接工具连接并进行测试，终于，6.0.版本的redis可以在windows环境下正常运行了。
忙活一大顿总算成功了，我们也终于可以在windows上体验redis6.x版本了，不过这里还是给小伙伴们提个醒，这样编译的redis我们平常自己在学习中体验一下就可以了，尽量不要用在生产上。
因为cygwin编译后的程序，相当于在windows系统上模拟实现了POSIX兼容层，应用程序在底层多了一层函数调用，因此效率比运行在linux系统的原生应用低了很多。因此，这样在windows上运行的redis，无疑会损失掉它引以为傲的高性能这一优势。
秉持着好东西就要分享的原则，我也已经把编译好的windows版redis6.0.上传到了网盘，有需要的小伙伴们可以从下面获取下载方式。
那么，这次的分享就到这里，我是Hydra，下期见。
作者简介，码农参上，一个热爱分享的公众号，有趣、深入、直接，与你聊聊技术。个人微信DrHydra9，欢迎添加好友，进一步交流。
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的工作原理，提升编程效率和设计决策能力。
