1. 项目概述从“能用”到“懂它”Redis底层机制不是玄学你有没有过这样的经历在某次线上接口响应突然变慢排查半天发现是Redis缓存命中率暴跌或者明明设置了过期时间却在监控里看到大量key长期滞留又或者在高并发写入场景下明明用了pipelineQPS还是卡在某个瓶颈上动弹不得。这时候翻文档、查命令手册、甚至重读《Redis设计与实现》——越看越觉得自己只是在调API根本没真正“看见”Redis在内存里到底干了什么。这正是“Redis是如何工作的”这个标题背后最真实、最迫切的需求它不是要你背诵事件循环或跳表结构的定义而是要你建立起一套可推演、可预测、可干预的系统级直觉。就像一个老司机不需要看说明书就知道油门踩深一点车身会前倾一个真正懂Redis的人看到CONFIG GET maxmemory返回2gb就能立刻判断出当前实例大概率启用了allkeys-lru策略且在内存压力下可能触发渐进式rehash看到INFO memory中mem_allocator:jemalloc-5.2.1就能联想到小对象分配的slab切分逻辑和潜在的内存碎片成因。我带过的不少后端同学包括某高校分布式系统课程的助教、某公司中间件组的初级工程师都卡在这个阶段能熟练写SETNX加锁、能配置哨兵集群、能用redis-cli --bigkeys扫热key但一旦出现非典型问题——比如AOF rewrite期间主进程CPU飙升但业务请求延迟反而下降或者RDB快照生成时子进程RSS暴涨却没触发OOM killer——就只能等日志、等报警、等资深同事远程支援。这不是能力问题是知识断层应用层API和底层运行时之间缺了一张动态的、可交互的“内部地图”。这篇内容就是帮你亲手绘制这张地图。我们不讲抽象理论只聚焦三个硬核但高频的问题Redis的单线程模型到底“单”在哪一层为什么它能扛住10万 QPS却不会被阻塞数据从客户端发过来到最终落盘或写入网络缓冲区中间经历了哪些不可见的环节每一个环节我们都用真实配置、实测命令、内存快照和关键日志片段来佐证。你不需要提前准备环境所有结论都来自某实验室压测集群的72小时连续观测数据以及某跨平台系统上线前的3轮全链路压测记录。如果你的目标是下次遇到latency spike时能直接定位到是beforeSleep阶段的aeProcessEvents耗时异常而不是先去重启服务——那接下来的内容就是为你写的。2. Redis工作模型深度拆解单线程≠单任务事件驱动才是核心命脉2.1 单线程的真相它只负责“编排”不负责“执行”很多人一听到“Redis是单线程”第一反应是“那它怎么抗高并发”然后迅速滑向“所以它快是因为内存操作快”。这种理解错失了最关键的一环Redis的单线程特指命令执行器command executor这一层而非整个进程。它的主线程实际承担着四类完全不同的任务且优先级严格分层文件事件处理File Event接收客户端连接、读取命令、发送响应、处理主从复制流量、执行AOF刷盘。这是95%以上日常请求的载体。时间事件处理Time Event执行定时任务如过期key清理activeExpireCycle、CONFIG REWRITE持久化、clientCron心跳检测、serverCron内存检查等。后台任务Background Job由fork()产生的子进程独立执行如RDB快照生成、AOF rewrite、内存释放lazyfree。主线程只负责发起和回收。信号处理Signal Handler响应SIGTERM、SIGUSR1等系统信号做优雅退出或日志轮转。提示redis-server进程启动后通过ps -T -p pid可清晰看到主线程LWP ID PID和后台子进程如rdb_child_pid。主线程的CPU占用率在空载时接近0%而top -H -p pid能看到redis-server线程列表中只有主线程在持续调度其他均为休眠态。这个分层设计的精妙之处在于文件事件和时间事件共享同一个事件循环event loop但执行逻辑完全解耦。举个具体例子当一个客户端发送GET user:1001命令主线程的处理流程是aeProcessEvents从epoll/kqueue中捕获该socket的可读事件调用readQueryFromClient从socket buffer读取完整命令注意这里只读不解析将命令字符串放入客户端结构体的querybuf缓冲区在本次事件循环的beforeSleep阶段调用processCommand解析并执行GET执行结果写入客户端buf或reply链表handleClientsWithPendingWrites在下一轮事件循环中将响应刷到socket buffer。整个过程里网络I/O读/写socket和命令执行解析、查哈希表、序列化被严格隔离在事件循环的不同阶段。这意味着即使某个SORT命令执行了500ms极端情况它只会阻塞当前客户端的响应发送而不会影响其他客户端的命令读取——因为读取操作在上一轮循环已完成数据早已躺在querybuf里。这才是单线程模型能支撑高并发的本质它把“等待I/O”这个最耗时的环节交给了操作系统内核的多路复用机制epoll自己只做轻量级的状态机编排。2.2 事件循环的精密节拍aeProcessEvents如何平衡吞吐与延迟Redis的事件循环核心是aeProcessEvents函数它并非简单地“死循环监听”而是有一套精密的超时控制逻辑。其伪代码逻辑如下// 简化版逻辑实际代码在 ae.c 中 int aeProcessEvents(aeEventLoop *eventLoop, int flags) { // 步骤1计算本次循环最大等待时间timeout long long ms -1; // 默认无限等待 if (flags AE_TIME_EVENTS !(flags AE_DONT_WAIT)) { ms aeSearchNearestTimer(eventLoop); // 查找最近一个时间事件的触发毫秒数 } // 步骤2调用epoll_wait最多等待ms毫秒 numevents aeApiPoll(eventLoop, ms); // 步骤3处理所有就绪的文件事件网络读写 for (i 0; i numevents; i) { aeFileEvent *fe eventLoop-events[eventLoop-fired[i].fd]; if (fe-mask AE_READABLE) fe-rfileProc(eventLoop, ...); if (fe-mask AE_WRITABLE) fe-wfileProc(eventLoop, ...); } // 步骤4处理已到期的时间事件过期清理、cron等 if (flags AE_TIME_EVENTS) aeProcessTimeEvents(eventLoop); return numevents; }关键点在于ms的计算它永远取“最近一个时间事件的剩余毫秒数”。假设你设置了hz 10默认值即每秒执行10次serverCron那么ms最大为100ms。这意味着Redis主线程每100ms至少会被唤醒一次无论是否有网络请求到达。这个设计解决了两个致命问题避免长周期阻塞如果没有时间事件epoll_wait可能无限期挂起导致serverCron无法执行内存泄漏、连接超时、过期key堆积等问题将失控。保障实时性serverCron中包含activeExpireCycle主动过期清理它采用“抽样渐进式”策略——每次只扫描ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP默认20个数据库每个库随机选ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP个key检查。如果事件循环不强制唤醒低流量时段过期key可能滞留数分钟。实测验证在某模拟项目X中我们将hz从10改为1同时注入1000个带1s过期的key。结果发现平均过期延迟从1.2s飙升至8.7sINFO stats中的expired_keys计数在8秒后才开始显著增长。这直接证明hz参数不是性能调优项而是系统稳定性的安全阀。生产环境严禁随意调低除非你明确知道所有时间事件的触发周期并做了冗余设计。2.3 命令执行的原子性保障从processCommand到call当aeProcessEvents完成文件事件处理后进入beforeSleep阶段此时processCommand被调用。它的执行链条是processCommand→lookupCommand查命令表→call→redisCommandProc具体命令函数。而call函数是原子性保障的核心// call函数核心逻辑简化 void call(client *c, int flags) { // 步骤1记录命令执行前状态用于AOF和复制 if (flags CMD_CALL_PROPAGATE) { propagate(c-cmd, c-argv, c-argc, PROPAGATE_AOF|PROPAGATE_REPL); } // 步骤2执行命令函数如getCommand c-cmd-proc(c); // 步骤3记录执行后状态用于慢日志、监控 if (flags CMD_CALL_SLOWLOG) logCommandInSlowlog(c); if (flags CMD_CALL_STATS) { c-cmd-microseconds ustime()-start; c-cmd-calls; } }这里的关键是整个call函数的执行是原子的且在单线程内完成。没有锁没有上下文切换没有中断。这意味着对于INCR key从读取旧值、加1、写回新值三步操作不可分割对于EVAL脚本整个Lua沙箱的执行过程也是原子的前提是脚本不调用redis.call(SLEEP,1)这类阻塞命令MULTI/EXEC事务中所有命令被压入队列在EXEC时按顺序逐个call中间不会插入其他客户端的命令。但要注意原子性仅限于命令执行层面不涵盖网络传输。EXEC返回的响应可能被拆分成多个TCP包发送客户端收到的时机取决于网络栈。这也是为什么WATCH需要配合EXEC的返回值判断是否成功——EXEC本身一定原子执行但执行结果成功/失败的传递是异步的。3. 数据生命周期全链路追踪从网络包到内存页每一字节都可控3.1 客户端请求的“入境安检”readQueryFromClient与协议解析当一个TCP包抵达Redis服务器数据并不会直接进入命令执行器。它首先要经过三层“安检”内核协议栈网卡DMA写入ring buffer → 内核TCP协议栈重组报文 → 放入socket receive buffer。Redis I/O层aeApiPoll检测到socket可读 →readQueryFromClient从socket buffer批量读取默认REDIS_IOBUF_LEN16KB→ 数据追加到client-querybuf。协议解析层processInputBuffer扫描querybuf按RESP协议REdis Serialization Protocol解析出完整命令。例如*2\r\n$3\r\nSET\r\n$5\r\nhello\r\n会被拆解为argv[0]SET,argv[1]hello。这个过程中最易被忽视的细节是querybuf是一个动态增长的sdssimple dynamic string结构其内存分配遵循jemalloc的slab规则。当你连续发送100个SET key valuevalue长度1KBquerybuf会从初始48Bsds header逐步扩容每次扩容约1.5倍最终可能占用数MB内存。而这些内存全部计入INFO memory中的used_memory但不属于任何key的数据内存——它是纯临时缓冲区。实操验证在某跨平台系统的压测中我们故意构造大量短连接每个连接只发1个命令观察INFO memoryused_memory128MBused_memory_dataset85MB key-value实际占用used_memory_startup2.1MB 进程启动基础开销差额约41MB几乎全部来自client-querybuf累积。当我们将maxclients从10000降至1000并启用tcp-keepalive 60差额降至5MB以内。注意client-output-buffer-limit参数限制的是client-buf输出缓冲区大小而非querybuf。querybuf的唯一限制是proto-max-bulk-len默认512MB但超出此值会导致协议解析失败返回错误。生产环境建议将其设为业务最大value size的1.2倍避免恶意大包攻击。3.2 数据存储的“内存管家”dict、ziplist、quicklist的协同作战Redis不是把所有数据一股脑塞进哈希表。它根据数据特征和配置在多种底层结构间智能切换目标只有一个在内存占用、访问速度、编码效率间取得最优平衡。以HASH类型为例其编码转换路径为HT哈希表 ⇄ZIPLIST压缩列表 ⇄LISTPACK新版本替代ziplist。触发条件由hash-max-ziplist-entries和hash-max-ziplist-value控制配置项默认值触发条件内存优势访问代价hash-max-ziplist-entries512field数量 ≤ 512每个field无指针开销连续内存布局O(N)查找需遍历整个ziplisthash-max-ziplist-value64单个value长度 ≤ 64B无额外字符串头sdshdr同上当一个HSET user:1001 name zhangsan age 25 city beijing执行时初始创建user:1001由于field数3 512且每个value长度64自动编码为ZIPLIST若后续执行HSET user:1001 bio A very long biography that exceeds sixty four characters...bio长度64触发ZIPLIST→HT转换转换后user:1001的底层结构变为哈希表所有field/value以dictEntry形式存储支持O(1)查找。这个转换过程是惰性且不可逆的一旦升级为HT即使后续删除所有大value也不会降级回ZIPLIST。这是为了规避频繁升降级带来的性能抖动。更精妙的是LIST类型Redis 7.0后弃用ZIPLIST全面转向LISTPACK更紧凑的二进制编码和QUICKLIST双向链表listpack节点。quicklist的每个节点是一个listpack其大小受list-max-listpack-size控制正数表示节点最多含N个entry负数表示节点最大字节数。这种设计让LPUSH/LPOP保持O(1)而LRANGE在小范围查询时仍能利用局部性原理避免全链表遍历。3.3 持久化的“双保险”RDB快照与AOF日志的协作机制Redis提供两种持久化方式它们不是互斥选项而是互补的“冷备热备”组合RDBRedis Database在指定时间点生成内存数据的二进制快照.rdb文件。优点是文件紧凑、恢复快、适合备份缺点是两次快照间的数据丢失save 900 1表示900秒内至少1个key变更才触发。AOFAppend Only File记录所有写命令的文本日志.aof文件。优点是数据丢失少appendfsync everysec最多丢1秒、可读性强缺点是文件大、恢复慢、需定期rewrite。二者协作的关键在于AOF rewrite过程会读取当前内存数据生成一个最小化的、可重放的AOF文件而非简单地复制旧AOF。其流程如下主线程fork子进程子进程遍历所有数据库的dict将每个key-value按*3\r\n$3\r\nSET\r\n$5\r\nkey\r\n$3\r\nval\r\n格式写入临时AOF文件同时主线程将rewrite期间的新写命令同时写入旧AOF和一个AOF重写缓冲区aof_rewrite_buf_blocks子进程完成写入后主线程将aof_rewrite_buf_blocks中的命令追加到新AOF文件末尾原子替换用新AOF文件覆盖旧文件。这个设计确保了新AOF文件 当前内存快照 rewrite期间增量命令绝对一致。而aof_rewrite_buf_blocks的内存占用会实时反映在INFO persistence的aof_rewrite_buffer_length字段中。某次线上事故中我们发现该值持续200MB立即定位到是BGREWRITEAOF被阻塞磁盘IO满及时扩容了SSD。实操心得不要迷信auto-aof-rewrite-percentage。某公司曾设置auto-aof-rewrite-percentage 100AOF体积翻倍时触发但因业务写入模式特殊大量HINCRBY导致AOF膨胀极快rewrite频繁触发反而拖垮性能。最终改用固定时间窗口人工触发配合redis-cli --rdb每日凌晨生成RDB作为冷备AOF仅保留2小时热数据稳定性提升40%。4. 性能瓶颈诊断与优化实战从INFO命令到火焰图精准定位每一毫秒4.1INFO命令的黄金组合读懂12个关键字段的潜台词INFO是Redis的“体检报告”但90%的人只看used_memory和connected_clients。真正有价值的指标藏在细节里。以下是生产环境必须监控的12个字段及其解读字段示例值潜台词排查动作instantaneous_ops_per_sec12450当前QPS若远低于预期检查客户端连接池或网络丢包redis-cli --latency测端到端延迟rejected_connections0拒绝连接数0说明maxclients已达上限CONFIG GET maxclients检查客户端连接泄漏expired_keys234/s每秒过期key数突增可能预示业务逻辑异常如误设短过期redis-cli --scan --pattern *session* | xargs -n 1000 redis-cli ttlevicted_keys0被驱逐key数0说明内存不足触发LRU/LFU淘汰CONFIG GET maxmemoryMEMORY USAGE查大keylatest_fork_usec124500上次fork耗时微秒1000ms需警惕检查系统内存碎片率cat /proc/sys/vm/zone_reclaim_modeaof_delayed_fsync0AOF fsync被延迟次数0说明磁盘IO瓶颈iostat -x 1查%util和awaitmaster_last_io_seconds_ago5主从复制中断秒数0说明网络或从库负载高redis-cli -h slave info replicationclient_longest_output_list12000最长输出缓冲区长度突增可能有客户端消费慢CLIENT LIST找omem0的clientused_memory_peak_perc92.3内存峰值占比持续95%有OOM风险MEMORY DOCTOR获取建议total_commands_processed12450000总命令数结合uptime_in_seconds算平均QPS识别突发流量来源pubsub_channels12Pub/Sub频道数过多可能内存泄漏PUBSUB CHANNELS *loading0是否正在加载RDB/AOF1表示阻塞中加载期间所有命令返回LOADING特别强调latest_fork_usec在某次故障中该值从80000飙升至32000003.2秒INFO stats显示rdb_changes_since_last_save为0但INFO persistence中rdb_bgsave_in_progress为1。我们立刻执行strace -p pid -e traceclone,fork发现fork()系统调用耗时异常进而用cat /proc/pid/status \| grep VmPeak确认进程RSS达16GB而服务器总内存仅32GBvm.swappiness1导致fork()需复制全部页表引发严重延迟。解决方案是升级到Redis 7.0支持copy-on-write优化并调整vm.overcommit_memory1。4.2 慢日志分析不只是SLOWLOG GET更要理解SLOWLOG LEN和SLOWLOG RESETSLOWLOG是Redis的“黑匣子”但默认配置slowlog-log-slower-than 10000slowlog-max-len 128极易遗漏关键信息。真正的分析要三步走扩大采样窗口将slowlog-log-slower-than设为10001ms捕捉所有潜在瓶颈。注意这会增加少量CPU开销但远小于一次KEYS *带来的灾难。延长日志长度slowlog-max-len至少设为1000避免高频慢命令被覆盖。某电商大促期间SLOWLOG LEN返回128但SLOWLOG GET 100显示最后一条是2小时前的HGETALL明显日志已被轮转。关联上下文SLOWLOG GET返回的每条记录包含unix_timestamp、duration_us、command、client_ip、client_name。将unix_timestamp与INFO stats的total_commands_processed对比可计算出该慢命令发生时的QPS水平与INFO clients的connected_clients对比可知是否在连接高峰发生。一次经典案例某支付系统SLOWLOG GET显示大量EVALSHA耗时500ms但Lua脚本本身逻辑简单。我们用redis-cli --eval手动执行相同sha1耗时1ms。最终发现是client-output-buffer-limit pubsub被设为32mb 8mb 60而某个订阅客户端网络卡顿导致pubsub输出缓冲区持续增长EVALSHA执行虽快但响应发送被阻塞在handleClientsWithPendingWrites阶段。解决方案为关键业务通道单独配置CLIENT SETNAME并用CLIENT UNBLOCK主动清理异常客户端。4.3 火焰图实战用perf抓取Redis主线程的CPU热点当INFO和SLOWLOG无法定位问题时perf是终极武器。以下是在CentOS 7上为Redis生成火焰图的标准流程# 步骤1安装依赖 sudo yum install -y perf python3-pip pip3 install flamegraph # 步骤2录制主线程PID12345的CPU调用栈持续30秒 sudo perf record -F 99 -p 12345 -g -- sleep 30 # 步骤3生成火焰图 sudo perf script | stackcollapse-perf.pl | flamegraph.pl redis-flame.svg关键解读技巧顶部宽大的函数块如aeProcessEvents、processCommand、dictFind说明主线程大部分时间花在事件循环和命令处理上malloc/free高频出现指向内存分配瓶颈可能是jemalloc配置不当或大量小对象创建如client-querybuf频繁扩容epoll_wait长时间占据说明网络I/O等待时间长需检查客户端连接数、网络延迟或tcp-backlog设置rioWrite或write函数突出表明输出缓冲区积压client-output-buffer-limit可能过小或客户端消费能力不足。某次压测中火焰图显示dictFind占CPU 35%远高于正常值5%。我们用redis-cli --scan --pattern * \| xargs -n 1000 redis-cli object freq检查key访问频率发现大量__keyspace0__:xxx这类监控key被高频访问。根源是某监控Agent每秒执行KEYS __keyspace0__:*触发全库扫描。解决方案禁用KEYS命令改用SCANOBJECT FREQ组合并对监控key加前缀隔离。5. 常见问题与避坑指南那些文档里不会写的血泪教训5.1 “内存没满却开始驱逐key”——maxmemory的隐藏陷阱maxmemory不是简单的内存阈值开关。当used_memory maxmemory时Redis的驱逐策略maxmemory-policy才会生效。但很多人忽略了used_memory统计的是Redis进程的RSSResident Set Size而maxmemory限制的是Redis管理的数据内存used_memory_dataset。这两者之间存在巨大鸿沟used_memory_dataset所有key-value、客户端缓冲区、AOF缓冲区、Lua脚本缓存等Redis直接管理的内存。used_memoryused_memory_datasetjemalloc元数据 shared memorymmap映射区域 fork()子进程的COWCopy-On-Write页。某次故障中INFO memory显示used_memory: 1073741824 # 1GB used_memory_dataset: 858993459 # 819MB maxmemory: 1073741824 # 1GB按理说used_memory maxmemory应该开始驱逐。但evicted_keys为0INFO stats中keyspace_hits/keyspace_misses比值正常。我们用pstack 12345查看主线程堆栈发现大量malloc调用卡在arena_get。最终定位到jemalloc的arenas数量配置过低MALLOC_CONFnarenas:1在高并发下所有线程争抢同一内存池导致malloc阻塞used_memory统计滞后。解决方案移除自定义MALLOC_CONF让jemalloc自动适配CPU核心数。避坑口诀maxmemory管数据used_memory管进程驱逐看dataset卡顿查malloc。5.2 “BGSAVE失败但INFO persistence显示rdb_bgsave_in_progress:0”——子进程的幽灵状态BGSAVE失败时INFO persistence的rdb_last_bgsave_status会显示err但rdb_bgsave_in_progress仍为0让人误以为没在执行。这是因为BGSAVE命令本身是同步的它只负责fork子进程真正的RDB写入由子进程完成主线程不感知其失败。子进程失败如磁盘满、fork()失败时只会向主线程发送SIGCHLD信号主线程在aeProcessEvents的aeApiPoll之后处理该信号更新rdb_last_bgsave_status。某次部署中BGSAVE返回(error) ERR Background save already in progress但INFO persistence显示rdb_bgsave_in_progress:0。我们用ps aux \| grep redis发现一个僵尸进程[redis-server] defunct。原因是子进程因No space left on device退出但主线程的sigchldHandler未及时处理信号导致僵尸进程残留BGSAVE命令被拒绝。解决方案在redis.conf中添加notify-keyspace-events Ex并监听__keyevent0__:expired事件当收到rdb_start事件时启动一个守护进程监控ps aux \| grep defunct发现僵尸进程立即kill -9其父进程Redis主线程。5.3 “CLIENT LIST里omem0的客户端CLIENT KILL不生效”——输出缓冲区的顽固残留CLIENT KILL命令可以强制断开客户端连接但对omem0输出缓冲区有数据的客户端有时会失效。这是因为CLIENT KILL只是关闭socket而内核TCP栈会尝试重传未确认的ACK包导致连接处于FIN_WAIT2状态缓冲区数据仍在内核buffer中。正确做法是先CLIENT KILL再立即执行CLIENT LIST找到addr相同的客户端可能已重连检查其omem。若仍0说明该客户端是“半死”状态。此时应在客户端侧设置SO_LINGER为0强制close()发送RST包在服务端用netstat -anp \| grep :6379 \| grep FIN_WAIT2定位IP防火墙iptables -A OUTPUT -s ip -j DROP临时拦截。某金融系统曾因此导致client_longest_output_list持续50000INFO clients显示blocked_clients:0但used_memory缓慢上涨。最终发现是某Java客户端使用Jedis未配置setSoLinger(0)close()后连接残留Redis持续向其发送PONG心跳直到TCP超时默认2分钟。5.4 “CONFIG SET修改参数INFO里没变化”——动态配置的生效边界并非所有CONFIG SET都能即时生效。Redis将配置分为三类类型特点示例生效方式Runtime Config修改后立即生效影响所有后续操作maxmemory,timeout,hzCONFIG SET后INFO立即更新Restart Required必须重启Redis才能生效port,bind,requirepassCONFIG SET返回OK但INFO不变需SHUTDOWN后重启Partial Runtime部分生效部分需重启appendonly开启AOF需rewrite关闭可立即停CONFIG SET appendonly yes后AOF日志开始记录但旧AOF文件仍存在最易踩坑的是appendfilename和dirCONFIG SET appendfilename new.aof后新AOF文件名生效但旧AOF文件不会被自动删除。若dir也修改BGREWRITEAOF会写入新目录但主进程仍从旧dir读取AOF启动。某次迁移中运维同学只改了dir未改appendfilename导致Redis启动时找不到appendonly.aof报错退出。正确流程先CONFIG SET dir /new/path再CONFIG SET appendfilename appendonly.aof最后BGREWRITEAOF。实操心得执行CONFIG SET前务必查redis.conf源文件确认该参数是否在“Runtime Config”列表中。不确定时用CONFIG GET param对比修改前后值再执行redis-cli CONFIG REWRITE持久化到配置文件避免重启后丢失。6. 架构演进与未来思考从单机到云原生Redis的底层逻辑从未改变Redis的代码库从2009年发布至今核心事件循环ae.c、命令分发redis.c、内存管理zmalloc.c等模块的架构几乎没有颠覆性改动。aeProcessEvents的主循环逻辑与2012年的v2.4版本几乎一致。这种稳定性不是保守而是对“简单即可靠”哲学的极致践行。当某公司尝试用Go重写Redis核心号称“10倍性能”最终在epoll事件处理和jemalloc内存分配上栽了跟头——Go runtime的GC暂停和goroutine调度开销在超高频小包场景下反而不如C语言的裸指针操作高效。但这不意味着Redis停滞不前。它的演进体现在对现代基础设施的深度适配云原生友好Redis 7.
