Redis性能调优指南

想让 Redis 发挥最佳性能，需要从内存、持久化、系统配置、客户端使用等多个维度进行综合调优。下面这个表格汇总了核心的优化方向和建议，你可以根据它快速抓住重点。
干货分享，感谢阅读

优化维度	核心配置/操作	建议值/策略
内存管理	内存限制 (maxmemory)	设置为物理内存的 70%-80%
	淘汰策略 (maxmemory-policy)	缓存用 allkeys-lru 或 volatile-lru
	数据结构优化	使用 Hash 存储对象；启用 ziplist 编码
	内存碎片整理	启用 activedefrag yes
持久化策略	RDB 配置 (save)	例如 save 900 1
	AOF 配置 (appendfsync)	推荐 everysec
	AOF 重写	auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
系统与网络	系统内核	禁用透明大页 (THP) ；设置 vm.overcommit_memory = 1
	最大连接数 (maxclients)	根据服务器资源调整，例如 10000
	TCP Keepalive (tcp-keepalive)	建议 60 秒或 300 秒
客户端使用	使用连接池	避免频繁创建销毁连接
	使用 Pipeline	批量执行命令，减少网络往返
	避免大 Key 和热 Key	拆分大 Key；对热 Key 使用本地缓存或分片
	避免阻塞命令	使用 SCAN 替代 KEYS

一、 内存管理优化

内存是影响Redis性能最核心的因素。

• 设置内存限制与淘汰策略：务必使用 maxmemory 为Redis设置上限，并根据数据特性选择合适的淘汰策略。例如，如果所有数据都可以丢弃（纯缓存场景），使用 allkeys-lru；如果部分数据设置了TTL且不能丢弃未设置TTL的数据，则使用 volatile-lru 。
• 优化数据结构：用Hash存储一个对象的多个字段，比使用多个String类型的Key能显著减少内存占用。对于小的列表、哈希等结构，Redis可以使用ziplist编码来节省内存，可通过 hash-max-ziplist-entries 等参数控制 。
• 管理内存碎片：操作系统分配和释放内存会产生碎片。如果 INFO memory 命令显示的 mem_fragmentation_ratio（碎片率）持续高于1.5，可以考虑重启实例或启用 activedefrag 让Redis自动整理碎片 。

二、持久化策略优化

持久化方式的选择直接影响Redis的性能和数据安全性。

• RDB与AOF的选择：
  • RDB：在指定时间间隔生成数据快照。恢复速度快，但可能会丢失最后一次快照后的数据。适用于允许少量数据丢失的备份场景 。
  • AOF：记录每一次写操作命令。数据安全性高，通常最多丢失一秒的数据（appendfsync everysec）。文件体积较大，恢复速度慢于RDB 。
  • 混合持久化（Redis 4.0+）：结合两者优点，在AOF文件中同时包含RDB格式的数据和增量AOF日志，兼顾了重启速度和数据安全性 。
• 优化AOF重写：AOF文件会不断增长，因此需要重写以缩小体积。可以调整 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 来控制重写触发的时机，避免过于频繁 。

三、系统与网络配置

Redis的性能也与它所运行的操作系统环境息息相关。

• 系统内核优化：
  • 禁用透明大页 (THP)：THP会导致Redis在持久化fork子进程时出现延迟陡增，强烈建议禁用：echo never > /sys/kernel/mm/transparent_hugepage/enabled 。
  • 设置内存分配策略：设置 vm.overcommit_memory = 1，确保Redis在需要时总能成功申请内存，避免后台保存操作因内存不足而失败 。
• 网络与连接配置：适当调高 maxclients 以避免在高并发场景下连接数被占满。设置合理的 tcp-keepalive 可以及时清理死掉的连接，释放资源 。

四、 客户端使用最佳实践

许多性能问题源于不当的客户端使用方式。

• 使用连接池与Pipeline：使用连接池来复用连接，避免每次操作都经历TCP三次握手和四次挥手 。对于多个连续操作，使用Pipeline批量发送，可以大幅减少网络往返次数（RTT），显著降低延迟 。
• 避免大Key与阻塞命令：
  • 大Key：指Value体积过大（如超过10KB）的Key。这些Key在序列化、网络传输、删除时都会严重阻塞主线程。应将其拆分为多个小Key 。
  • 热Key：指被极高频率访问的Key。可以考虑使用本地缓存或在客户端采用分片策略来分散压力 。
  • 绝对避免在生产环境使用 KEYS * 命令，它的时间复杂度为O(N)，会阻塞所有其他请求。请使用 SCAN 命令进行替代 。

五、监控与问题排查

性能调优不是一劳永逸的，需要持续的监控和分析。

• 利用内置命令监控：定期使用 INFO 命令查看关键指标，如 used_memory（内存使用）、connected_clients（连接数）、instantaneous_ops_per_sec（每秒操作数）和 keyspace_hits/misses（缓存命中率）等 。
• 分析慢查询日志：通过 slowlog-log-slower-than 设置慢查询阈值（如10毫秒），然后使用 SLOWLOG GET 查看哪些命令执行过慢，并针对性地进行优化 。

希望这份详细的指南能帮助你系统地优化Redis性能。如果你能分享更多关于你的业务场景（例如是用作缓存还是数据库、数据量大小、读写比例等），我可以为你提供更具针对性的建议。

这部分之前在约面试的时候可以根据文章上的内容，并用自己的语言组织回答，不需要死记硬背。在实际开发过程中，尽量避免存储大key，因为redis是单线程执行命令行，这一过程可能消耗网络I/O，以及持久化阻塞。