Redis性能卡在哪儿了？从哪些方面开始找瓶颈比较靠谱呢

当你发现Redis变慢了，别急着下结论，性能瓶颈就像水管堵塞，得一段段排查，根据Redis官方文档和大量社区实践经验，靠谱的找瓶颈顺序应该是“从外到内，从大到小”。

排除“别人家”的问题。 很多卡顿其实不是Redis本身的错，你得先看看“路”通不通，网络是第一个怀疑对象，一个简单的ping命令看延迟，如果平均超过1毫秒，对于高性能场景就算高了，更实际的是用redis-cli --latency命令，它专门测试到Redis服务器的往返延迟，网络带宽也可能成为瓶颈，特别是当你频繁传输大键（比如几百KB的列表或集合）时，千兆网卡可能瞬间被打满，别忘了客户端本身，如果客户端应用服务器CPU满了，或者发生了Full GC（垃圾回收），它自己处理不过来，也会感觉是Redis慢了,先看看客户端机器的CPU和内存使用情况。

把目光放到Redis服务器这台机器上。 核心就两点：CPU和内存，CPU使用率高不一定有问题，单线程的Redis如果跑满一个核心，说明它真的很忙，但如果你发现CPU系统态（sys）使用率异常高，比如超过20%，那可能就有麻烦了，这常常意味着内核在忙着做两件事：一是处理网络中断，二是进行内存交换（Swap），内存是Redis的重中之重，通过INFO memory命令，重点关注used_memory和used_memory_rss，前者是Redis存数据用了多少，后者是操作系统分配给Redis的总物理内存，如果RSS远大于used_memory（比如超过1.5倍），说明内存碎片很严重，操作系统在“收拾”碎片上花了大量时间，更致命的是Swap，一旦Redis的数据被挤到硬盘上，速度会下降几个数量级，用free命令或cat /proc/<redis-pid>/smaps | grep Swap查看。

深入Redis内部找“慢”操作。 Redis是单线程干活儿（指处理命令的核心模块），所以最怕“一个人霸占厕所”，Redis官方文档强烈建议使用SLOWLOG命令。slowlog-log-slower-than这个参数设个值，比如5毫秒，任何执行时间超过这个阈值的命令都会被记录下来，你就能清楚地看到，是不是有KEYS *这种全表扫描的命令，或者是对一个存了几十万成员的集合执行SMEMBERS，又或者是对大字符串进行修改，除了单个慢命令，还要警惕大量短命令，每个命令都有网络往返和解析的成本，如果可能，用MGET、MSET或Pipeline（管道）批量操作能极大提升效率，持久化操作（RDB快照和AOF重写）虽然由子进程执行，不阻塞主线程，但子进程在生成快照的瞬间（特别是fork操作时）如果内存占用巨大，会导致主线程短暂停顿，观察latest_fork_usec这个指标，如果fork时间很长（比如超过1秒）,就是明确的警告信号。

检查一些常被忽略的角落。 连接数是个隐形杀手，用INFO clients看看connected_clients，如果连接数好几千，甚至上万，单线程花在管理连接上的时间就不可忽视，可能是连接池配置不当，或者有连接泄漏。Key的数量也值得关注。INFO stats里的keyspace告诉你每个数据库有多少key，如果有几百万甚至上千万个key，即使内存不大，管理这些key的元数据本身也会带来开销，看看是否用了效率低下的数据结构，比如该用HSET存对象，却用多个SET来拼凑。

一个比较靠谱的排查路径是：查网络和客户端；2.查服务器CPU、内存（尤其碎片和Swap）；3.用SLOWLOG查内部慢命令和批处理优化；4.查连接数、Key数量和数据结构。 按照这个顺序，由外至内，由浅入深，大部分性能卡顿的元凶都会现形，监控和基准测试是关键，在你感觉“慢”之前,就应该对正常情况下的性能表现心中有数。