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没启用，对称加密部分就会退化成纯软件计算，拖累整体吞吐。
- 先确认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高其实是结果，不是原因。
