Redis性能问题主要集中在CPU占用高、内存溢出、命令延迟和持久化开销。根本原因包括大Key、热Key、高复杂度命令滥用及配置不当。解决需多管齐下：优化数据结构，避免使用KEYS等阻塞命令，改用SCAN类命令；合理设置maxmemory及淘汰策略如allkeys-lru；开启主动碎片整理activedefrag；采用Pipelining和连接池提升客户端效率；排查网络延迟与系统资源争用；通过SLOWLOG定位慢查询；避免在大内存实例频繁fork导致阻塞；必要时引入Redis Cluster实现分片扩容。
Redis常见的性能问题，说白了，就是那么几类：CPU占用过高、内存吃紧甚至OOM、命令执行慢导致响应延迟，以及持久化操作带来的额外开销。解决这些问题，核心思路无非是优化数据结构和命令使用、合理配置内存策略、调整持久化机制，以及从网络和硬件层面去排查。
解决方案
解决Redis性能问题，需要一套组合拳。首先，从源头抓起，审视你的数据模型和业务逻辑，是不是存在“大Key”或者“热Key”的问题，或者有没有滥用一些高复杂度命令。其次，针对Redis的配置进行精细化调整，比如内存淘汰策略、持久化方式和频率。再者，客户端的使用方式也很关键，连接池、管道（Pipelining）的运用能极大提升效率。最后，别忘了基础设施层面的检查，网络延迟、服务器资源（CPU、内存、IO）瓶颈，这些都可能成为压死骆驼的最后一根稻草。
Redis CPU 占用过高怎么办？
Redis是单线程模型，这既是它的优势，也是潜在的瓶颈。当CPU占用持续飙高时，通常意味着你的Redis实例正在处理一些非常耗时或者计算量大的操作。
在我看来，最常见的原因是用了像
KEYS *这种命令去遍历所有键，或者对一个包含大量元素的集合（Set、Hash、List、ZSet）执行了像
SMEMBERS、
HGETALL、
LRANGE 0 -1这样的操作。这些命令在数据量大的时候，会瞬间把CPU打满。另一个可能的原因是Lua脚本执行时间过长，或者使用了复杂正则表达式的
EVAL命令。
排查起来，
SLOWLOG GET命令简直是神器，它能帮你揪出那些执行时间超过阈值的“罪魁祸首”。一旦发现慢查询，就得分析这些命令为什么慢：是不是操作的数据结构太大了？有没有可能用
SCAN系列命令替代
KEYS或其他全量遍历？比如，遍历大集合时，用
SSCAN、
HSCAN、
ZSCAN替代
SMEMBERS、
HGETALL、
ZRANGE，这样可以分批次进行，避免一次性阻塞Redis。
如果业务场景确实需要处理大量数据，而且单线程Redis已经成为瓶颈，那么考虑数据分片（Sharding）或者搭建Redis Cluster，将数据分散到多个Redis实例上，利用多核CPU的优势，这是一种有效的横向扩展策略。此外，确保你的Redis实例没有运行在虚拟机上，或者如果必须在虚拟机上，也要确保CPU资源是独占的，避免资源争抢。
Redis 内存飙升或OOM了，该如何应对？
内存问题是Redis运维中挺让人头疼的一块。Redis内存飙升，除了数据量确实在增长，还可能是“大Key”问题，或者内存碎片、过期键没有及时清理等原因。最极端的情况就是OOM（Out Of Memory），直接导致服务不可用。
首先，得知道内存到底是怎么用的。
INFO memory命令能给你一个大致的内存使用情况报告，比如
used_memory、
used_memory_rss、
mem_fragmentation_ratio。
redis-cli --bigkeys这个工具能帮你找出那些占用内存过大的键，这是解决大Key问题的利器。
如果发现存在大Key，比如一个Hash里存了几十万个字段，或者一个List里堆了几百万个元素，那就要考虑拆分这些大Key了。比如，把一个大Hash拆分成多个小Hash，或者利用Redis的Stream类型来处理日志流这种无限增长的数据。
内存碎片率（
mem_fragmentation_ratio）如果很高（比如大于1.5），说明内存碎片比较严重，Redis实际占用的物理内存远大于它报告的逻辑内存。Redis 4.0及以上版本提供了
activedefrag yes配置项，可以开启主动内存碎片整理功能，这在某些场景下能有效缓解内存压力。
更重要的，是合理配置
maxmemory和
maxmemory-policy。
maxmemory限制Redis可使用的最大内存，当达到这个阈值时，
maxmemory-policy就会生效，决定如何淘汰键。常用的策略有
allkeys-lru（最近最少使用）、
volatile-lru（只淘汰设置了过期时间的键中最近最少使用的）。选择合适的淘汰策略，能确保Redis在内存不足时，优先清理掉那些“不那么重要”或者“旧”的数据，而不是直接崩溃。
Redis 命令执行慢，响应延迟大怎么排查？
命令执行慢和响应延迟大，这往往是用户直接感知到的性能问题，它可能由多种因素引起，不单单是CPU或内存的问题。
除了前面提到的慢查询（通过
SLOWLOG检查），网络延迟也是一个常见且容易被忽视的因素。客户端和Redis服务器之间的网络距离、中间网络设备的性能、带宽限制，都可能导致命令虽然执行得快，但数据传输来回耗时。这时候，可以尝试在Redis服务器本地执行
redis-cli命令，对比一下响应时间，如果本地很快，远程很慢，那多半是网络问题。
另一个导致延迟的常见原因是Redis的持久化操作。当Redis进行
BGSAVE（后台保存RDB文件）时，会进行一次
fork操作。这个
fork过程在内存很大的情况下可能会耗时几百毫秒甚至几秒，期间Redis主进程会短暂阻塞。AOF持久化如果配置为
appendfsync always，每次写入都同步到磁盘，那IO开销会非常大，导致写入操作延迟。即使是
appendfsync everysec，在IO繁忙时也可能出现周期性的小延迟。
客户端的使用方式也影响巨大。如果你的应用频繁地进行单条命令的读写，而不是利用管道（Pipelining）批量发送命令，那么每次命令的网络往返时间（RTT）都会累加，导致整体吞吐量下降，延迟看起来就高了。Pipelining能显著减少网络往返次数，提高效率。
排查时，除了
SLOWLOG，还可以结合操作系统的工具，比如
top、
iostat、
netstat来观察服务器的CPU、IO、网络状况，看看有没有其他进程抢占资源，或者磁盘IO是否已经达到瓶颈。有时候，问题并不在Redis本身，而在它运行的环境。
