一、背景介绍

因为业务规模与流量的继续增长较快。自建 Redis 集群面临更高的性能与稳定性要求，对网站化、自动化运维能力也提出了新的挑战。常见的痛点包括：

• 人工监控和调优成本高，难以快速响应峰值流量。
• 资源利用率低下导致同一物理机上存在多余闲置节点。
• 运维流程繁琐，错误率偏高。

为进一步提高资源利用效率、保障服务稳定运行，并更好地支撑业务发展很快。我们对 Redis 网站进行了自动化能力的建设与升级，通过程序化的网站能力调整，降低人工运维费力度，提高整体运维效率与服务质量。

Redis 使用现状

Redis 集群目前基于 ECS 部署。采用单机多实例、主从混合部署的架构模式，并将 Proxy 组件与数据节点混合部署，以提高 CPU 资源利用率与整体部署密度。当前集群已达到百 TB 级存储规模、数十万数据节点，支撑超大规模业务场景的稳定运行。

面临的挑战和问题

因为业务规模与流量的继续增长。网站在资源效能与运维效率方面面临新的调整空间：

• 机器资源池整体利用率仍有提高空间，需要进一步调整资源调度与负载均衡策略。
• 告警自动化处理覆盖度不足，部分复杂运维场景仍需人工介入；流程效率可进一步调整，
• 缺乏统一的生命周期管理。使得集群扩容/缩容往往手工操作，导致失误和延迟。

集群架构

自建 Redis 由 ConfigServer、Redis-Proxy、Redis-Server 等主要组件构成。说起来，

ConfigServer

• 跨多可用区多节点部署。采用 raft 协议实现 ConfigServer 高可用；负责 Proxy 添加/删除、group 创建/删除、Redis-server 实例管理还有水平扩容与数据迁移等功能操作。
• 负责 Redis-server 实例故障检测与自动故障转移。

Redis-Proxy

代理服务负责接受客户端连接并转发命令到后端相应 Redis-server，使业务透明访问。支持 RESP 协议，让业务可以把自建 Redis 集群当作单点使用。说到痛点，若代理未同步更新，会导致请求路由失效，引发业务中断。

Redis-Server

基于开源 Redis 提高槽同步迁移功能； 支持 String、Hash、List、Set 等结构，AOF 持久化、主从复制等。默认一主一从，可支持多从部署。痛点的观点是，手工管理分片容易出现不一致或热点分布不均的问题。

二、自动化运维能力

资源池自动化均衡调度

当前 Redis 资源池支持按内存使用率、内存分配率和 CPU 使用率进行自动平衡调度，并提供凌晨迁移窗口以提前维护隐患机器。主要流程为合理选择迁移节点，每日生成迁移计划并在凌晨执行。从而降低峰值期间手工干预需求。

迁移 Server 节点选择算法流程图

选择 Server 节点原则

1. 机器选择：

• 筛选内存容量使用率超过阈值的机器；筛选分配率超过阈值的机器；标记需要维护或迁移调整的机器；优先选取实例数量多且非 P0 等级实例；优先从节点，按规格排序，再考虑其他规格；汇总时去除同一组 master 节点避免冲突；不过，对需要维护/调整机器上的 proxy 做版本及标签检查后再决定是否替换或调整权重。

选择 Server 迁移任务流程图

• 生成任务后前端展示，可确认或取消；定时任务执行任务并启动迁移；添加从节点并同步数据，若是 from 节点则直接删除旧实例； 怎么说呢，若是 master 则进行主从切换。 并检查 proxy 拓扑更新，如异常则触发告警。

Migration Proxy 节点选择算法流程图

选择 Proxy 节点原则

1. CVM CPU 峰值高者优先迁出：

• CVM CPU 峰值需采集并排序，高峰者优先迁出至低负载机器直至阈值达标；不过，每台机器每日仅允许迁出固定数量代理，以避免过度扰动网络拓扑；判断 CPU 峰值高数目是否满足阈值后决定是否执行一次迁出操作。

Proxy 迁移任务流程图

• 生成任务后前端展示，可确认或取消；定时执行生成任务，获取原 proxy 版本及标签信息判断是否特殊用途，再部署新 proxy 并绑定 LB；旧 proxy 禁用或调整权重以完成平滑过渡.

收益概述

• 明显提高资源池内存 & CPU 利用率，提高整体使用效率;
• 合理管控超卖率，降低自动扩容失败 & 告警发生;
• 在凌晨低峰期执行调度，实现隐患机器前置治理及节点下线需求快速响应;

---

---