大家好，我是今天的讲师，今天咱们聊聊 Redis 的内存分配器，特别是大名鼎鼎的 jemalloc。这玩意儿可不是个简单的角色，它在 Redis 的性能和内存效率之间玩了个漂亮的平衡木。 一、Redis 的内存分配：不只是 malloc 那么简单 首先，咱们得明白，Redis 存储的是各种各样的数据，从简单的字符串到复杂的数据结构，这些数据都得在内存里安家。内存的分配和管理，直接影响 Redis 的性能和稳定性。 最基础的内存分配当然是 C 语言自带的 malloc 和 free。但是，直接用 malloc 有几个问题： 碎片化： 频繁地分配和释放小块内存，容易产生内存碎片，导致可用内存不连续，降低内存利用率。 性能开销： malloc 通常是通用的内存分配器，为了适应各种场景，它的实现比较复杂，性能上可能不是最优。 缺乏监控： 难以监控内存的使用情况，定位内存泄漏等问题。 所以，Redis 并没有直接依赖系统的 malloc，而是可以选择不同的内存分配器，其中 jemalloc 就是一个非常受欢迎的选择。 二、jemalloc：Facebook 出品的内存分配神器 jemalloc …
Redis 命令处理流程：从客户端请求到结果返回的全链路
好的，开始吧！ 各位观众，晚上好！今天咱们来聊聊 Redis 的命令处理流程，保证让大家听完之后，下次面试再被问到这个问题，能直接把面试官侃晕，而不是自己晕倒。 咱们这次的目标是，从客户端一个简单的 GET mykey 命令开始，一直跟踪到 Redis 服务器处理完，然后把结果返回给客户端的全过程。别怕，咱们尽量用大白话，多敲代码，少说理论。 第一幕：客户端的呼唤 (Client Request) 首先，客户端（比如你的 Java 程序、Python 脚本、甚至只是 Redis CLI）想从 Redis 拿点东西，它会构建一个符合 Redis 协议（RESP）的命令。RESP 协议是一种文本协议，简单易懂。 例如，GET mykey 这个命令，会被编码成如下的 RESP 字符串： *2rn$3rnGETrn$5rnmykeyrn 是不是觉得有点像古代的电报码？别慌，咱们来解读一下： *2rn: 表示这是一个包含两个元素的数组。 $3rn: 表示接下来的字符串长度为 3。 GETrn: 实际的命令字符串。 $5rn: 表示接下来的字符串长度为 5。 mykeyrn: 实际的键名字符串。 …
Redis 定时事件与事件循环：Reactor 模式与单线程模型
各位听众，早上好/下午好/晚上好！ 今天咱们来聊聊 Redis 的定时事件和事件循环，这俩货可是 Redis 这台高性能跑车引擎盖下的关键组件。咱们会深入到 Reactor 模式和单线程模型，保证让大家听得懂，记得住，还能用得上。放心，没有教科书式的生硬，只有接地气的解读和实战代码。 开场白：Redis，快男背后的秘密 Redis 为什么这么快？除了内存数据库这个先天优势，它的事件驱动机制和单线程模型功不可没。想象一下，你在 Redis 服务器面前，敲入各种命令，比如 GET mykey, SET mykey myvalue, EXPIRE mykey 60。这些命令，就像一个个的“事件”，需要 Redis 来处理。而 Redis 就像一个超级勤劳的管家，在“事件循环”中不停地转圈，处理这些事件，同时还要兼顾定时任务，比如过期 key 的删除。 第一部分：事件循环，管家的日常 Redis 的事件循环，说白了，就是一个永不停歇的 while 循环。这个循环主要干三件事： 监听文件描述符（File Descriptor，FD）： 啥是 FD？你可以把它理解为操作系统给你的一个“文件句柄”， …
Redis 延迟删除（Lazy Free）：异步释放大键值内存的策略
好的，咱们这就开始！ 各位朋友，大家好！今天咱们聊聊Redis里一个挺有意思的特性，叫做“延迟删除”（Lazy Free）。这玩意儿听起来好像是说Redis偷懒，其实不然，它可是解决大键值删除时性能瓶颈的一大利器。想象一下，你家Redis里有个巨无霸键，几GB那种，你一DEL，服务器原地爆炸，卡死几秒甚至更久，这谁顶得住？所以，Lazy Free应运而生，它让Redis删除这些大块头的时候，不用一次性清理干净，而是悄悄地放到后台慢慢处理，保证你的Redis服务丝滑流畅。 一、啥是延迟删除？为啥需要它？ 想象一下，你是个餐厅老板，突然来了个客人，点了一桌满汉全席。客人吃完拍拍屁股走了，留下你一个人面对堆积如山的碗筷。如果你必须一个人立刻把所有碗筷都洗干净，其他客人来了也得等着，那你的餐厅估计就得关门大吉了。 Redis也一样。如果一个键值对特别大，比如几百兆甚至几个G，当你执行DEL命令的时候，Redis主线程就得停下来，吭哧吭哧地释放内存。这个过程可能会持续几秒甚至更长，直接导致Redis阻塞，无法处理其他请求。这对于高并发的场景来说，简直是灾难。 延迟删除就是为了解决这个问题而生的。 …
Redis 内存碎片化：产生原因、检测与整理优化
各位好，今天咱们来聊聊 Redis 的内存碎片化，这玩意儿就像你家里的抽屉，东西放久了，乱七八糟，空间利用率直线下降。Redis 也一样，用的时间长了，内存也会变得支离破碎，影响性能。别怕，今天咱们就来把这个“抽屉”好好整理整理。 一、啥是内存碎片化？你家抽屉乱了，就是这玩意儿！ 想象一下，你往 Redis 里塞数据，就像往抽屉里放东西。刚开始，抽屉空空的，放啥都方便，一块连续的空间给你放个“衣服”，再放个“裤子”。但当你删除一些数据（比如“旧袜子”），就会留下一些空隙。这些空隙可能太小，放不下新的完整的数据（比如“新鞋”），这就造成了内存碎片。 简单来说，内存碎片就是： 外部碎片： 很多小块的空闲内存，加起来够用，但因为不连续，没法分配给需要大块连续内存的请求。就像你抽屉里有很多小空隙，但放不下一双鞋。 内部碎片： 分配给你的内存块，你实际上用不了那么多，浪费了。就像你抽屉里有个专门放鞋的格子，你只放了双袜子，剩下的空间就浪费了。 在 Redis 中，我们主要关注的是外部碎片，因为它对性能影响更大。 二、为啥会有碎片？Redis 也没闲着啊！ Redis 用的是动态内存分配，也就是需 …
Redis `robj` (Redis Object)：统一对象结构与引用计数
各位观众，晚上好！欢迎来到今天的“Redis探秘之对象戏法”讲座。今天咱们要聊的是Redis世界里的一个关键角色——robj，也就是Redis Object。别看它名字平平无奇，它可是Redis能玩转各种数据类型的幕后英雄，同时也是内存管理大师。 咱们先来想个问题：Redis为啥能存字符串、列表、集合、哈希表等等各种类型的数据？难道它内部针对每种类型都实现一套存储和操作逻辑？那也太累了吧！答案当然是No！Redis聪明的地方在于，它使用robj这个统一的对象结构，把各种类型的数据都包装起来，这样就可以用一套通用的机制来管理它们。 1. robj：万物皆对象 robj的定义在redis.h文件中，咱们先来看看它的庐山真面目（简化版）： typedef struct redisObject { unsigned type:4; // 对象类型 unsigned encoding:4; // 对象编码 unsigned lru:REDIS_LRU_BITS; // LRU 时间（用于内存淘汰） int refcount; // 引用计数 void *ptr; // 指向底层数据结构的指针 } …
Redis 对象系统：类型、编码与 LRU 计数器详解
好的，没问题！ 各位观众老爷们，今天咱们来聊聊Redis的“对象系统”，听起来是不是有点高大上？其实一点都不难，说白了，就是Redis怎么管理它里面的数据，以及怎么省着点用内存。 Redis作为一个内存数据库，寸土寸金，每一块内存都要精打细算。所以，它搞了一套“对象系统”，就像一个精明的管家，把各种数据都打理得井井有条。 对象系统是什么？ 简单来说，Redis里存储的任何东西，都不是直接存的，而是封装成了一个redisObject结构体。这个结构体就像一个“百宝箱”，里面装着真实的数据，还记录着数据的类型、编码方式，以及一些其他的元数据。 typedef struct redisObject { unsigned type:4; // 对象类型 (5种) unsigned encoding:4; // 对象编码 (8种) unsigned lru:LRU_BITS; // LRU时间 (用于淘汰) int refcount; // 引用计数 void *ptr; // 指向底层数据结构的指针 } robj; 看到没？这个redisObject就是核心。咱们一点点来解剖它： type ( …
Redis `hashtable` 内部：字典的哈希冲突解决与渐进式 Rehash
好的，直接开始！ 各位观众，欢迎来到“Redis Hash Table的秘密花园”讲座！今天咱们就来扒一扒Redis hashtable的内裤…啊不，是内部实现，重点聊聊哈希冲突和渐进式Rehash这两个有趣的话题。 一、字典的本质：Key-Value存储的基石 Redis字典，也就是dict类型，是Redis最核心的数据结构之一。它干的事情很简单：存储键值对（key-value pairs）。但它背后的实现可不简单，因为它需要足够快、足够稳，才能撑起Redis高性能的半边天。 Redis字典的底层实现，核心就是一个hashtable（哈希表）。 想象一下，你有一个巨大的数组，每个数组元素可以存放一个键值对。 但问题来了：你如何快速地找到某个key对应的value呢？ 难道要一个一个遍历数组？ 那效率也太低了！ 这时候，哈希函数就登场了！ 它的作用就是：将key转换成一个整数（哈希值），这个哈希值就对应着数组的下标。这样，我们就可以直接通过哈希值找到对应的数组元素，也就是找到了对应的键值对。 用代码来表示一下，大概是这个样子： typedef struct dictEntry { vo …
Redis `skiplist` 跳跃表机制：有序集合 ZSet 的高效实现
好的，各位观众，欢迎来到今天的Redis专场！今天我们要聊的，是Redis里一个非常重要的底层数据结构——跳跃表（skiplist）。各位可能要问了，跳跃表是啥玩意？听起来像是一种新的滑雪方式？ 别急，其实跳跃表跟滑雪没啥关系，但它确实能让数据检索的速度“飞起来”。它在Redis中扮演着关键角色，特别是作为有序集合（ZSet）的底层实现之一。今天，我们就来扒一扒这个“跳跃高手”的底裤，看看它到底是怎么让Redis如此高效的。 一、为啥需要跳跃表？ 在深入了解跳跃表之前，我们先来思考一个问题：有序集合用什么数据结构来实现最好？ 数组？ 插入、删除元素太慢，需要移动大量元素，复杂度是O(n)。 链表？ 查找元素只能遍历，复杂度也是O(n)。即使是有序链表，也只能一个个地比较。 平衡树 (比如红黑树)? 查找、插入、删除的复杂度都是O(log n)，效率很高。Redis早期确实考虑过用平衡树实现ZSet，但最终选择了跳跃表，这是为什么呢？ 原因如下： 实现难度： 跳跃表比平衡树更容易实现和维护。平衡树的代码通常比较复杂，容易出错。 内存占用： 跳跃表的内存占用通常比平衡树更小。特别是当数据量 …
Redis `ziplist` 压缩列表原理：小数据集合的内存极致优化
各位观众，各位朋友，欢迎来到今天的“Redis数据结构奇妙夜”！今天我们要聊的是Redis里一个非常低调但又极其重要的角色——ziplist，也就是压缩列表。 别看它名字里带“压缩”两个字就觉得它很复杂，其实啊，它就是Redis为了节省内存，对小数据集合进行极致优化的一种数据结构。简单来说，如果你的列表或者哈希只存几个小猫小狗，Redis就懒得给你动用重量级的链表或者哈希表了，直接用ziplist伺候着，省钱！ ziplist：小身材，大智慧 想象一下，你有一个小杂物间，里面就放了几件东西。如果专门为了这几件东西搭个钢筋混凝土的房间，是不是有点浪费？ziplist就相当于这个杂物间，它把数据紧凑地排列在一起，不搞多余的指针，能省一点是一点。 ziplist的结构 ziplist本质上就是一段连续的内存空间，里面存储着一系列的节点（entry）。它的结构可以用下图来简单概括（别嫌弃，这可是纯文字版架构图）： <zlbytes> <zltail> <zllen> <entry1> <entry2> … <entryN&g …