TLS 的成本构成
TLS 给连接加上握手与逐字节加解密的开销：握手包含证书校验与会话协商，短连接场景下这部分占比很高；用长连接与连接复用把握手摊薄到整个生命周期后，成本主要落在加解密 CPU 上。Redis 6 起原生支持 TLS，服务端与客户端两侧都要配置证书。上线加密前应做加密前后的对照压测，并确认 CPU 留有足够余量。
基本信息
| 成本构成 | 握手（证书校验、会话协商）与数据加解密 CPU |
|---|---|
| 缓解手段 | 连接复用、会话复用、CPU 的加密指令加速 |
| 服务端配置 | tls-port、tls-cert-file、tls-key-file、tls-ca-cert-file |
| 客户端验证 | redis-cli --tls 配合 --cacert、--cert、--key |
| 容量影响 | 吞吐下降、CPU 上升，原容量规划需重算 |
典型使用场景
- 合规要求：等保或行业规范要求链路加密时的标准做法
- 跨不可信网络：业务与实例之间经过公网或共享网络
- 短连接同步：未复用连接时握手成本突出，需要评估是否改造
- 上线前压测：同条件对比加密前后的吞吐与延迟差
- 证书运维：轮换、到期与吊销流程提前准备
加密连接写法
加密连接写法
redis-cli --tls --cacert ./ca.crt --cert ./client.crt --key ./client.key -h redis.internal -p 6380 PING # 双向校验
redis-cli --tls --cacert ./ca.crt -h redis.internal -p 6380 PING # 只校验服务端证书
redis-cli -h redis.internal -p 6379 PING # 明文端口对照，量化差异
redis-cli --tls --cacert ./ca.crt -h redis.internal -p 6380 INFO cpu # 看加密开销落在哪个线程
redis-cli INFO clients | grep connected_clients # 连接数变化场景成本对照
| 场景 | 主要开销 | 缓解方向 |
|---|---|---|
| 短连接加 TLS | 每次建连都完整跑一遍握手 | 改用连接池复用长连接 |
| 长连接加 TLS | 主要是逐条命令的加解密 | 会话复用，用批量命令减少往返 |
| 大批量传输 | 加解密吞吐成为限制 | 关注 CPU 余量与单连接带宽 |
| 混合部署 | 明文与加密实例并存 | 客户端按端口区分，配置集中管理 |
加密带来的吞吐下降与 CPU 上升要写进容量规划：明文时代算出的单实例承载量不能直接沿用，加密后往往需要上调实例数量或规格。
证书轮换流程缺失会在到期当天中断全部连接。把到期时间纳入监控，并在低峰预演一次轮换，确认服务端与客户端两侧都能平滑重启。