为什么用 IP 直连
客户端连接 Redis 时把域名换成内网 IP，规避的是解析环节引入的不确定性：解析可能慢（DNS 服务器抖动、超时重试），也可能漂移（多 A 记录、缓存到期后换地址），这两种情况在业务侧都先表现成连接超时与重试，看起来像 Redis 出问题。改成 IP 直连后，地址治理交给配置管理或代理层，切换动作变成一次可控的配置下发。
基本信息
| 主要风险 | 解析延迟与解析结果漂移 |
|---|---|
| 建议做法 | 内网客户端使用固定 IP 直连 |
| 例外情况 | 需要统一地址治理时由代理层承担解析 |
| 代价 | 地址进入应用配置，切换依赖配置管理而非 DNS |
| 适用平台 | Linux 自建实例、云托管实例的内网地址（本身即 IP 形态） |
典型使用场景
- 同可用区部署：拓扑稳定，没必要在中间引入一层解析
- 切换演练：地址在配置里可控，切主或切路径一步到位
- 容器环境：集群 DNS 抖动时会拖慢建连，直连地址绕开这条链路
- 压测基线：去掉解析耗时这个变量，多轮结果才可比
- 故障排查：先排除解析因素，再判断是网络还是服务端的问题
对比与排查写法
对比与排查写法
redis-cli -h 10.0.0.12 -p 6379 PING # 直连内网地址，跳过解析
time redis-cli -h cache.internal -p 6379 PING # 域名写法：含解析耗时
time redis-cli -h 10.0.0.12 -p 6379 PING # IP 写法：纯建连与往返
getent hosts cache.internal # 看这台机器实际解析到什么地址
redis-cli -h 10.0.0.12 -p 6379 INFO clients | grep connected_clients两种写法取舍
| 维度 | IP 直连 | 域名 |
|---|---|---|
| 建连开销 | 没有解析步骤 | 每次新建连接都可能触发解析 |
| 切换成本 | 改配置后热加载或重启 | 改记录后受缓存 TTL 拖尾 |
| 可读性 | 靠命名规范与注释表达用途 | 自带语义，交接时更直观 |
| 典型故障表现 | 连接被拒绝或超时 | 解析超时，日志多为解析类报错 |
解析缓存有自己的 TTL：DNS 记录改完后旧地址还会被继续使用一段时间，这段时间的流量可能打到已经下线的节点，切换窗口要把这段拖尾算进去。
IP 直连会让地址散落到各应用的配置文件里，一次迁移就要改动多个系统。把地址收敛到配置中心或代理层并维护清单，否则漏改一处就留下连不上的实例。