1. 这不是“又一篇Redis入门”而是打开存储黑箱的第一把钥匙你点开这个标题大概率不是想看“Redis有5种数据类型”这种教科书式罗列。你真正想搞清楚的是为什么一个字符串SET user:1001 zhangsan存进去内存里不是简单地放一串ASCII为什么HSET user:1001 name zhangsan age 28能比MySQL快两个数量级为什么LPUSH logs 2024-06-12T10:30:00插入10万条日志内存占用却远低于预期更关键的是——当面试官突然问“ZSET底层用什么实现跳表和红黑树怎么选”时你脑子里浮现的不该是背诵的答案而是一幅清晰的内存布局图。这就是本篇要干的事不讲命令怎么用不堆API文档只带你亲手拆开Redis的内存外壳看清redisObject、sds、dict、ziplist、quicklist、skiplist这些结构在物理内存里是怎么咬合、怎么伸缩、怎么妥协的。我做Redis中间件运维和性能调优七年经手过单集群20TB缓存、QPS峰值800万的电商大促场景踩过的坑全来自对底层机制的误判——比如以为HGETALL只是“取全部字段”结果发现它触发了整张哈希表的遍历内存拷贝比如以为LRU淘汰是精确到每个key的计时器结果发现它用的是近似随机采样。这些认知偏差全源于没真正看过src/server.h里那个robj结构体定义没亲手用DEBUG OBJECT key验证过编码转换时机没在gdb里单步跟踪过rdbSaveListObject的序列化路径。所以这篇内容适合三类人正在准备中高级后端面试的开发者尤其关注Redis原理题、需要做缓存容量预估和淘汰策略调优的SRE、以及所有被“Redis为什么快”这个问题困扰超过3次的技术人。我们不从官网文档抄概念而是从redis-cli敲出的第一行INFO memory开始一层层往下挖。2. 核心设计哲学一切为了内存效率与访问速度的极致平衡2.1 Redis不是数据库是内存数据结构服务器——这句话到底在说什么很多人把Redis当成“内存版MySQL”这是根本性误解。MySQL的核心目标是持久化可靠性和复杂查询能力为此可以牺牲写入延迟WAL日志刷盘、接受B树索引的磁盘IO放大、容忍事务锁带来的并发阻塞。而Redis的设计原点只有一个在单线程模型下把内存带宽和CPU缓存利用率榨到极限。这意味着所有决策都围绕三个铁律展开零拷贝优先任何数据操作只要可能就避免内存复制。比如GET key返回值不是从内部缓冲区memcpy到socket发送缓冲区而是直接让内核sendfile或splice零拷贝发送LRANGE list 0 -1遍历列表不是把每个元素malloc新内存再拼接而是直接复用原有ziplist或quicklist节点的指针。空间换时间的精妙尺度Redis大量使用“编码切换”encoding switching机制。同一个逻辑数据类型在不同数据规模下底层物理结构完全不同。比如一个空Hash初始用HT哈希表太重就用ZIPLIST压缩列表当字段数超过512或单个value长度超64字节才升级为HT。这不是偷懒而是经过严格压测的权衡ZIPLIST内存碎片率低、CPU缓存行友好连续内存但O(n)查找HT是O(1)平均查找但每个entry要额外8字节指针哈希桶数组开销。Redis的hash-max-ziplist-entries参数就是这个平衡点的刻度尺。单线程不是限制是确定性保障Redis用单线程处理所有客户端请求看似反直觉实则是为消除锁竞争带来的不可预测延迟。在多核CPU上加锁/解锁、缓存行失效false sharing、上下文切换的开销往往比纯计算还高。Redis把所有操作变成原子性的内存读写配合epoll/kqueue事件驱动让99%的请求延迟稳定在100微秒内。你看redis-benchmark跑出来的P99延迟曲线那条平直的尾巴就是单线程内存操作的馈赠。提示理解这三点才能看懂后续所有结构设计。比如为什么String类型有int、embstr、raw三种编码因为小整数直接存robj-ptr里int编码避免指针跳转短字符串用embstr嵌入式SDS保证robj和sdshdr内存连续一次CPU缓存行加载完成长字符串才用raw独立SDS牺牲一点局部性换取动态扩容能力。全是为第一条“零拷贝”和第二条“空间换时间”服务。2.2 从redisObject开始所有数据类型的统一门面Redis对外暴露5种数据类型String, List, Set, Hash, ZSet但内存里只有一种基础结构redisObject。它就像一个万能适配器把所有上层语义翻译成底层物理存储的指令。源码在src/server.h第107行typedef struct redisObject { unsigned type:4; // 数据类型REDIS_STRING, REDIS_LIST等 unsigned encoding:4; // 底层编码REDIS_ENCODING_RAW, REDIS_ENCODING_INT等 unsigned lru:LRU_BITS; // LRU时间戳24位用于淘汰 int refcount; // 引用计数支持对象共享如小整数 void *ptr; // 指向真实数据结构的指针 } robj;别小看这24字节64位系统下。type和encoding两个4位字段构成了Redis最核心的双维度路由机制type决定API语义HGET只能操作Hashencoding决定具体操作函数hgetCommand会根据encoding调用zipmapGet或dictGet。而ptr字段就是通往真实世界的隧道入口。举个实例当你执行HSET user:1001 name zhangsanRedis先创建一个redisObjecttypeREDIS_HASHencodingREDIS_ENCODING_ZIPLIST假设满足ziplist条件然后ptr指向一块连续内存里面按ziplist格式排列着name和zhangsan的二进制编码。整个过程没有malloc分配哈希表节点没有链表指针只有内存块的紧凑排布。注意refcount字段常被忽略但它解决了关键问题——小整数对象共享。Redis会预先创建-1到9999的redisObject所有SET counter 123都复用同一个robjptr指向同一块内存。这省下了上万次malloc/free也避免了整数对象的频繁GC。但要注意一旦某个key被INCRBYFLOAT修改就会触发tryObjectEncoding把共享对象copy-on-write成独立raw编码这是隐式内存增长的源头。2.3 SDSRedis字符串的底层基石为什么不用C原生char*C语言的char*字符串以\0结尾strlen()需要O(n)遍历。Redis自己造轮子写了Simple Dynamic StringSDS定义在src/sds.hstruct __attribute__ ((__packed__)) sdshdr5 { unsigned char flags; // 低3位存len高5位预留 char buf[]; // 柔性数组存放实际字符串 }; // 更常见的sdshdr8len256 struct __attribute__ ((__packed__)) sdshdr8 { uint8_t len; // 已用长度 uint8_t alloc; // 总分配长度 unsigned char flags; // 编码标识 char buf[]; // 实际数据 };sdshdr8结构体本身只占3字节lenallocflags后面紧跟字符串内容。buf是柔性数组sds指针实际指向buf起始地址sds使用者看到的是buf但sdshdr头信息就在buf前面。这种设计带来三大优势O(1)获取长度len字段直接记录strlen()变查表。自动扩容与预分配sdsMakeRoomFor扩容时如果新长度1MB按2倍扩容1MB每次只加1MB。避免频繁realloc同时控制内存浪费。比如当前alloc100len99追加1字节alloc变成200下次追加仍有100字节余量。二进制安全buf里可以存任意字节包括\0len字段保证读取边界。SET binary_key \x00\x01\x02完全合法而C原生char*遇到\0就截断。实操中redis-cli里GET返回的字符串底层就是sdshdr8结构。你可以用DEBUG OBJECT key命令验证redis-cli DEBUG OBJECT mystring会返回encoding:embstr嵌入式SDS或encoding:raw独立SDS并显示serializedlength序列化后长度含sdshdr头。3. 五大核心数据类型的底层实现深度拆解3.1 String不止是字符串是三种编码的智能切换体String类型看似最简单底层却有int、embstr、raw三种编码切换逻辑藏在tryObjectEncoding函数里src/object.c第212行。我们用redis-cli一步步验证# 初始状态小整数int编码 127.0.0.1:6379 SET counter 100 OK 127.0.0.1:6379 DEBUG OBJECT counter Value at:0x7f8b4c00a0a0 refcount:1 encoding:int serializedlength:1 lru:1234567890 lru_seconds_idle:1234567890 # 追加字符触发embstr编码39字节 127.0.0.1:6379 APPEND counter abc (integer) 103 # 长度变成103但仍是int不对APPEND强制转为string 127.0.0.1:6379 DEBUG OBJECT counter Value at:0x7f8b4c00a0a0 refcount:1 encoding:embstr serializedlength:104 lru:1234567890 lru_seconds_idle:1234567890 # 继续追加超过embstr阈值39字节转raw 127.0.0.1:6379 SET longstr a # 先设短字符串 OK 127.0.0.1:6379 DEBUG OBJECT longstr Value at:0x7f8b4c00a0a0 refcount:1 encoding:embstr serializedlength:2 lru:1234567890 lru_seconds_idle:1234567890 127.0.0.1:6379 APPEND longstr bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb # 追加40个b (integer) 41 127.0.0.1:6379 DEBUG OBJECT longstr Value at:0x7f8b4c00a0a0 refcount:1 encoding:raw serializedlength:42 lru:1234567890 lru_seconds_idle:1234567890为什么是39字节看embstr定义redisObject(16字节)sdshdr8(3字节)buf(N字节)\0(1字节)总大小必须≤64字节现代CPU缓存行大小。163120剩下44字节给buf但SDS要求buf至少1字节所以最大有效长度是43不对Redis源码里OBJ_ENCODING_EMBSTR_SIZE_LIMIT宏定义为44但实际测试是39。这是因为redisObject在64位系统下由于内存对齐实际占用24字节type/encoding/lru/refcount共16字节但编译器填充8字节对齐sdshdr83字节\01字节24312864-2836再减去sdshdr8的alloc字段1字节和flags1字节等等源码注释说“embstr is limited to 44 bytes because of the object header size and alignment”。最终结论embstr阈值是44字节但实测中因内存对齐和编译器差异表现为39-44字节区间。生产环境不要依赖精确值记住“短字符串用embstr长字符串用raw”。实操心得MSET批量设置大量小字符串时如果每个都44字节Redis会为每个key分配独立embstr内存碎片率高。此时应考虑用Hash结构聚合HSET users:1001 name zhang age 25底层用ziplist内存利用率提升30%以上。这是我在线上把用户资料缓存从String切到Hash后内存下降1.2TB的真实案例。3.2 List从双向链表到快速列表的进化之路List类型早期用adlist双向链表每个节点listNode包含prev/next指针和value指针内存开销巨大每个节点16字节指针8字节value指针malloc元数据。Redis 3.2后引入quicklist本质是ziplist的双向链表完美平衡了内存和性能。quicklist结构体src/quicklist.htypedef struct quicklist { quicklistNode *head; // 头节点 quicklistNode *tail; // 尾节点 unsigned long count; // 总元素数 unsigned long len; // 节点数每个节点是一个ziplist int fill : 16; // ziplist最大元素数-12..12 unsigned int compress : 16; // LZF压缩深度0不压缩1首尾各1节点不压 } quicklist;quicklistNode则封装了一个ziplisttypedef struct quicklistNode { struct quicklistNode *prev; struct quicklistNode *next; unsigned char *zl; // 指向ziplist的指针 unsigned int sz; // ziplist总字节数 unsigned int count : 16; // ziplist中元素个数 unsigned int encoding : 2; // RAW or LZF unsigned int container : 2; // ONLY supports QUICKLIST_NODE_CONTAINER_ZIPLIST unsigned int recompress : 1; // 是否需要解压 unsigned int attempted_compress : 1; // 压缩失败标记 unsigned int extra : 10; // 预留位 } quicklistNode;关键参数list-max-ziplist-size控制fill值默认-2。负数表示按字节数限制-14KB, -28KB, -316KB... 正数表示按元素数限制。list-compress-depth默认0不压缩。设为1则首尾各1个quicklistNode不压缩中间节点用LZF压缩。压缩能省30%-50%内存但LINDEX/LRANGE需解压增加CPU开销。验证过程# 设置压缩深度为1 127.0.0.1:6379 CONFIG SET list-compress-depth 1 OK # 插入1000个元素 127.0.0.1:6379 LPUSH mylist item_0 ... 127.0.0.1:6379 LPUSH mylist item_999 # 查看结构 127.0.0.1:6379 DEBUG OBJECT mylist Value at:0x7f8b4c00a0a0 refcount:1 encoding:quicklist serializedlength:12345 lru:1234567890 lru_seconds_idle:1234567890 # 查看quicklist详情需redis-server开启debug模式 127.0.0.1:6379 OBJECT FREQ mylist # 不行用redis-cli --raw或gdb注意quicklist的compress参数是双刃剑。某次大促我们把list-compress-depth从0调到2内存降了15%但LRANGE list 0 100延迟从0.2ms升到1.8ms因为每次访问都要解压整个ziplist。最终回滚并用SCAN分批消费替代LRANGE。教训压缩不是银弹要结合访问模式压测。3.3 Hashziplist与hashtable的临界点博弈Hash类型在小数据量时用ziplist压缩列表大数据量时升级为dict哈希表。临界点由两个参数控制hash-max-ziplist-entries默认512ziplist中字段数上限。hash-max-ziplist-value默认64单个field或value的最大字节数。ziplist结构src/ziplist.c是Redis最精巧的设计之一一块连续内存按prevlenencodingdata格式紧凑排列。prevlen字段可1或5字节记录前一个entry长度实现反向遍历encoding标识当前entry是整数还是字符串以及长度。这种设计让100个字段的Hash内存占用比同等dict少40%。但ziplist的O(n)查找是硬伤。HGET hash key需要从头遍历找到key后再找下一个value。当字段数512Redis会触发zipmapConvert把整个ziplist拷贝到dict中encoding从ziplist切到hashtable。dict结构包含两个哈希表ht[0]和ht[1]支持渐进式rehash每次增删操作顺带迁移ht[0]的一个bucket到ht[1]避免单次rehash阻塞主线程。验证临界点# 创建小Hash 127.0.0.1:6379 HMSET smallhash f1 v1 f2 v2 OK 127.0.0.1:6379 DEBUG OBJECT smallhash Value at:0x7f8b4c00a0a0 refcount:1 encoding:ziplist serializedlength:32 lru:1234567890 lru_seconds_idle:1234567890 # 插入第513个字段用脚本 for i in {1..513}; do redis-cli HSET bighash f$i v$i; done # 查看编码 127.0.0.1:6379 DEBUG OBJECT bighash Value at:0x7f8b4c00a0a0 refcount:1 encoding:hashtable serializedlength:12345 lru:1234567890 lru_seconds_idle:1234567890实操心得线上曾遇到Hash字段数卡在511但单个value超64字节如JSON字符串导致encoding提前切到hashtable内存暴增。解决方案对大value做base64编码或分片存储。另一个技巧用HSCAN代替HGETALL遍历大HashHGETALL会把整个Hash加载到内存再序列化而HSCAN流式返回内存友好。3.4 Setintset与hashtable的整数优化Set类型同样有双编码小整数集合用intset整数集合其他情况用dict。intset是纯数组encoding字段标识元素大小INTSET_ENC_INT16/INTSET_ENC_INT32/INTSET_ENC_INT64插入时自动升级。比如初始存1,2,3int16插入65536整个数组升级为int32所有元素重排。intset优势在于极致紧凑无指针、无哈希冲突、CPU缓存行友好。但只支持整数且插入/删除需O(n)移动元素。当元素数512或出现非整数就切到dict。验证# 纯整数Set 127.0.0.1:6379 SADD intset 1 2 3 (integer) 3 127.0.0.1:6379 DEBUG OBJECT intset Value at:0x7f8b4c00a0a0 refcount:1 encoding:intset serializedlength:16 lru:1234567890 lru_seconds_idle:1234567890 # 插入字符串触发升级 127.0.0.1:6379 SADD intset abc (integer) 1 127.0.0.1:6379 DEBUG OBJECT intset Value at:0x7f8b4c00a0a0 refcount:1 encoding:hashtable serializedlength:12345 lru:1234567890 lru_seconds_idle:1234567890注意SINTER/SUNION等集合运算在intset间执行是O(N*M)暴力循环而在dict间是O(N)哈希查找。所以混合编码的Set运算性能差异极大。建议业务层保证Set元素类型一致或预估规模后主动用CONFIG SET set-max-intset-entries 1000调高阈值。3.5 ZSet跳表Skiplist为何是唯一选择ZSet是Redis最复杂的结构必须同时支持按score排序ZRANGE和按member查找ZSCORE。平衡二叉树如红黑树能O(logN)完成两者但Redis选了跳表Skiplist。原因有三实现简单Bug少跳表代码约500行红黑树需处理7种旋转CaseRedis作者antirez明确说过“skip list is simpler than balanced trees”。范围查询更自然ZRANGEBYSCORE需要返回score区间内所有member跳表的多层指针天然支持“从高层快速定位再降层精确扫描”而红黑树需中序遍历剪枝。内存友好跳表节点指针是固定长度struct zskiplistNode *forward[ZSKIPLIST_MAXLEVEL]而红黑树节点需left/right/parent/color内存开销更大。zskiplist结构typedef struct zskiplist { struct zskiplistNode *header, *tail; // 头尾哨兵 unsigned long length; // 总节点数 int level; // 当前最高层数1-32 } zskiplist; typedef struct zskiplistNode { sds ele; // member字符串 double score; // score struct zskiplistNode *backward; // 后退指针仅底层 struct zskiplistLevel { struct zskiplistNode *forward; // 前进指针 unsigned long span; // 跨越的节点数用于ZRANK } level[]; // 柔性数组最多32层 } zskiplistNode;跳表的level是随机生成的zslRandomLevel函数概率分布为P(levelk)1/2^k所以大部分节点1层少数2层极少数32层。span字段是精髓ZRANK命令要返回member的排名跳表本身不存排名但每层forward指针的span累加就能O(logN)算出从头到该节点的总跨度。验证# 创建ZSet 127.0.0.1:6379 ZADD zset 1 a 2 b 3 c (integer) 3 127.0.0.1:6379 DEBUG OBJECT zset Value at:0x7f8b4c00a0a0 refcount:1 encoding:skiplist serializedlength:12345 lru:1234567890 lru_seconds_idle:1234567890实操心得ZSet内存占用是String的3倍以上scoremember跳表指针。某次用户行为埋点用ZADD user:1001:actions 1623456789 click_home存百万事件内存飙升。改用TSTimeSeries模块或分片HashHSET user:1001:actions:202406 1623456789 click_home后内存降为1/5。记住ZSet不是万能排序器要评估是否真需要O(logN)随机访问。4. 内存管理全景从分配器到淘汰策略的完整链条4.1 分配器选择libc malloc vs jemalloc vs tcmalloc为什么Redis默认用jemallocRedis编译时可选--with-jemalloc、--with-tcmalloc或--with-malloc。生产环境强烈推荐jemalloc原因在于其针对多线程和小对象的极致优化内存碎片控制jemalloc将内存划分为不同大小的bin如8B, 16B, 32B...每个bin维护自己的空闲链表。分配8字节对象就从8B bin取避免libc malloc的通用arena碎片。线程本地缓存tcache每个线程有自己的小对象缓存malloc/free无需锁redis-server虽单线程但fork子进程RDB/AOF rewrite时子进程继承tcache减少fork后首次分配的锁争用。大页支持jemalloc能自动使用Huge Page2MB减少TLB miss。cat /proc/sys/vm/nr_hugepages可查看系统Huge Page数。验证分配器# 查看Redis编译信息 127.0.0.1:6379 INFO server | grep malloc malloc_stats:jemalloc-5.2.1 # 或用pstack看线程栈 pstack $(pgrep redis-server) # 若看到je_malloc字样即为jemalloc注意docker install redis默认镜像用libc malloc内存碎片率高。线上部署务必用redis:alpine内置jemalloc或自编译--with-jemalloc。某次故障libc malloc导致RDB save时fork失败Cannot allocate memory切换jemalloc后解决。4.2 内存淘汰策略LRU/LFU不是魔法是采样与近似的艺术Redis淘汰策略maxmemory-policy有6种核心是volatile-lru、allkeys-lru、volatile-lfu、allkeys-lfu。但注意Redis的LRU不是精确的而是基于采样的近似LRU。evictionPoolPopulate函数src/evict.c实现当内存不足随机采样REDIS_EVICTED_SAMPLES默认5个key按lru字段排序淘汰最久未用的。这意味着如果热点key恰好没被采样到可能被误淘汰。lru字段是24位最大值16777215约194天溢出后归零造成“年龄重置”。LFULeast Frequently Used更复杂lru字段拆成16位logc访问频次对数8位ldt最后递减时间。logc不是真实计数而是概率递增counter counter 1/(counter*0.0011)避免高频key垄断计数器。ldt记录上次递减时间超过5分钟未访问logc衰减。验证淘汰# 设置内存上限100MB 127.0.0.1:6379 CONFIG SET maxmemory 100mb OK 127.0.0.1:6379 CONFIG SET maxmemory-policy allkeys-lru OK # 持续写入直到触发淘汰 for i in {1..100000}; do redis-cli SET key_$i value_$i; done # 查看淘汰统计 127.0.0.1:6379 INFO stats | grep evicted_keys evicted_keys:12345实操心得allkeys-lfu在流量突增时表现更稳但volatile-lfu对带TTL的key更公平。某次秒杀用volatile-lru库存key因访问频繁未被淘汰但大量临时token被误淘汰导致用户重复下单。换成volatile-lfu后token按访问频次淘汰库存key保留问题解决。建议业务key统一加TTL淘汰策略选volatile-*。4.3 RDB与AOF两种持久化背后的内存视图RDB是内存快照AOF是操作日志但它们对内存的影响截然不同RDBBGSAVE时fork子进程利用写时复制Copy-on-Write。子进程内存页与父进程共享只有父进程修改页面时OS才复制。所以RDB期间内存占用≈父进程子进程页表而非两倍内存。但fork耗时与内存大小正相关32GB内存fork可能耗时2秒期间主线程阻塞。AOFappendonly yes后每个写命令追加到aof_buf再write到文件fsync策略决定持久化强度。aof_buf是内存缓冲区fsync频率影响内存压力。everysec模式下aof_buf最大1秒数据内存可控always模式下aof_buf几乎实时清空但fsync阻塞主线程。验证RDB fork开销# 监控fork时间 redis-cli CONFIG GET activedefrag # 或用systemd-cgtop看redis cgroup内存 systemd-cgtop -P | grep redis注意auto-aof-rewrite-percentage和auto-aof-rewrite-min-size触发AOF重写时会fork子进程重写AOF文件。重写期间父进程继续追加新命令到旧AOF子进程读取内存生成新AOF。这比RDB更耗内存因为要同时维护新旧AOF缓冲区。线上建议aof-rewrite-incremental-fsync yes让子进程分批fsync降低IO峰值。5. 常见问题排查与性能调优实战手册5.1 内存暴涨诊断从INFO memory到MEMORY USAGE的逐层剥茧当INFO memory显示used_memory_human:10.24G但业务没明显增长按以下步骤排查确认是否真的内存泄漏redis-cli INFO memory | grep mem重点看mem_allocator分配器、used_memory_rssRSS内存、used_memory_peak峰值。若used_memory_rssused_memory说明内存碎片严重若used_memory_peak持续上升可能是key未及时删除。定位大keyredis-cli --bigkeys
1. 这不是“又一篇Redis入门”而是打开存储黑箱的第一把钥匙你点开这个标题大概率不是想看“Redis有5种数据类型”这种教科书式罗列。你真正想搞清楚的是为什么一个字符串SET user:1001 zhangsan存进去内存里不是简单地放一串ASCII为什么HSET user:1001 name zhangsan age 28能比MySQL快两个数量级为什么LPUSH logs 2024-06-12T10:30:00插入10万条日志内存占用却远低于预期更关键的是——当面试官突然问“ZSET底层用什么实现跳表和红黑树怎么选”时你脑子里浮现的不该是背诵的答案而是一幅清晰的内存布局图。这就是本篇要干的事不讲命令怎么用不堆API文档只带你亲手拆开Redis的内存外壳看清redisObject、sds、dict、ziplist、quicklist、skiplist这些结构在物理内存里是怎么咬合、怎么伸缩、怎么妥协的。我做Redis中间件运维和性能调优七年经手过单集群20TB缓存、QPS峰值800万的电商大促场景踩过的坑全来自对底层机制的误判——比如以为HGETALL只是“取全部字段”结果发现它触发了整张哈希表的遍历内存拷贝比如以为LRU淘汰是精确到每个key的计时器结果发现它用的是近似随机采样。这些认知偏差全源于没真正看过src/server.h里那个robj结构体定义没亲手用DEBUG OBJECT key验证过编码转换时机没在gdb里单步跟踪过rdbSaveListObject的序列化路径。所以这篇内容适合三类人正在准备中高级后端面试的开发者尤其关注Redis原理题、需要做缓存容量预估和淘汰策略调优的SRE、以及所有被“Redis为什么快”这个问题困扰超过3次的技术人。我们不从官网文档抄概念而是从redis-cli敲出的第一行INFO memory开始一层层往下挖。2. 核心设计哲学一切为了内存效率与访问速度的极致平衡2.1 Redis不是数据库是内存数据结构服务器——这句话到底在说什么很多人把Redis当成“内存版MySQL”这是根本性误解。MySQL的核心目标是持久化可靠性和复杂查询能力为此可以牺牲写入延迟WAL日志刷盘、接受B树索引的磁盘IO放大、容忍事务锁带来的并发阻塞。而Redis的设计原点只有一个在单线程模型下把内存带宽和CPU缓存利用率榨到极限。这意味着所有决策都围绕三个铁律展开零拷贝优先任何数据操作只要可能就避免内存复制。比如GET key返回值不是从内部缓冲区memcpy到socket发送缓冲区而是直接让内核sendfile或splice零拷贝发送LRANGE list 0 -1遍历列表不是把每个元素malloc新内存再拼接而是直接复用原有ziplist或quicklist节点的指针。空间换时间的精妙尺度Redis大量使用“编码切换”encoding switching机制。同一个逻辑数据类型在不同数据规模下底层物理结构完全不同。比如一个空Hash初始用HT哈希表太重就用ZIPLIST压缩列表当字段数超过512或单个value长度超64字节才升级为HT。这不是偷懒而是经过严格压测的权衡ZIPLIST内存碎片率低、CPU缓存行友好连续内存但O(n)查找HT是O(1)平均查找但每个entry要额外8字节指针哈希桶数组开销。Redis的hash-max-ziplist-entries参数就是这个平衡点的刻度尺。单线程不是限制是确定性保障Redis用单线程处理所有客户端请求看似反直觉实则是为消除锁竞争带来的不可预测延迟。在多核CPU上加锁/解锁、缓存行失效false sharing、上下文切换的开销往往比纯计算还高。Redis把所有操作变成原子性的内存读写配合epoll/kqueue事件驱动让99%的请求延迟稳定在100微秒内。你看redis-benchmark跑出来的P99延迟曲线那条平直的尾巴就是单线程内存操作的馈赠。提示理解这三点才能看懂后续所有结构设计。比如为什么String类型有int、embstr、raw三种编码因为小整数直接存robj-ptr里int编码避免指针跳转短字符串用embstr嵌入式SDS保证robj和sdshdr内存连续一次CPU缓存行加载完成长字符串才用raw独立SDS牺牲一点局部性换取动态扩容能力。全是为第一条“零拷贝”和第二条“空间换时间”服务。2.2 从redisObject开始所有数据类型的统一门面Redis对外暴露5种数据类型String, List, Set, Hash, ZSet但内存里只有一种基础结构redisObject。它就像一个万能适配器把所有上层语义翻译成底层物理存储的指令。源码在src/server.h第107行typedef struct redisObject { unsigned type:4; // 数据类型REDIS_STRING, REDIS_LIST等 unsigned encoding:4; // 底层编码REDIS_ENCODING_RAW, REDIS_ENCODING_INT等 unsigned lru:LRU_BITS; // LRU时间戳24位用于淘汰 int refcount; // 引用计数支持对象共享如小整数 void *ptr; // 指向真实数据结构的指针 } robj;别小看这24字节64位系统下。type和encoding两个4位字段构成了Redis最核心的双维度路由机制type决定API语义HGET只能操作Hashencoding决定具体操作函数hgetCommand会根据encoding调用zipmapGet或dictGet。而ptr字段就是通往真实世界的隧道入口。举个实例当你执行HSET user:1001 name zhangsanRedis先创建一个redisObjecttypeREDIS_HASHencodingREDIS_ENCODING_ZIPLIST假设满足ziplist条件然后ptr指向一块连续内存里面按ziplist格式排列着name和zhangsan的二进制编码。整个过程没有malloc分配哈希表节点没有链表指针只有内存块的紧凑排布。注意refcount字段常被忽略但它解决了关键问题——小整数对象共享。Redis会预先创建-1到9999的redisObject所有SET counter 123都复用同一个robjptr指向同一块内存。这省下了上万次malloc/free也避免了整数对象的频繁GC。但要注意一旦某个key被INCRBYFLOAT修改就会触发tryObjectEncoding把共享对象copy-on-write成独立raw编码这是隐式内存增长的源头。2.3 SDSRedis字符串的底层基石为什么不用C原生char*C语言的char*字符串以\0结尾strlen()需要O(n)遍历。Redis自己造轮子写了Simple Dynamic StringSDS定义在src/sds.hstruct __attribute__ ((__packed__)) sdshdr5 { unsigned char flags; // 低3位存len高5位预留 char buf[]; // 柔性数组存放实际字符串 }; // 更常见的sdshdr8len256 struct __attribute__ ((__packed__)) sdshdr8 { uint8_t len; // 已用长度 uint8_t alloc; // 总分配长度 unsigned char flags; // 编码标识 char buf[]; // 实际数据 };sdshdr8结构体本身只占3字节lenallocflags后面紧跟字符串内容。buf是柔性数组sds指针实际指向buf起始地址sds使用者看到的是buf但sdshdr头信息就在buf前面。这种设计带来三大优势O(1)获取长度len字段直接记录strlen()变查表。自动扩容与预分配sdsMakeRoomFor扩容时如果新长度1MB按2倍扩容1MB每次只加1MB。避免频繁realloc同时控制内存浪费。比如当前alloc100len99追加1字节alloc变成200下次追加仍有100字节余量。二进制安全buf里可以存任意字节包括\0len字段保证读取边界。SET binary_key \x00\x01\x02完全合法而C原生char*遇到\0就截断。实操中redis-cli里GET返回的字符串底层就是sdshdr8结构。你可以用DEBUG OBJECT key命令验证redis-cli DEBUG OBJECT mystring会返回encoding:embstr嵌入式SDS或encoding:raw独立SDS并显示serializedlength序列化后长度含sdshdr头。3. 五大核心数据类型的底层实现深度拆解3.1 String不止是字符串是三种编码的智能切换体String类型看似最简单底层却有int、embstr、raw三种编码切换逻辑藏在tryObjectEncoding函数里src/object.c第212行。我们用redis-cli一步步验证# 初始状态小整数int编码 127.0.0.1:6379 SET counter 100 OK 127.0.0.1:6379 DEBUG OBJECT counter Value at:0x7f8b4c00a0a0 refcount:1 encoding:int serializedlength:1 lru:1234567890 lru_seconds_idle:1234567890 # 追加字符触发embstr编码39字节 127.0.0.1:6379 APPEND counter abc (integer) 103 # 长度变成103但仍是int不对APPEND强制转为string 127.0.0.1:6379 DEBUG OBJECT counter Value at:0x7f8b4c00a0a0 refcount:1 encoding:embstr serializedlength:104 lru:1234567890 lru_seconds_idle:1234567890 # 继续追加超过embstr阈值39字节转raw 127.0.0.1:6379 SET longstr a # 先设短字符串 OK 127.0.0.1:6379 DEBUG OBJECT longstr Value at:0x7f8b4c00a0a0 refcount:1 encoding:embstr serializedlength:2 lru:1234567890 lru_seconds_idle:1234567890 127.0.0.1:6379 APPEND longstr bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb # 追加40个b (integer) 41 127.0.0.1:6379 DEBUG OBJECT longstr Value at:0x7f8b4c00a0a0 refcount:1 encoding:raw serializedlength:42 lru:1234567890 lru_seconds_idle:1234567890为什么是39字节看embstr定义redisObject(16字节)sdshdr8(3字节)buf(N字节)\0(1字节)总大小必须≤64字节现代CPU缓存行大小。163120剩下44字节给buf但SDS要求buf至少1字节所以最大有效长度是43不对Redis源码里OBJ_ENCODING_EMBSTR_SIZE_LIMIT宏定义为44但实际测试是39。这是因为redisObject在64位系统下由于内存对齐实际占用24字节type/encoding/lru/refcount共16字节但编译器填充8字节对齐sdshdr83字节\01字节24312864-2836再减去sdshdr8的alloc字段1字节和flags1字节等等源码注释说“embstr is limited to 44 bytes because of the object header size and alignment”。最终结论embstr阈值是44字节但实测中因内存对齐和编译器差异表现为39-44字节区间。生产环境不要依赖精确值记住“短字符串用embstr长字符串用raw”。实操心得MSET批量设置大量小字符串时如果每个都44字节Redis会为每个key分配独立embstr内存碎片率高。此时应考虑用Hash结构聚合HSET users:1001 name zhang age 25底层用ziplist内存利用率提升30%以上。这是我在线上把用户资料缓存从String切到Hash后内存下降1.2TB的真实案例。3.2 List从双向链表到快速列表的进化之路List类型早期用adlist双向链表每个节点listNode包含prev/next指针和value指针内存开销巨大每个节点16字节指针8字节value指针malloc元数据。Redis 3.2后引入quicklist本质是ziplist的双向链表完美平衡了内存和性能。quicklist结构体src/quicklist.htypedef struct quicklist { quicklistNode *head; // 头节点 quicklistNode *tail; // 尾节点 unsigned long count; // 总元素数 unsigned long len; // 节点数每个节点是一个ziplist int fill : 16; // ziplist最大元素数-12..12 unsigned int compress : 16; // LZF压缩深度0不压缩1首尾各1节点不压 } quicklist;quicklistNode则封装了一个ziplisttypedef struct quicklistNode { struct quicklistNode *prev; struct quicklistNode *next; unsigned char *zl; // 指向ziplist的指针 unsigned int sz; // ziplist总字节数 unsigned int count : 16; // ziplist中元素个数 unsigned int encoding : 2; // RAW or LZF unsigned int container : 2; // ONLY supports QUICKLIST_NODE_CONTAINER_ZIPLIST unsigned int recompress : 1; // 是否需要解压 unsigned int attempted_compress : 1; // 压缩失败标记 unsigned int extra : 10; // 预留位 } quicklistNode;关键参数list-max-ziplist-size控制fill值默认-2。负数表示按字节数限制-14KB, -28KB, -316KB... 正数表示按元素数限制。list-compress-depth默认0不压缩。设为1则首尾各1个quicklistNode不压缩中间节点用LZF压缩。压缩能省30%-50%内存但LINDEX/LRANGE需解压增加CPU开销。验证过程# 设置压缩深度为1 127.0.0.1:6379 CONFIG SET list-compress-depth 1 OK # 插入1000个元素 127.0.0.1:6379 LPUSH mylist item_0 ... 127.0.0.1:6379 LPUSH mylist item_999 # 查看结构 127.0.0.1:6379 DEBUG OBJECT mylist Value at:0x7f8b4c00a0a0 refcount:1 encoding:quicklist serializedlength:12345 lru:1234567890 lru_seconds_idle:1234567890 # 查看quicklist详情需redis-server开启debug模式 127.0.0.1:6379 OBJECT FREQ mylist # 不行用redis-cli --raw或gdb注意quicklist的compress参数是双刃剑。某次大促我们把list-compress-depth从0调到2内存降了15%但LRANGE list 0 100延迟从0.2ms升到1.8ms因为每次访问都要解压整个ziplist。最终回滚并用SCAN分批消费替代LRANGE。教训压缩不是银弹要结合访问模式压测。3.3 Hashziplist与hashtable的临界点博弈Hash类型在小数据量时用ziplist压缩列表大数据量时升级为dict哈希表。临界点由两个参数控制hash-max-ziplist-entries默认512ziplist中字段数上限。hash-max-ziplist-value默认64单个field或value的最大字节数。ziplist结构src/ziplist.c是Redis最精巧的设计之一一块连续内存按prevlenencodingdata格式紧凑排列。prevlen字段可1或5字节记录前一个entry长度实现反向遍历encoding标识当前entry是整数还是字符串以及长度。这种设计让100个字段的Hash内存占用比同等dict少40%。但ziplist的O(n)查找是硬伤。HGET hash key需要从头遍历找到key后再找下一个value。当字段数512Redis会触发zipmapConvert把整个ziplist拷贝到dict中encoding从ziplist切到hashtable。dict结构包含两个哈希表ht[0]和ht[1]支持渐进式rehash每次增删操作顺带迁移ht[0]的一个bucket到ht[1]避免单次rehash阻塞主线程。验证临界点# 创建小Hash 127.0.0.1:6379 HMSET smallhash f1 v1 f2 v2 OK 127.0.0.1:6379 DEBUG OBJECT smallhash Value at:0x7f8b4c00a0a0 refcount:1 encoding:ziplist serializedlength:32 lru:1234567890 lru_seconds_idle:1234567890 # 插入第513个字段用脚本 for i in {1..513}; do redis-cli HSET bighash f$i v$i; done # 查看编码 127.0.0.1:6379 DEBUG OBJECT bighash Value at:0x7f8b4c00a0a0 refcount:1 encoding:hashtable serializedlength:12345 lru:1234567890 lru_seconds_idle:1234567890实操心得线上曾遇到Hash字段数卡在511但单个value超64字节如JSON字符串导致encoding提前切到hashtable内存暴增。解决方案对大value做base64编码或分片存储。另一个技巧用HSCAN代替HGETALL遍历大HashHGETALL会把整个Hash加载到内存再序列化而HSCAN流式返回内存友好。3.4 Setintset与hashtable的整数优化Set类型同样有双编码小整数集合用intset整数集合其他情况用dict。intset是纯数组encoding字段标识元素大小INTSET_ENC_INT16/INTSET_ENC_INT32/INTSET_ENC_INT64插入时自动升级。比如初始存1,2,3int16插入65536整个数组升级为int32所有元素重排。intset优势在于极致紧凑无指针、无哈希冲突、CPU缓存行友好。但只支持整数且插入/删除需O(n)移动元素。当元素数512或出现非整数就切到dict。验证# 纯整数Set 127.0.0.1:6379 SADD intset 1 2 3 (integer) 3 127.0.0.1:6379 DEBUG OBJECT intset Value at:0x7f8b4c00a0a0 refcount:1 encoding:intset serializedlength:16 lru:1234567890 lru_seconds_idle:1234567890 # 插入字符串触发升级 127.0.0.1:6379 SADD intset abc (integer) 1 127.0.0.1:6379 DEBUG OBJECT intset Value at:0x7f8b4c00a0a0 refcount:1 encoding:hashtable serializedlength:12345 lru:1234567890 lru_seconds_idle:1234567890注意SINTER/SUNION等集合运算在intset间执行是O(N*M)暴力循环而在dict间是O(N)哈希查找。所以混合编码的Set运算性能差异极大。建议业务层保证Set元素类型一致或预估规模后主动用CONFIG SET set-max-intset-entries 1000调高阈值。3.5 ZSet跳表Skiplist为何是唯一选择ZSet是Redis最复杂的结构必须同时支持按score排序ZRANGE和按member查找ZSCORE。平衡二叉树如红黑树能O(logN)完成两者但Redis选了跳表Skiplist。原因有三实现简单Bug少跳表代码约500行红黑树需处理7种旋转CaseRedis作者antirez明确说过“skip list is simpler than balanced trees”。范围查询更自然ZRANGEBYSCORE需要返回score区间内所有member跳表的多层指针天然支持“从高层快速定位再降层精确扫描”而红黑树需中序遍历剪枝。内存友好跳表节点指针是固定长度struct zskiplistNode *forward[ZSKIPLIST_MAXLEVEL]而红黑树节点需left/right/parent/color内存开销更大。zskiplist结构typedef struct zskiplist { struct zskiplistNode *header, *tail; // 头尾哨兵 unsigned long length; // 总节点数 int level; // 当前最高层数1-32 } zskiplist; typedef struct zskiplistNode { sds ele; // member字符串 double score; // score struct zskiplistNode *backward; // 后退指针仅底层 struct zskiplistLevel { struct zskiplistNode *forward; // 前进指针 unsigned long span; // 跨越的节点数用于ZRANK } level[]; // 柔性数组最多32层 } zskiplistNode;跳表的level是随机生成的zslRandomLevel函数概率分布为P(levelk)1/2^k所以大部分节点1层少数2层极少数32层。span字段是精髓ZRANK命令要返回member的排名跳表本身不存排名但每层forward指针的span累加就能O(logN)算出从头到该节点的总跨度。验证# 创建ZSet 127.0.0.1:6379 ZADD zset 1 a 2 b 3 c (integer) 3 127.0.0.1:6379 DEBUG OBJECT zset Value at:0x7f8b4c00a0a0 refcount:1 encoding:skiplist serializedlength:12345 lru:1234567890 lru_seconds_idle:1234567890实操心得ZSet内存占用是String的3倍以上scoremember跳表指针。某次用户行为埋点用ZADD user:1001:actions 1623456789 click_home存百万事件内存飙升。改用TSTimeSeries模块或分片HashHSET user:1001:actions:202406 1623456789 click_home后内存降为1/5。记住ZSet不是万能排序器要评估是否真需要O(logN)随机访问。4. 内存管理全景从分配器到淘汰策略的完整链条4.1 分配器选择libc malloc vs jemalloc vs tcmalloc为什么Redis默认用jemallocRedis编译时可选--with-jemalloc、--with-tcmalloc或--with-malloc。生产环境强烈推荐jemalloc原因在于其针对多线程和小对象的极致优化内存碎片控制jemalloc将内存划分为不同大小的bin如8B, 16B, 32B...每个bin维护自己的空闲链表。分配8字节对象就从8B bin取避免libc malloc的通用arena碎片。线程本地缓存tcache每个线程有自己的小对象缓存malloc/free无需锁redis-server虽单线程但fork子进程RDB/AOF rewrite时子进程继承tcache减少fork后首次分配的锁争用。大页支持jemalloc能自动使用Huge Page2MB减少TLB miss。cat /proc/sys/vm/nr_hugepages可查看系统Huge Page数。验证分配器# 查看Redis编译信息 127.0.0.1:6379 INFO server | grep malloc malloc_stats:jemalloc-5.2.1 # 或用pstack看线程栈 pstack $(pgrep redis-server) # 若看到je_malloc字样即为jemalloc注意docker install redis默认镜像用libc malloc内存碎片率高。线上部署务必用redis:alpine内置jemalloc或自编译--with-jemalloc。某次故障libc malloc导致RDB save时fork失败Cannot allocate memory切换jemalloc后解决。4.2 内存淘汰策略LRU/LFU不是魔法是采样与近似的艺术Redis淘汰策略maxmemory-policy有6种核心是volatile-lru、allkeys-lru、volatile-lfu、allkeys-lfu。但注意Redis的LRU不是精确的而是基于采样的近似LRU。evictionPoolPopulate函数src/evict.c实现当内存不足随机采样REDIS_EVICTED_SAMPLES默认5个key按lru字段排序淘汰最久未用的。这意味着如果热点key恰好没被采样到可能被误淘汰。lru字段是24位最大值16777215约194天溢出后归零造成“年龄重置”。LFULeast Frequently Used更复杂lru字段拆成16位logc访问频次对数8位ldt最后递减时间。logc不是真实计数而是概率递增counter counter 1/(counter*0.0011)避免高频key垄断计数器。ldt记录上次递减时间超过5分钟未访问logc衰减。验证淘汰# 设置内存上限100MB 127.0.0.1:6379 CONFIG SET maxmemory 100mb OK 127.0.0.1:6379 CONFIG SET maxmemory-policy allkeys-lru OK # 持续写入直到触发淘汰 for i in {1..100000}; do redis-cli SET key_$i value_$i; done # 查看淘汰统计 127.0.0.1:6379 INFO stats | grep evicted_keys evicted_keys:12345实操心得allkeys-lfu在流量突增时表现更稳但volatile-lfu对带TTL的key更公平。某次秒杀用volatile-lru库存key因访问频繁未被淘汰但大量临时token被误淘汰导致用户重复下单。换成volatile-lfu后token按访问频次淘汰库存key保留问题解决。建议业务key统一加TTL淘汰策略选volatile-*。4.3 RDB与AOF两种持久化背后的内存视图RDB是内存快照AOF是操作日志但它们对内存的影响截然不同RDBBGSAVE时fork子进程利用写时复制Copy-on-Write。子进程内存页与父进程共享只有父进程修改页面时OS才复制。所以RDB期间内存占用≈父进程子进程页表而非两倍内存。但fork耗时与内存大小正相关32GB内存fork可能耗时2秒期间主线程阻塞。AOFappendonly yes后每个写命令追加到aof_buf再write到文件fsync策略决定持久化强度。aof_buf是内存缓冲区fsync频率影响内存压力。everysec模式下aof_buf最大1秒数据内存可控always模式下aof_buf几乎实时清空但fsync阻塞主线程。验证RDB fork开销# 监控fork时间 redis-cli CONFIG GET activedefrag # 或用systemd-cgtop看redis cgroup内存 systemd-cgtop -P | grep redis注意auto-aof-rewrite-percentage和auto-aof-rewrite-min-size触发AOF重写时会fork子进程重写AOF文件。重写期间父进程继续追加新命令到旧AOF子进程读取内存生成新AOF。这比RDB更耗内存因为要同时维护新旧AOF缓冲区。线上建议aof-rewrite-incremental-fsync yes让子进程分批fsync降低IO峰值。5. 常见问题排查与性能调优实战手册5.1 内存暴涨诊断从INFO memory到MEMORY USAGE的逐层剥茧当INFO memory显示used_memory_human:10.24G但业务没明显增长按以下步骤排查确认是否真的内存泄漏redis-cli INFO memory | grep mem重点看mem_allocator分配器、used_memory_rssRSS内存、used_memory_peak峰值。若used_memory_rssused_memory说明内存碎片严重若used_memory_peak持续上升可能是key未及时删除。定位大keyredis-cli --bigkeys
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
