redis 6.0开启tls后cpu满载、qps骤降，主因是未启用会话复用、缺失aes-ni硬件加速及客户端未配合复用；须确认tls-session-caching已启用、openssl验证reused session、grep aes /proc/cpuinfo确认aes-ni支持。

Redis 6.0开启TLS后CPU跑满、QPS断崖下跌，不是配置写错了，而是TLS握手和加解密压垮了单线程主线程——必须直奔三个关键点：会话复用是否生效、AES-NI是否启用、客户端连接模式是否合理。

确认TLS会话复用是否真正启用

Redis默认开启tls-session-caching，但客户端不配合等于白搭。服务端缓存了票据，客户端每次仍走完整握手，非对称运算反复触发，CPU直接飙高。

• 检查服务端配置是否显式启用：tls-session-caching yes、tls-session-cache-size 1000000、tls-session-cache-timeout 300
• 验证客户端是否复用会话：用openssl s_client -connect node:6379 -reconnect -servername node.internal观察输出里是否出现Reused session字样（不是New, TLSv1.3）
• redis-cli默认不复用会话；若用--tls测试，需配合--insecure临时绕过验证，否则可能因证书校验失败误判为握手失败
• Lettuce等Java客户端需显式配置ClientOptions.builder().disallowAllCertificates().build()并启用sessionCache，否则即使服务端开了也没用

验证AES-NI硬件加速是否生效

AES加解密本身极快，慢在ECDSA签名验证、密钥交换这些无法硬件加速的环节。但只要AES-NI没启用，对称加密部分就会退化成纯软件计算，拖累整体吞吐。

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 先确认CPU支持：grep -m1 aes /proc/cpuinfo有输出即支持
• 再看Redis启动日志是否含Using hardware acceleration for AES；若无，说明OpenSSL编译时未启用enable-ec_nistp_64_gcc_128，或系统OpenSSL版本太旧（
• 强制指定高效套件可间接验证：tls-ciphersuites "TLS_AES_256_GCM_SHA384" + tls-protocols "TLSv1.3"；若启用了TLSv1.3却连不上，大概率是客户端OpenSSL版本不匹配，而非服务端问题

区分短连接与长连接场景下的真实瓶颈

短连接（如HTTP请求级调用Redis）下，TLS性能损耗集中在握手阶段，占比可达60%；长连接复用下，损耗通常压到10–20%。别一上来就调优，先确认你的业务属于哪一类。

• 用redis-benchmark -h x.x.x.x -p 6379 -c 100 -n 10000 --tls测试，对比-k 1（keepalive）和-k 0（每请求新建连接）的QPS差异；若后者跌超50%，就是握手开销主导
• top里看redis-server进程CPU高但load average低，基本可锁定为TLS计算密集型负载，不是IO或锁竞争
• 容器/K8s环境里，别盲目上专线或LB TLS卸载——同VPC内延迟 session timeout

最容易被忽略的是：证书SAN字段缺失导致节点间静默握手失败，此时INFO replication显示master_link_status:down，但错误日志里什么都没有。集群通信卡住后，主从同步停滞、ASK重定向失效，所有请求最终都挤在少数可用节点上，CPU高其实是结果，不是原因。