Redis 的性能极高（单机可达 10w+ QPS），但在实际生产环境中，瓶颈通常出现在以下几个层面，其中CPU 单核性能和内存/网络延迟最为常见。
1️⃣ CPU：单线程处理的“甜点与痛点”
- 瓶颈表现：单个 Redis 实例只能使用一个 CPU 核。当请求量极高（如超过 10w QPS）或执行耗时命令（如
KEYS *、大集合的交集运算）时，该核使用率会达到 100%，导致所有请求排队等待。 - 注意：Redis 6.0 后的 I/O 多线程只用于网络读写，命令执行依然是单线程，所以 CPU 单核瓶颈仍然存在。
- 缓解：分片（Redis Cluster）、将耗时命令放到从库或专用节点执行。
2️⃣ 内存：容量、带宽与系统开销
- 物理容量：数据全部在内存，单机内存有限（通常 ≤ 256GB）。超出后要么无法存下，要么触发
OOM。 - 内存带宽：对大 key（如几 MB 的 value）进行高频读写时，内存带宽可能成为瓶颈（尤其是在多实例共享内存通道的物理机上）。
- 内存碎片：频繁更新不同大小的数据会导致碎片率过高（
mem_fragmentation_ratio > 1.5），实际占用远超数据大小。 - 缓解：合理设置
maxmemory和淘汰策略，使用INFO memory监控，必要时重启实例整理碎片。
3️⃣ 网络：吞吐与延迟
- 带宽上限：千兆网卡的理论极限约 125 MB/s。如果单个 value 较大（如 1KB），10w QPS 就能占满带宽。大 key 场景更容易触达网络瓶颈。
- 往返延迟（RTT）：跨机房或长距离访问时，网络延迟本身（例如 10ms）会明显拖累吞吐。此时即使 Redis 处理很快，也受限于网络。
- 缓解：使用 Pipeline 或 Lua 脚本减少 RTT；大 value 考虑压缩或拆分；避免跨地域访问。
4️⃣ 持久化：fork 与磁盘 I/O
- RDB 快照 / AOF 重写：会
fork一个子进程。fork 耗时与内存大小正相关（例如 30GB 内存的实例可能阻塞主线程几百毫秒甚至几秒）。在内存很大且写入频繁时，这个问题尤其突出。 - AOF 追加写入：如果设置
appendfsync always，每个写命令都要刷盘，磁盘 I/O 会急剧拖慢性能。即便用everysec，高负载下也可能导致磁盘写瓶颈。 - 缓解：避免大内存实例（建议 ≤ 20GB）；使用 SSD 并合理配置 AOF 刷盘策略；启用
aof-use-rdb-preamble混合持久化。
💡 如何快速定位你的 Redis 瓶颈？
- CPU：看
redis-cli --stat或INFO CPU，结合系统top观察 redis 进程 CPU 使用率。 - 内存：
INFO memory中的used_memory、mem_fragmentation_ratio。 - 网络：
INFO stats中的total_net_input_bytes / output_bytes结合网卡流量监控。 - 持久化阻塞：
INFO stats中latest_fork_usec是否过大，或看日志中的 “Asynchronous AOF fsync is taking too long”。
总的来说，绝大多数 Redis 瓶颈都不是 Redis 本身慢，而是使用姿势不当（大 key、热 key、复杂命令、持久化配置不合理）或硬件资源受限（单核 CPU 打满、网络带宽不够、磁盘 IO 慢）。针对性优化往往能成倍提升性能。
