接手过好几个线上Redis性能问题之后我的体会是性能优化这件事大部分人一上来就盯参数和命令其实方向就错了。Redis号称单线程扛十万级QPS但真到生产环境延迟抖动、OOM、慢查询、连接被打满乱七八糟的问题一堆。你问它为什么慢它甩给你一段日志看不懂就抓瞎。这篇文章就把我从定位问题到动手优化的完整思路梳理一遍从基线采集、数据结构选型到内存、网络、持久化的调优最后附上排查实录和避坑清单。不管是刚入门的新手还是已经踩过几个坑的开发者照着这个框架走至少能少走半年的弯路。很多人对Redis性能优化有个误解以为调几个参数、换个机器就完事。实际上性能是设计出来的不是调出来的。数据的形状、键的设计、操作的粒度决定了你能跑多快内存策略、持久化配置、网络开销决定了你能稳多久。这篇文章不会只丢给你一堆配置项而是把每个决策背后的逻辑讲透让你以后遇到类似问题自己能判断该往哪个方向查。1. 从基线开始没有数据的优化都是拍脑袋1.1 先回答三个问题拿到任何一个Redis性能问题时我第一件事不是查配置而是先搞清楚三件事当前到底有多慢慢在哪个环节优化之后拿什么证明有效“到底有多慢”不能靠体感。有人说“感觉有点卡”这不算数。你要有数字P99延迟是多少每秒处理多少请求内存碎片率多少慢查询一分钟出现几次没有基线你后面做的任何改动都说不清楚效果甚至可能把问题搞得更隐蔽。“慢在哪个环节”要分层看。客户端到Redis之间的网络、Redis自身处理命令、持久化落盘、主从同步每个环节的瓶颈特征不一样。网络慢是延迟均匀升高命令慢是P99突刺持久化导致的问题是周期性卡顿。先定位层再往下钻。“拿什么证明有效”就是优化前后的对比。我习惯在优化前把baseline记录成一张表延迟均值、P99、P99.9、命中率、内存碎片率、慢查询数量。后面每一步改动都对着一项或几项指标看变化。没有对比的优化都是心理安慰。1.2 手把手建立性能基线Redis自带两个工具足够完成大部分基线采集。第一个是延迟测试直接在服务器上跑redis-cli --intrinsic-latency 100这个命令统计Redis进程内部延迟的分布。参数100表示测试100秒。正常情况下结果里max值应该在微秒级别。如果max出现了毫秒级跳动说明这台机器的CPU调度、内存带宽或虚拟化环境有问题。顺带说一句这个命令测的是本机到Redis进程的延迟不经过网络所以它是排障的第一步——先把服务器本身的底子查干净。第二个是压测工具redis-benchmark我记得常规用法是这样redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -t set,get -P 16-c是并发连接数-n是总请求数-P是pipeline批量数。注意-P设成16的时候测出来的是批量操作的吞吐不代表单条命令的延迟表现报告里的requests per second会虚高。所以压测的时候要分开看单发模式测延迟pipeline模式测吞吐上限。还有一些指标要从INFO里读。执行redis-cli info重点看这几个字段instantaneous_ops_per_sec当前每秒操作数。latency相关的监控项。used_memory_rss / used_memory如果比值高说明内存碎片严重。rejected_connections连接被拒绝的次数。sync_full或主从相关的计数器判断同步是否频繁。另外我强烈建议开启latency monitor这是排查延迟抖动最省事的工具。只要在运行时执行redis-cli CONFIG SET latency-monitor-threshold 100把阈值设成100毫秒之后所有超过100ms的命令都会被记录到延迟事件里用redis-cli --latency-history就能看到时间线。我在几次线上问题里都是靠它抓到“某个时段内大量慢命令”的把柄。注意--intrinsic-latency测的是物理环境--latency-history测的是命令执行事件两者配合能快速区分“机器的问题”和“Redis自身的问题”。2. 数据的形状决定性能数据结构与编码优化2.1 选错类型的代价Redis慢很多时候不是Redis本身慢而是数据结构和访问模式不匹配。最典型的案例用String存了一个很大的JSON每次只需要修改其中的一个字段结果每次都是先GET整个JSON、反序列化、改字段、再序列化、SET回去。一次业务逻辑变成了几十KB的序列化和网络传输吞吐直接被打下去。这类问题的解法通常是拆类型。字段独立、更新频繁的数据用Hash来存每个字段是单独的entry修改一个字段只传输一个field的值需要排序、范围查询的用ZSet别自己搞客户端排序需要去重、判断成员关系的用Set需要先进先出的用List。选类型的核心就一句话让每次命令操作的数据量最小让每个命令匹配你真正的访问模式。还有一种是key设计的问题。比如用时间戳做key的前缀把热点集中在某个分片或某一段连续的key上。虽然Redis集群对key做了哈希分布但如果你所有的key都落在同一个业务前缀下而且访问都集中在某一小段时间还是会造成局部过热。设计key的时候要有意识地加一些随机后缀或业务维度让请求尽量均匀散开。2.2 大key与热key的识别与处理在性能优化领域大key和热key是绕不开的两个问题。先说大key。一个Hash有几万甚至几十万个field一个String存了几MB的图片或文本这就是大key。它的危害不只是占用内存而是每次执行相关命令都可能造成Redis主线程长时间阻塞尤其是删除DEL和导出KEYS/SCAN的时候。识别大key最安全的方式是用redis-cli --bigkeys它会在线上实例做一次scan统计各类数据结构中最大的几个key。注意这里有个坑--bigkeys的原理是遍历整个key空间线上流量高的时候最好在低峰期跑而且它统计的是每类数据结构的top1不代表全貌。发现大key之后处理方案要看数据类型。大的String可以拆成多个小key或者改成Hash存一段一段的大的Hash/Set/ZSet可以用hscan/sscan/zscan分批取数据然后逐步删除如果实在拆不了至少在删除的时候不能用DEL要用UNLINK。Redis 4.0之后UNLINK能异步释放内存不阻塞主线程。这是我见过最容易踩的坑一个几百MB的key一条DEL下去整个实例卡了几秒QPS瞬间掉零。再说热key。某个key每秒被请求几万次单线程的Redis处理这个key的时候其他请求全部排队。识别热key可以用redis-cli --hotkeys需要开启LFU策略或者客户端在访问时做本地计数。处理手段我看过不少最实用的是三个方向一是加本地缓存把热key的值在应用进程内缓存几秒直接砍掉对Redis的访问二是把这个key复制成多份加不同后缀比如key:0到key:9每个副本只承担一部分流量三是拆分key结构把热点分散到多个key上。这三种做法各有利弊本地缓存适合读多写少复制key适合整体热拆结构适合热点集中在某个字段的情况。2.3 内部编码与内存结构从Redis存储的角度讲同一类型的key内部编码还有差异这直接关系到内存效率和访问速度。比如List老的redis版本可能用quicklistPython的list对比不好类比但是你可以理解为是一个压缩的双端链表每个节点里塞一个ziplistHash和ZSet在元素少、值小的情况下会用listpack早期是ziplist把多个entry紧凑排列在一段连续内存里。连续内存带来的好处是两个一是省内存省去了指针的开销二是局部性好遍历速度快。但要注意一旦元素数量或单个元素大小超过阈值Redis会自动从紧凑编码转换成常规的hashtable或skiplist。这个转换是双向不可逆的转换后不会自动转回去直到key被删除。转换过程本身是原子的大对象转换时可能瞬间卡一下。所以我维护线上实例时会有意识地预估每个key的规模让数据尽量保持在紧凑编码的阈值范围内。相关的阈值在redis.conf里通过hash-max-listpack-entries、hash-max-listpack-value这类参数控制。谈到内存碎片这是另一个容易被忽视的点。INFO memory里的mem_fragmentation_ratio如果长期大于1.5说明内存碎片很多。成因为频繁更新、删除大小不一的值导致内存分配器无法回收空洞。我处理过最典型的一个案例一个实例的used_memory只有2GB但RSS占用了6GB直接导致操作系统内存告警。后来在低峰期执行了memory purge仅限jemalloc并重启解决。更建议的做法是从源头入手控制key的更新频率和值大小波动必要时开启activedefrag yes让Redis在后台自动整理碎片。3. 运行时调优内存、连接与网络开销3.1 淘汰策略怎么选内存是有上限的maxmemory设了之后数据到了上限怎么办由淘汰策略决定。很多人的第一反应是选allkeys-lru因为听上去最通用但这常常是性能事故的开端。淘汰策略直接影响命中率而命中率就是性能。noeviction最安全写不进去直接报错虽然不优雅但至少不会静默丢数据allkeys-lru对整个key空间做LRU近似淘汰适合所有key都不分轻重缓急的场景volatile-lru只淘汰带过期时间的key适合把缓存和持久数据混在同一个实例里的场景。实际生产里我见过用allkeys-lfu处理读多写少的热点数据的因为LFU比LRU更能抵御偶发扫描型访问。这里要提醒一个细节maxmemory的取值不是越大越好。如果你给Redis 8GB内存maxmemory设成7GB剩下的1GB是留给操作系统页缓存和内存碎片余量的。踩过最大的坑就是把maxmemory设成了物理内存的上限结果内存碎片涨一点操作系统直接OOM Killer把Redis进程干掉了。我的习惯是maxmemory设为物理内存的70%到80%留足余量再配合监控告警。3.2 连接池和pipelineRedis是单线程处理命令但网络IO和命令执行其实是分开的新版本还有IO多线程不过对于客户端而言连接数的控制依然非常重要。每个连接都有建立和销毁的成本TCP握手加Redis的握手协议一次连接几十微秒就没了。高并发场景下如果客户端每次请求都新建连接光握手就能把Redis拖垮。解决方案就是连接池。连接池的核心参数是最大连接数、最小空闲连接数和获取连接的超时时间。连接池开得太大也没有意义因为Redis单线程处理能力固定你开1000个连接和开200个连接吞吐上限差不多反而连接多了增加上下文切换和内存占用。我之前调过一个服务连接池从1000调到200性能没下降CPU使用率反而降了不少。连接池解决了连接复用pipeline解决的是往返开销。普通模式下客户端发一条命令等一个响应再发下一条每次都要走一次网络RTT。pipeline把多条命令打包到一次请求里服务端处理完后一次性返回。注意pipeline虽然能大幅提升吞吐但它不是无脑用的。一是pipeline里的命令会排队等待处理如果其中一条特别慢后面的都会被拖住二是pipeline打包的命令不宜过大我一般控制在50到100条以内太大反而可能造成网络包分片和内存占用问题。3.3 IO多线程的取舍Redis 6.0引入了IO多线程网上很多人一听就兴奋觉得单线程的瓶颈终于解除了。实际上没那么神。默认情况下IO多线程是关闭的它只处理网络读写命令执行仍然是主线程单线程。打开IO多线程之后网络包的解析和发送可以分散到多个线程这对大流量场景下的网络吞吐有帮助尤其是客户端连接数多、小命令多的时候。开启方式是在redis.conf中设置io-threads 4 io-threads-do-reads yes人话就是4个IO线程负责读写socket主线程继续排队执行命令。注意核心数不多的时候开太多IO线程反而因为线程切换开销导致性能下降我一般建议不超过CPU核心数的一半。再提醒一下IO多线程不是解决慢查询的手段。命令本身慢比如大key的排序、超大hash的遍历该卡还是卡。所以必须先排除慢查询和大key再谈IO多线程优化。4. 持久化不是免费午餐4.1 RDB与AOF的阻塞点Redis性能波动有个很隐蔽的来源持久化。RDB快照生成的时候Redis会fork出一个子进程把内存数据写入磁盘。fork本身在主线程里执行如果内存很大比如20GBfork的瞬间可能卡几百毫秒甚至更久。而且子进程跑RDB时会通过写时复制机制共享内存页如果那个时段写入流量大主线程会被迫复制大量内存页造成CPU和内存带宽的双重压力。AOF的阻塞点不同。AOF是追加写文件本身很快但有两个问题一个是每个写命令都要写系统缓冲区fsync策略如果设为everysec每秒刷一次盘理论上最多丢一秒数据如果设为always每条命令都刷盘性能直接掉一个量级。另一个是AOF文件重写重写期间fork、写临时文件同样有阻塞风险。4.2 合理的持久化配置我从性能和可靠性的平衡角度给一套比较稳的配置组合。第一如果你的Redis是纯缓存场景数据丢了可以从上游重建直接关闭持久化save 、appendonly no性能和内存都是最优的。第二如果是混合场景建议AOF开启appendfsync everysecRDB作为兜底比如每小时一次。第三避免在主库上同时跑RDB和AOF重写尽量错开时间我通常把RDB的定时任务放在业务低峰期AOF重写用auto-aof-rewrite-percentage控制阈值。还有一个大家容易忽略的点不要在主从架构的所有节点上同时执行快照。主库做RDB从库也做RDB两把fork一起发生服务器直接卡死。我处理过一个案例主从同时进入RDB周期主库延迟从1ms飙到800ms持续了十几秒。后来改成从库错峰执行并开启repl-diskless-sync问题才解决。5. 慢查询与阻塞排查实录5.1 慢查询日志怎么读Redis会把超过指定耗时的命令记录到慢查询日志里。配置项是slowlog-log-slower-than单位是微秒。我一般设成1000010ms因为Redis单条命令正常应该在微秒级别超过10ms就要警惕。慢查询队列长度slowlog-max-len设成1024够排查用。查看慢查询用redis-cli slowlog get 10输出里能看到命令、耗时、时间戳和客户端地址。我最常遇到的是两类慢命令一类是KEYS *全库扫描这个命令在Redis官方文档里都直接说不建议生产使用另一类是HGETALL一个大Hash几千个field一次性拉回。解决办法不是优化命令而是改设计——用SCAN代替KEYS用HMGET按需取字段。5.2 常见的阻塞元凶如果慢查询日志里看不到明显的慢命令但延迟还是高就要查阻塞源。常见的阻塞源有这么几类第一过期key的清理。Redis默认每秒做10次过期扫描每次最多清一部分key。如果某个时刻突然有大量key同时过期清理线程会占用主线程时间。解决方法是给key的过期时间加随机偏移比如expire设置成基准值加上一个随机数让过期时间分散开。第二内存页换出。如果系统内存不足Redis的内存页被换到swap访问这些数据的时候会有几十毫秒的延迟。用redis-cli info看used_memory和RSS的差异再看系统的vmstat的si/so。第三CPU争抢。Redis进程被别的进程抢占CPU尤其是同机部署了其他高CPU应用。看top里Redis进程的CPU使用率如果和系统总CPU使用率差距过大就要考虑隔离部署。下面这个表是我平时排查时用的速查表遇到延迟问题直接对照现象可能原因优先排查方向延迟均匀升高网络带宽打满、连接过多看网卡流量查连接数P99突刺大key操作、慢命令slowlog、bigkeys周期性卡顿RDB fork、AOF fsync、过期清理看时间点和持久化配置延迟突然持续高内存换页、CPU争抢vmstat、top延迟在从库更明显主从同步积压看master_repl_offset差距6. 避坑清单我这几年踩过的坑最后分享几个印象最深的教训。第一个教训是不要在生产环境跑KEYS *。有次半夜帮同事排查问题同事说“我就跑一次看看有哪些key”然后整个实例卡了将近三十秒上游服务超时告警一片。后来所有检索类需求都用SCAN并且加COUNT限制。SCAN虽然也可能在游标过程中碰到正在变动的key但至少不阻塞主流程。第二个教训是主从库的内存规格要一致。曾经为了省钱给从库配了比主库小的内存结果主库触发RDB fork之后从库同步数据时内存不够直接OOM主从断开了。从库的内存规格如果比主库小很多问题在同步峰值时才会暴露。第三个教训是优化前一定记得记录基线优化后不要同时改多个参数。我有一次改了淘汰策略又开了IO多线程还调整了连接池结果性能变好了但根本不知道是哪个改动起了作用。之后严格一次只改一个变量对比前一次基线这样每次改动的影响都清清楚楚。第四个教训是关于监控的。Redis的INFO输出里有很多指标但单独看一两项说明不了问题。我后面搭了一套简单的采集每30秒抓一次INFO和slowlog存成历史曲线出问题的时候回放曲线基本上大问题都能定位到分钟级别的时间点。这套东西不需要多复杂的工具一个定时脚本加一个时序数据库就能做到。Redis性能优化做到最后你会发现拼的其实是两件事一是对数据结构的理解二是在生产中长期积累的排障直觉。前者靠学后者只能靠踩坑。希望这篇文章能让你在遇到性能问题时有一个明确的排查起点而不是在一堆参数面前发懵。 
长河君 · 2026/10/16 9:06:01 · 阅读 1.2k Redis性能优化实战：从基线采集到避坑清单的完整指南
接手过好几个线上Redis性能问题之后我的体会是性能优化这件事大部分人一上来就盯参数和命令其实方向就错了。Redis号称单线程扛十万级QPS但真到生产环境延迟抖动、OOM、慢查询、连接被打满乱七八糟的问题一堆。你问它为什么慢它甩给你一段日志看不懂就抓瞎。这篇文章就把我从定位问题到动手优化的完整思路梳理一遍从基线采集、数据结构选型到内存、网络、持久化的调优最后附上排查实录和避坑清单。不管是刚入门的新手还是已经踩过几个坑的开发者照着这个框架走至少能少走半年的弯路。很多人对Redis性能优化有个误解以为调几个参数、换个机器就完事。实际上性能是设计出来的不是调出来的。数据的形状、键的设计、操作的粒度决定了你能跑多快内存策略、持久化配置、网络开销决定了你能稳多久。这篇文章不会只丢给你一堆配置项而是把每个决策背后的逻辑讲透让你以后遇到类似问题自己能判断该往哪个方向查。1. 从基线开始没有数据的优化都是拍脑袋1.1 先回答三个问题拿到任何一个Redis性能问题时我第一件事不是查配置而是先搞清楚三件事当前到底有多慢慢在哪个环节优化之后拿什么证明有效“到底有多慢”不能靠体感。有人说“感觉有点卡”这不算数。你要有数字P99延迟是多少每秒处理多少请求内存碎片率多少慢查询一分钟出现几次没有基线你后面做的任何改动都说不清楚效果甚至可能把问题搞得更隐蔽。“慢在哪个环节”要分层看。客户端到Redis之间的网络、Redis自身处理命令、持久化落盘、主从同步每个环节的瓶颈特征不一样。网络慢是延迟均匀升高命令慢是P99突刺持久化导致的问题是周期性卡顿。先定位层再往下钻。“拿什么证明有效”就是优化前后的对比。我习惯在优化前把baseline记录成一张表延迟均值、P99、P99.9、命中率、内存碎片率、慢查询数量。后面每一步改动都对着一项或几项指标看变化。没有对比的优化都是心理安慰。1.2 手把手建立性能基线Redis自带两个工具足够完成大部分基线采集。第一个是延迟测试直接在服务器上跑redis-cli --intrinsic-latency 100这个命令统计Redis进程内部延迟的分布。参数100表示测试100秒。正常情况下结果里max值应该在微秒级别。如果max出现了毫秒级跳动说明这台机器的CPU调度、内存带宽或虚拟化环境有问题。顺带说一句这个命令测的是本机到Redis进程的延迟不经过网络所以它是排障的第一步——先把服务器本身的底子查干净。第二个是压测工具redis-benchmark我记得常规用法是这样redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 100000 -t set,get -P 16-c是并发连接数-n是总请求数-P是pipeline批量数。注意-P设成16的时候测出来的是批量操作的吞吐不代表单条命令的延迟表现报告里的requests per second会虚高。所以压测的时候要分开看单发模式测延迟pipeline模式测吞吐上限。还有一些指标要从INFO里读。执行redis-cli info重点看这几个字段instantaneous_ops_per_sec当前每秒操作数。latency相关的监控项。used_memory_rss / used_memory如果比值高说明内存碎片严重。rejected_connections连接被拒绝的次数。sync_full或主从相关的计数器判断同步是否频繁。另外我强烈建议开启latency monitor这是排查延迟抖动最省事的工具。只要在运行时执行redis-cli CONFIG SET latency-monitor-threshold 100把阈值设成100毫秒之后所有超过100ms的命令都会被记录到延迟事件里用redis-cli --latency-history就能看到时间线。我在几次线上问题里都是靠它抓到“某个时段内大量慢命令”的把柄。注意--intrinsic-latency测的是物理环境--latency-history测的是命令执行事件两者配合能快速区分“机器的问题”和“Redis自身的问题”。2. 数据的形状决定性能数据结构与编码优化2.1 选错类型的代价Redis慢很多时候不是Redis本身慢而是数据结构和访问模式不匹配。最典型的案例用String存了一个很大的JSON每次只需要修改其中的一个字段结果每次都是先GET整个JSON、反序列化、改字段、再序列化、SET回去。一次业务逻辑变成了几十KB的序列化和网络传输吞吐直接被打下去。这类问题的解法通常是拆类型。字段独立、更新频繁的数据用Hash来存每个字段是单独的entry修改一个字段只传输一个field的值需要排序、范围查询的用ZSet别自己搞客户端排序需要去重、判断成员关系的用Set需要先进先出的用List。选类型的核心就一句话让每次命令操作的数据量最小让每个命令匹配你真正的访问模式。还有一种是key设计的问题。比如用时间戳做key的前缀把热点集中在某个分片或某一段连续的key上。虽然Redis集群对key做了哈希分布但如果你所有的key都落在同一个业务前缀下而且访问都集中在某一小段时间还是会造成局部过热。设计key的时候要有意识地加一些随机后缀或业务维度让请求尽量均匀散开。2.2 大key与热key的识别与处理在性能优化领域大key和热key是绕不开的两个问题。先说大key。一个Hash有几万甚至几十万个field一个String存了几MB的图片或文本这就是大key。它的危害不只是占用内存而是每次执行相关命令都可能造成Redis主线程长时间阻塞尤其是删除DEL和导出KEYS/SCAN的时候。识别大key最安全的方式是用redis-cli --bigkeys它会在线上实例做一次scan统计各类数据结构中最大的几个key。注意这里有个坑--bigkeys的原理是遍历整个key空间线上流量高的时候最好在低峰期跑而且它统计的是每类数据结构的top1不代表全貌。发现大key之后处理方案要看数据类型。大的String可以拆成多个小key或者改成Hash存一段一段的大的Hash/Set/ZSet可以用hscan/sscan/zscan分批取数据然后逐步删除如果实在拆不了至少在删除的时候不能用DEL要用UNLINK。Redis 4.0之后UNLINK能异步释放内存不阻塞主线程。这是我见过最容易踩的坑一个几百MB的key一条DEL下去整个实例卡了几秒QPS瞬间掉零。再说热key。某个key每秒被请求几万次单线程的Redis处理这个key的时候其他请求全部排队。识别热key可以用redis-cli --hotkeys需要开启LFU策略或者客户端在访问时做本地计数。处理手段我看过不少最实用的是三个方向一是加本地缓存把热key的值在应用进程内缓存几秒直接砍掉对Redis的访问二是把这个key复制成多份加不同后缀比如key:0到key:9每个副本只承担一部分流量三是拆分key结构把热点分散到多个key上。这三种做法各有利弊本地缓存适合读多写少复制key适合整体热拆结构适合热点集中在某个字段的情况。2.3 内部编码与内存结构从Redis存储的角度讲同一类型的key内部编码还有差异这直接关系到内存效率和访问速度。比如List老的redis版本可能用quicklistPython的list对比不好类比但是你可以理解为是一个压缩的双端链表每个节点里塞一个ziplistHash和ZSet在元素少、值小的情况下会用listpack早期是ziplist把多个entry紧凑排列在一段连续内存里。连续内存带来的好处是两个一是省内存省去了指针的开销二是局部性好遍历速度快。但要注意一旦元素数量或单个元素大小超过阈值Redis会自动从紧凑编码转换成常规的hashtable或skiplist。这个转换是双向不可逆的转换后不会自动转回去直到key被删除。转换过程本身是原子的大对象转换时可能瞬间卡一下。所以我维护线上实例时会有意识地预估每个key的规模让数据尽量保持在紧凑编码的阈值范围内。相关的阈值在redis.conf里通过hash-max-listpack-entries、hash-max-listpack-value这类参数控制。谈到内存碎片这是另一个容易被忽视的点。INFO memory里的mem_fragmentation_ratio如果长期大于1.5说明内存碎片很多。成因为频繁更新、删除大小不一的值导致内存分配器无法回收空洞。我处理过最典型的一个案例一个实例的used_memory只有2GB但RSS占用了6GB直接导致操作系统内存告警。后来在低峰期执行了memory purge仅限jemalloc并重启解决。更建议的做法是从源头入手控制key的更新频率和值大小波动必要时开启activedefrag yes让Redis在后台自动整理碎片。3. 运行时调优内存、连接与网络开销3.1 淘汰策略怎么选内存是有上限的maxmemory设了之后数据到了上限怎么办由淘汰策略决定。很多人的第一反应是选allkeys-lru因为听上去最通用但这常常是性能事故的开端。淘汰策略直接影响命中率而命中率就是性能。noeviction最安全写不进去直接报错虽然不优雅但至少不会静默丢数据allkeys-lru对整个key空间做LRU近似淘汰适合所有key都不分轻重缓急的场景volatile-lru只淘汰带过期时间的key适合把缓存和持久数据混在同一个实例里的场景。实际生产里我见过用allkeys-lfu处理读多写少的热点数据的因为LFU比LRU更能抵御偶发扫描型访问。这里要提醒一个细节maxmemory的取值不是越大越好。如果你给Redis 8GB内存maxmemory设成7GB剩下的1GB是留给操作系统页缓存和内存碎片余量的。踩过最大的坑就是把maxmemory设成了物理内存的上限结果内存碎片涨一点操作系统直接OOM Killer把Redis进程干掉了。我的习惯是maxmemory设为物理内存的70%到80%留足余量再配合监控告警。3.2 连接池和pipelineRedis是单线程处理命令但网络IO和命令执行其实是分开的新版本还有IO多线程不过对于客户端而言连接数的控制依然非常重要。每个连接都有建立和销毁的成本TCP握手加Redis的握手协议一次连接几十微秒就没了。高并发场景下如果客户端每次请求都新建连接光握手就能把Redis拖垮。解决方案就是连接池。连接池的核心参数是最大连接数、最小空闲连接数和获取连接的超时时间。连接池开得太大也没有意义因为Redis单线程处理能力固定你开1000个连接和开200个连接吞吐上限差不多反而连接多了增加上下文切换和内存占用。我之前调过一个服务连接池从1000调到200性能没下降CPU使用率反而降了不少。连接池解决了连接复用pipeline解决的是往返开销。普通模式下客户端发一条命令等一个响应再发下一条每次都要走一次网络RTT。pipeline把多条命令打包到一次请求里服务端处理完后一次性返回。注意pipeline虽然能大幅提升吞吐但它不是无脑用的。一是pipeline里的命令会排队等待处理如果其中一条特别慢后面的都会被拖住二是pipeline打包的命令不宜过大我一般控制在50到100条以内太大反而可能造成网络包分片和内存占用问题。3.3 IO多线程的取舍Redis 6.0引入了IO多线程网上很多人一听就兴奋觉得单线程的瓶颈终于解除了。实际上没那么神。默认情况下IO多线程是关闭的它只处理网络读写命令执行仍然是主线程单线程。打开IO多线程之后网络包的解析和发送可以分散到多个线程这对大流量场景下的网络吞吐有帮助尤其是客户端连接数多、小命令多的时候。开启方式是在redis.conf中设置io-threads 4 io-threads-do-reads yes人话就是4个IO线程负责读写socket主线程继续排队执行命令。注意核心数不多的时候开太多IO线程反而因为线程切换开销导致性能下降我一般建议不超过CPU核心数的一半。再提醒一下IO多线程不是解决慢查询的手段。命令本身慢比如大key的排序、超大hash的遍历该卡还是卡。所以必须先排除慢查询和大key再谈IO多线程优化。4. 持久化不是免费午餐4.1 RDB与AOF的阻塞点Redis性能波动有个很隐蔽的来源持久化。RDB快照生成的时候Redis会fork出一个子进程把内存数据写入磁盘。fork本身在主线程里执行如果内存很大比如20GBfork的瞬间可能卡几百毫秒甚至更久。而且子进程跑RDB时会通过写时复制机制共享内存页如果那个时段写入流量大主线程会被迫复制大量内存页造成CPU和内存带宽的双重压力。AOF的阻塞点不同。AOF是追加写文件本身很快但有两个问题一个是每个写命令都要写系统缓冲区fsync策略如果设为everysec每秒刷一次盘理论上最多丢一秒数据如果设为always每条命令都刷盘性能直接掉一个量级。另一个是AOF文件重写重写期间fork、写临时文件同样有阻塞风险。4.2 合理的持久化配置我从性能和可靠性的平衡角度给一套比较稳的配置组合。第一如果你的Redis是纯缓存场景数据丢了可以从上游重建直接关闭持久化save 、appendonly no性能和内存都是最优的。第二如果是混合场景建议AOF开启appendfsync everysecRDB作为兜底比如每小时一次。第三避免在主库上同时跑RDB和AOF重写尽量错开时间我通常把RDB的定时任务放在业务低峰期AOF重写用auto-aof-rewrite-percentage控制阈值。还有一个大家容易忽略的点不要在主从架构的所有节点上同时执行快照。主库做RDB从库也做RDB两把fork一起发生服务器直接卡死。我处理过一个案例主从同时进入RDB周期主库延迟从1ms飙到800ms持续了十几秒。后来改成从库错峰执行并开启repl-diskless-sync问题才解决。5. 慢查询与阻塞排查实录5.1 慢查询日志怎么读Redis会把超过指定耗时的命令记录到慢查询日志里。配置项是slowlog-log-slower-than单位是微秒。我一般设成1000010ms因为Redis单条命令正常应该在微秒级别超过10ms就要警惕。慢查询队列长度slowlog-max-len设成1024够排查用。查看慢查询用redis-cli slowlog get 10输出里能看到命令、耗时、时间戳和客户端地址。我最常遇到的是两类慢命令一类是KEYS *全库扫描这个命令在Redis官方文档里都直接说不建议生产使用另一类是HGETALL一个大Hash几千个field一次性拉回。解决办法不是优化命令而是改设计——用SCAN代替KEYS用HMGET按需取字段。5.2 常见的阻塞元凶如果慢查询日志里看不到明显的慢命令但延迟还是高就要查阻塞源。常见的阻塞源有这么几类第一过期key的清理。Redis默认每秒做10次过期扫描每次最多清一部分key。如果某个时刻突然有大量key同时过期清理线程会占用主线程时间。解决方法是给key的过期时间加随机偏移比如expire设置成基准值加上一个随机数让过期时间分散开。第二内存页换出。如果系统内存不足Redis的内存页被换到swap访问这些数据的时候会有几十毫秒的延迟。用redis-cli info看used_memory和RSS的差异再看系统的vmstat的si/so。第三CPU争抢。Redis进程被别的进程抢占CPU尤其是同机部署了其他高CPU应用。看top里Redis进程的CPU使用率如果和系统总CPU使用率差距过大就要考虑隔离部署。下面这个表是我平时排查时用的速查表遇到延迟问题直接对照现象可能原因优先排查方向延迟均匀升高网络带宽打满、连接过多看网卡流量查连接数P99突刺大key操作、慢命令slowlog、bigkeys周期性卡顿RDB fork、AOF fsync、过期清理看时间点和持久化配置延迟突然持续高内存换页、CPU争抢vmstat、top延迟在从库更明显主从同步积压看master_repl_offset差距6. 避坑清单我这几年踩过的坑最后分享几个印象最深的教训。第一个教训是不要在生产环境跑KEYS *。有次半夜帮同事排查问题同事说“我就跑一次看看有哪些key”然后整个实例卡了将近三十秒上游服务超时告警一片。后来所有检索类需求都用SCAN并且加COUNT限制。SCAN虽然也可能在游标过程中碰到正在变动的key但至少不阻塞主流程。第二个教训是主从库的内存规格要一致。曾经为了省钱给从库配了比主库小的内存结果主库触发RDB fork之后从库同步数据时内存不够直接OOM主从断开了。从库的内存规格如果比主库小很多问题在同步峰值时才会暴露。第三个教训是优化前一定记得记录基线优化后不要同时改多个参数。我有一次改了淘汰策略又开了IO多线程还调整了连接池结果性能变好了但根本不知道是哪个改动起了作用。之后严格一次只改一个变量对比前一次基线这样每次改动的影响都清清楚楚。第四个教训是关于监控的。Redis的INFO输出里有很多指标但单独看一两项说明不了问题。我后面搭了一套简单的采集每30秒抓一次INFO和slowlog存成历史曲线出问题的时候回放曲线基本上大问题都能定位到分钟级别的时间点。这套东西不需要多复杂的工具一个定时脚本加一个时序数据库就能做到。Redis性能优化做到最后你会发现拼的其实是两件事一是对数据结构的理解二是在生产中长期积累的排障直觉。前者靠学后者只能靠踩坑。希望这篇文章能让你在遇到性能问题时有一个明确的排查起点而不是在一堆参数面前发懵。