Envoy Ratelimit 项目中的 Redis Sentinel 高可用配置实践

概述

在分布式系统中，Redis 作为缓存和限流组件的关键存储，其高可用性至关重要。本文将深入探讨在 Kubernetes 环境下为 Envoy Ratelimit 组件配置 Redis Sentinel 高可用方案的最佳实践。

Redis 部署架构分析

当使用 Bitnami Helm Chart 部署 Redis Sentinel 模式时，系统会创建三个关键 Kubernetes 服务对象：

1. ClusterIP 服务：提供对所有 Redis 副本的访问，但由于采用轮询路由，仅适合读取操作
2. Headless 服务：直接暴露所有副本的端点，可用于 Sentinel 配置
3. Master 服务：动态指向当前主节点，在故障转移时自动更新

两种高可用配置方案

方案一：使用 Sentinel 模式

- name: REDIS_TYPE
  value: "sentinel"
- name: REDIS_URL
  value: "mymaster,redis-node-0.redis-headless.namespace.svc.cluster.local:26379,redis-node-1.redis-headless.namespace.svc.cluster.local:26379,redis-node-2.redis-headless.namespace.svc.cluster.local:26379"

特点：

• 直接连接 Sentinel 节点
• 配置中需要明确指定所有 Sentinel 节点地址
• 故障转移时会产生较多连接错误日志
• 完全遵循 Redis Sentinel 标准工作流程

方案二：使用 Master 服务

- name: REDIS_TYPE
  value: "single"
- name: REDIS_URL
  value: "redis-master:6379"

特点：

• 依赖 Kubernetes 服务发现机制
• 配置简单直观
• 故障转移期间同样会有短暂不可用
• 日志输出较为简洁

故障转移性能分析

两种方案在实际测试中均表现出约 4 秒的故障转移恢复时间。这一延迟主要来自：

1. Sentinel 检测主节点失效的判定时间
2. 新主节点选举过程
3. 服务端点更新传播延迟

对于关键业务系统，这一中断时间需要纳入容错设计考虑。

方案选型建议

对于生产环境，建议考虑以下因素：

1. 运维复杂度：Sentinel 模式配置更复杂但更符合 Redis 原生设计
2. 日志管理：Master 服务模式日志更简洁
3. 环境限制：某些 Kubernetes 环境可能对 Headless 服务有特殊限制
4. 监控需求：Sentinel 模式提供更细粒度的监控指标

最佳实践

1. 无论采用哪种方案，都应实施客户端重试机制
2. 监控 Redis 主从状态和 Sentinel 健康状态
3. 定期测试故障转移过程，验证恢复时间是否符合预期
4. 考虑在应用层实现本地缓存，减轻故障转移期间的影响

通过合理配置和运维，可以确保 Envoy Ratelimit 组件在 Redis 故障转移场景下的稳定运行。