各位观众，欢迎来到今天的“Redis HyperLogLog：基数统计的奇妙冒险”讲座！ 今天，我们来聊聊Redis里面一个非常酷，但又有点神秘的数据结构——HyperLogLog。 它能帮你解决一个很常见的问题：统计海量数据的基数(distinct count)。 简单来说，就是统计一堆数据里面有多少个不重复的值。 场景回放：你需要统计什么？ 想象一下这些场景： 网站每天有多少独立访客(UV)？ App每天有多少独立用户？ 搜索关键词有多少个不同的用户搜索？ 一个大型电商网站，每天有多少不同的商品被浏览？ 如果你用传统的方式，比如集合(Set)来存储所有访问过的用户ID，那数据量一大，内存就爆炸了。 比如，你有个网站，每天有几百万用户访问，每个用户ID是64位的整数，那Set就需要占用几百MB甚至几GB的内存。 这还没算其他的开销！ 救星登场：HyperLogLog HyperLogLog就是来拯救你的！它是一种概率数据结构，用极小的内存空间就能近似地统计出海量数据的基数。 它牺牲了一点精度，换来了巨大的内存节省。 精度损失通常在百分之几以内，但内存占用却可以减少到原来的几十分之一甚 …
Redis `Stream` 数据结构：Kafka 消息队列在 Redis 中的实现原理
好的，没问题。 各位观众，各位朋友，大家好！今天咱们来聊聊Redis里的一个“狠角色”——Stream，以及它如何摇身一变，模仿起了Kafka老大哥的消息队列。这可不是简单的山寨，而是Redis在某些场景下，对Kafka的一种轻量级替代方案。 准备好了吗？咱们这就开始“探险”！ 第一幕：Stream 是个啥？ 首先，咱们得搞清楚Stream是个什么玩意儿。简单来说，Stream是Redis 5.0版本引入的一种新的数据结构，它是一个持久化的、可追加的消息队列。你可以把它想象成一个日志文件，消息就像一行行记录，不断地往里追加。 但Stream又不仅仅是个简单的队列，它还具备以下这些特性： 持久化存储： 消息会持久化到磁盘，不用担心Redis挂掉数据丢失。 消息ID： 每条消息都有一个唯一ID，方便追踪和管理。 消费者组（Consumer Group）： 允许多个消费者组成一个组，共同消费Stream里的消息，实现负载均衡。 消息确认机制： 消费者可以确认消息已处理，避免重复消费。 阻塞读取： 消费者可以阻塞等待新消息，而不用轮询。 这些特性是不是有点眼熟？没错，它们和Kafka非常相似。 …
Redis 持久化 AOF 原理：命令追加、重写与混合模式
好的，没问题，直接开始！ 各位老铁，大家好！今天咱们来聊聊 Redis 的持久化，特别是 AOF (Append Only File) 这种姿势。这玩意儿啊，说白了就是把咱们对 Redis 的所有操作都记下来，像个小本本一样，万一 Redis 宕机了，还能照着小本本重放一遍，数据就回来啦！ 一、AOF：一个尽职尽责的小本本 AOF 的核心思想很简单：每次执行完写操作（SET、HSET、DEL 等等），就把这条命令以追加的方式写到 AOF 文件里。这样，即使 Redis 挂了，重启后也能通过重新执行 AOF 文件里的命令，恢复到之前的状态。 命令追加 (Command Append) AOF 的第一步，就是把命令追加到 AOF 文件。这个过程就像咱们写日记，每天都往后加，永远不回头改。 Redis 内部的实现大概是这样： // 假设我们执行了 SET mykey myvalue 命令 char *command = “SET mykey myvalue”; // 把命令格式化成 Redis 的协议格式 char *redis_protocol = redisFormatCommand(c …
Redis 持久化 RDB 原理：Copy-on-Write 与数据快照
各位朋友，大家好！今天咱们来聊聊 Redis 持久化中的RDB，也就是Redis Database，听起来有点像“数据库”，但它更像是Redis数据的“快照摄影师”。 RDB：数据的“灵魂摄影师” 想象一下，你养了一群小仓鼠（就是Redis里存的数据），每天活蹦乱跳，搞得你头晕眼花。突然有一天，你要出门旅行，为了防止小仓鼠们在你不在的时候饿死或者把笼子拆了，你得把它们的状态保存下来，等回来的时候再恢复。RDB就是干这个活的，它定期给Redis的数据拍一张“快照”，把那一刻的状态保存到磁盘上。 RDB的优势和缺点 RDB的优势很明显： 恢复速度快: 就像你旅行回来，直接把“快照”加载回来，小仓鼠们瞬间恢复到旅行前的状态，启动速度非常快。 占用空间小: “快照”是压缩过的，占用的磁盘空间相对较小，方便备份和迁移。 性能影响小: RDB生成快照的过程，主要依赖于操作系统的Copy-on-Write机制，对主进程的影响非常小，堪称“无痛备份”。 但是，RDB也有缺点： 数据丢失风险: 如果Redis崩溃在两次快照之间，那么这段时间内的数据就会丢失。就像摄影师还没来得及拍照，小仓鼠们就发生意外了 …
Redis `jemalloc` 内存分配器：性能与内存效率的平衡
大家好，我是今天的讲师，今天咱们聊聊 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; // 指向底层数据结构的指针 } …