阿里云上用Redis访问老慢了，性能优化那些事儿分享一下

Redis本身是内存数据库，速度极快，你觉得慢，十有八九不是Redis本身的问题，而是使用方式或者周边环境出了问题，这就像你买了一台顶级跑车，但开在了坑坑洼洼的乡村小路上，怎么也跑不快，下面我就把常见的“坑”和“填坑”方法捋一捋。

第一方面：先别急着怪Redis，看看是不是“路”的问题——网络。

根据阿里云官方文档和大量用户实践,网络问题是导致访问延迟高的头号嫌疑犯。

1. 检查客户端和Redis实例是否在同一个地域和可用区。 这是最基本也是最容易忽略的一点，如果你的应用服务器（ECS）在上海，而Redis实例在北京，那每个请求都要跨越上千公里，光网络传输就要几十毫秒，这对于期望微秒级响应的Redis来说是不可接受的。优化建议： 务必确保ECS和Redis在同一个地域，甚至同一个可用区（AZ），同可用区内网通信,延迟能降到1毫秒以内。
2. 使用内网连接地址，千万别用公网地址。 阿里云的Redis提供了内网连接地址和外网连接地址，通过公网访问，不仅延迟高、不稳定，还极不安全，带宽也有限制。优化建议： 应用程序的连接配置中，一定要使用阿里云控制台提供的“内网连接地址”。
3. 警惕连接池耗尽和网络带宽打满。 如果你的应用并发很高，连接池设置过小，会导致大量请求排队等待获取连接，这个等待时间就会被算作延迟，同样，如果网络带宽被其他应用占满，Redis的请求也会被阻塞。优化建议： 合理设置客户端连接池参数（如最大连接数、最小空闲连接数），监控Redis实例的网络流入/流出带宽使用率，如果持续高位,需要考虑升级实例规格或排查是否有大Key频繁传输。

第二方面：看看你的“驾驶习惯”好不好——命令使用。

很多时候，慢是因为发送了不该发送的命令,或者用错了方式。

1. 严禁使用KEYS命令。 这是Redis运维手册里用红字标出的禁令。KEYS命令会遍历所有键来匹配模式，在数据量大的时候，会导致Redis单线程阻塞，所有后续命令全部排队，服务瞬间不可用。优化建议： 用SCAN命令代替。SCAN是增量式迭代,不会阻塞服务。
2. 避免“大Key”和“热Key”。
   • 大Key：指一个Key对应的Value非常大，比如一个List存了十万个元素，或者一个String值有几MB，读取或删除这种Key会非常耗时，同样会阻塞进程，在集群模式下，大Key会导致数据分布不均。优化建议： 拆分成多个小的Key,比如一个大Hash可以按业务维度拆成多个小Hash。
   • 热Key：指某个Key在瞬间被超高并发访问，这个Key可能不大，但访问频率极高，会撑满单台Redis服务器的CPU（在集群模式下，一个Key只存在于一个节点），造成瓶颈。优化建议： 使用阿里云Tair（增强版Redis）的特定功能，或者在本机应用层做本地缓存（如Guava Cache）。
3. 多用批量操作，少用循环单条命令。 如果你要获取100个Key的值，用100次GET命令，就会产生100次网络往返（RTT），延迟非常高。优化建议： 使用MGET、MSET、Pipeline（管道）等批量操作，Pipeline能将多个命令打包一次发送，大大减少网络往返次数,是优化高延迟网络的利器。
4. 慎用O(N)复杂度的命令。 比如HGETALL、LRANGE 0 -1、SMEMBERS等，这些命令会一次性获取所有元素，如果Hash、List、Set本身元素很多，操作就会很慢。优化建议： 是否真的需要全部数据？能不能用HSCAN、HGET部分字段？

第三方面：看看“车子”本身的状态——Redis实例配置与监控。

1. 实例规格瓶颈。 你的Redis实例可能真的到了性能瓶颈，CPU使用率持续100%，内存使用率过高（比如超过80%，会导致Swap和逐出策略，影响性能），带宽打满。优化建议： 登录阿里云控制台，查看Redis的监控图表，如果各项指标持续高位，别犹豫，升级实例规格（扩容）是最直接有效的方法。
2. 数据持久化带来的延迟。 无论是RDB快照还是AOF日志，在持久化时都会消耗CPU和磁盘I/O资源，可能会引起短暂的延迟毛刺，特别是AOF配置为appendfsync always（每次写操作都刷盘）时，延迟会显著增加。优化建议： 对于绝大多数业务，使用默认的appendfsync everysec（每秒刷盘）即可,在性能和数据安全间取得平衡。
3. 内存碎片率过高。 频繁的写入和删除会导致内存碎片化，当碎片率过高时（可通过info memory命令查看），Redis整理碎片的过程可能会引起延迟。优化建议： 监控内存碎片率，如果过高，可以尝试重启实例（在业务低峰期）或者升级到更新版本的Redis,其碎片整理机制更优秀。

总结一下排查思路：

当发现Redis慢的时候，别慌,按照从外到内的顺序排查：

1. 网络优先： 检查地域、可用区、内网地址、带宽。
2. 命令次之： 通过Redis的慢查询日志（Slowlog）功能，找出是哪些命令慢，然后分析是否存在KEYS、大Key、不合理批量操作等问题。
3. 资源最后： 查看实例监控，确认CPU、内存、连接数是否达到瓶颈。

优化是一个持续的过程，需要结合监控和日志不断分析和调整，希望这些“那些事儿”能帮你把阿里云上的Redis开回高速路。