【Redis】—— 借助redis-cluster-proxy实现Kubernetes外部服务无缝访问Redis Cluster

1. Redis Cluster在Kubernetes中的访问困境

Redis Cluster作为分布式缓存解决方案，在Kubernetes环境中部署时会遇到一个典型问题：外部服务如何高效访问集群。传统方案中，客户端需要维护所有节点地址列表，当集群拓扑变化时（如节点扩缩容），客户端配置也需要同步更新。这种强耦合性在动态的Kubernetes环境中会带来显著的运维负担。

我在实际项目中遇到过这样的场景：某电商平台的购物车服务部署在Kubernetes集群外，需要访问集群内的Redis Cluster。最初采用NodePort直接暴露所有Redis节点，结果发现每当集群节点变化时，客户端配置都需要手动调整，导致多次线上故障。更棘手的是，Redis Cluster的重定向机制（MOVED/ASK）要求客户端必须能直接访问Pod IP，这在跨网络环境时几乎不可行。

2. redis-cluster-proxy的核心价值

redis-cluster-proxy的出现完美解决了上述痛点。它相当于在客户端和Redis Cluster之间增加了一个抽象层，对外提供单节点Redis的访问接口，对内自动处理集群路由。实测下来，这种架构带来了三个显著优势：

1. 客户端零改造：应用代码无需任何修改，就像访问普通Redis一样使用集群功能
2. 动态拓扑感知：代理自动维护集群状态，客户端不再关心节点变化
3. 协议完全兼容：支持所有Redis命令，包括事务、管道等高级特性

特别值得一提的是它的连接池设计。每个工作线程维护独立的连接池，默认包含10个到集群节点的预连接。当客户端需要专用连接（如执行MULTI命令时），可以立即从池中获取可用连接，而不是等待新建连接。我们通过以下配置优化了连接池性能：

connections-pool-size 20 connections-pool-min-size 15 connections-pool-spawn-rate 2 connections-pool-spawn-every 500

这表示每个线程池最大20个连接，当连接数低于15时，每500毫秒自动补充2个新连接。在压力测试中，这种配置使95%的专用连接请求都能在1毫秒内获得资源。

3. Kubernetes中的部署实践

3.1 构建代理镜像

由于官方未提供Docker镜像，我们需要自行构建。这里分享一个优化后的Dockerfile：

FROM alpine:3.15 RUN apk add --no-cache build-base git WORKDIR /build RUN git clone https://github.com/RedisLabs/redis-cluster-proxy && \ cd redis-cluster-proxy && \ make PREFIX=/opt/proxy install FROM alpine:3.15 COPY --from=0 /opt/proxy /opt/proxy RUN apk add --no-cache libstdc++ WORKDIR /data ENTRYPOINT ["/opt/proxy/bin/redis-cluster-proxy"]

相比原始文章的CentOS基础镜像，改用Alpine后镜像大小从300MB缩减到15MB。同时采用多阶段构建，确保最终镜像不包含编译工具链。

3.2 Kubernetes资源配置

以下是经过生产验证的部署方案，主要优化点包括：

• 使用Readiness探针确保服务可用性
• 资源限制防止OOM
• 反亲和性避免单点故障

apiVersion: apps/v1 kind: Deployment metadata: name: redis-proxy spec: replicas: 3 selector: matchLabels: app: redis-proxy template: metadata: labels: app: redis-proxy spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: ["redis-proxy"] topologyKey: "kubernetes.io/hostname" containers: - name: proxy image: private-registry/redis-cluster-proxy:v1.1 resources: limits: memory: "512Mi" cpu: "1" readinessProbe: tcpSocket: port: 7777 initialDelaySeconds: 5 periodSeconds: 10 args: ["-c", "/data/proxy.conf"] volumeMounts: - name: config mountPath: /data volumes: - name: config configMap: name: redis-proxy-config --- apiVersion: v1 kind: Service metadata: name: redis-proxy spec: type: LoadBalancer ports: - port: 6379 targetPort: 7777 selector: app: redis-proxy

4. 高级特性与调优建议

4.1 跨槽命令处理

redis-cluster-proxy最亮眼的特性是跨槽命令支持。默认情况下，MGET/MSET等涉及多个key的命令要求所有key必须位于同一槽位。通过启用跨槽功能，可以突破这一限制：

enable-cross-slot yes

但需要注意两点：

1. 原子性丢失：跨节点操作不再具备原子性
2. 性能损耗：需要合并多个节点响应，延迟会增加30-50%

我们在订单服务中实际测试发现，对于100个key的MGET操作，跨槽模式的平均响应时间从12ms增长到18ms，但代码复杂度大幅降低。

4.2 监控与运维

通过PROXY命令可以获取丰富的运行时信息：

# 查看代理状态 PROXY INFO # 获取集群拓扑 PROXY CLUSTER NODES # 动态调整日志级别 PROXY CONFIG SET log-level debug

建议将这些命令集成到监控系统中。我们采用的方案是：

1. 通过cronJob定期执行PROXY INFO
2. 使用Prometheus的textfile exporter采集指标
3. Grafana展示关键指标：连接数、QPS、命令耗时分布

5. 常见问题排查

在实际使用中遇到过几个典型问题：

连接泄漏：某次上线后发现代理内存持续增长。通过PROXY CLIENT LIST发现大量闲置连接，最终确认是客户端未正确关闭连接。解决方案是在配置中添加：

timeout 300 # 自动关闭空闲连接

集群切换卡顿：当主节点故障切换时，部分请求会出现超时。调整以下参数后得到改善：

cluster-reconnection-delay 500 # 重试间隔从默认1s改为500ms refresh-cluster-interval 60 # 主动刷新集群拓扑的间隔

内存突增：大流量下代理出现OOM。分析发现默认的连接池大小不足，调整后稳定运行：

connections-pool-size 30 threads 16 # 根据CPU核心数调整