小红书缓存服务多云建设之路 - 吴成超

Redis集群现状

• 功能: 标准缓存、内存数据库、数据排序、推荐特征存储、分布式锁等。
• 架构: 采用 Redis Cluster，包含 Master-Slave 结构，使用 Gossip 协议和 16384 个 Slot 进行数据分片。
• 规模: 90 个 Pod，每 Pod 412 QPS，总内存 488 GB，数据量 TB 级别，100% 运行在 Kubernetes 上。

集群编排

• 优势: 运维简单、自动化程度高，屏蔽多云机器差异，复用 K8S 调度能力，方便资源拆借和混部。
• 挑战: IP 漂移、磁盘满导致节点被驱逐、资源碎片、单 K8S 规模过大 (>4000 node)、宿主机快速重启导致数据丢失。

集群编排优化

• 方案: 采用 Gossip 分治、Cluster 功能裁剪、Time Window Rank、全局 Scan 等技术。
• 效果: 内存减少 30.1%，CPU 降低 33.6%，业务报错消失，P99 响应时间从 75-100ms 降至 <20ms。

Redis内核优化

• 优化内容: 搜索词频率 TopN 统计、实时动态刷新、归并计算优化、全局 Scan、Cluster 拓扑缓存、实时大 Key 检测、亚健康节点自动隔离、实时热 Key 检测、Rehash 内存分配异步化等。
• 关键指标: 记录 Key 搜索事件，获取 Top 100 频率，优化后显著提升性能和稳定性。

多云架构演进

• 原因: 单机房故障、单云入口层异常、更强大的灰度和容量管理能力、上海机房资源受限、单供应商议价能力差、地域级故障。
• 演进路径:
  • 同城双活: 上海双机房 (Ping<2ms)，核心业务场景，单机房/专线异常时用户体验不受影响。
  • 跨云多活 1.0: 华东跨省多机房 (Ping:10ms)，业务层单元化改造，核心用户体验不受影响。
  • 跨云多活 2.0: 跨云多机房架构，引入自定义 ReplCmd、Cluster ID 避免循环复制，外部组件检查复制链路。
• 挑战: 链路管理复杂、业务层无法单元化、读多写少、写入 Latency 要求不高、不要求“写后读”。
• 最终方案: 强一致性、强写后读场景，专线带宽管理，异步 RDB 全同步，单机房/专线故障处理预案，双活 VS 三活。