想让 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在需要时总能成功申请内存，避免后台保存操作因内存不足而失败 。
- 禁用透明大页 (THP) ：THP会导致Redis在持久化fork子进程时出现延迟陡增，强烈建议禁用：
- 网络与连接配置 ：适当调高
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，以及持久化阻塞。