得物 Redis 设计与实践

自建 Redis 系统是得物 DBA 团队自研高性能分布式 KV 缓存系统，目前管理的 ECS 内存总容量超过数十TB，数百多个 Redis 缓存集群实例，数万多个 Redis 数据节点，其中内存规格超过 1T 的大容量集群多个。

自建 Redis 系统采用 Proxy 架构，包含 ConfigServer、Proxy 等核心组件，还包括一个具备实例自动化部署、资源管理、诊断与分析等重要功能在内的完善的自动化运维平台。

本文将从系统架构及核心组件、自建 Redis 支持的重要特性、自动化运维平台的重要功能等多方面为大家介绍自建 Redis 系统。

## 二、自建 Redis 架构及核心组件

自建 Redis 分布式 KV 缓存系统由 ConfigServer、Redis-Proxy、Redis-Server 等核心组件构成，整体架构图如下所示：

![](https://doc.xiqi.site/media/202407/2024-07-26_223941_1387060.2536250411419376.jpeg)

下面为大家逐一介绍自建 Redis 各核心组件支持的重要功能和特性。

## ConfigServer

ConfigServer 是自建 Redis 系统中关键组件之一，跨多可用区多节点部署，采用 Raft 协议实现 ConfigServer 组件高可用；ConfigServer 主要负责三方面职责：

-   负责 Proxy 添加与删除、Group 创建与删除、Redis-Server 实例添加与删除、Redis-Server 实例手动主从切换、水平扩容与数据迁移等功能操作。
-   集群拓扑发生变化时，主动向 Redi-Proxy 更新集群拓扑。
-   负责 Redis-Server 实例故障检测与自动故障转移（主节点故障后自动主从切换）。

**ConfigServer 系统结构图如下所示：**

![](https://doc.xiqi.site/media/202407/2024-07-26_223941_2950880.8752661879043119.jpeg)

每个自建 Redis 集群会对应部署一组独立的 ConfigServer 组件，并且每组 ConfigServer 采用至少三节点部署，分布在三个不同的可用区，保证自建 Redis 系统高可用：

-   ConfigServer 多节点多可用区部署，保证了 ConfigServer 组件自身的高可用。
-   同时，也保证 Redis-Server 的高可用，任意一个可用区故障，剩余 ConfigServer 依然能高效完成 Redis-Server 的宕机判定、选主与故障 Failover。
-   相对于开源 Redis 原生 Cluster 模式，也不会因多数 Redis-Server 主节点故障而无法完成故障判定与 Failover。

### 故障检测与转移

ConfigServer 负责 Redis-Server 节点故障检测与自动故障转移，ConfigServer 会对每一个 Group 的 Master 节点进行定期探活，如果发现某一个 Group 的 Master 节点不可用，就会执行 Failover 流程，选择该 Group 内一个可用的 Slave 节点提升为新的 Master 节点，保证该 Group 可继续对外提供服务。

实现思路参考开源 Redis Sentinel，不过由于 ConfigServer 是 Golang 实现，而开源 Redis Sentinel 是使用 C 语言实现，所以在部分细节上略有不同。

**多协程：**在 Redis Sentinel 中，是在一个单线程中定时检测所有 Redis-Server 节点，而由于 Golang 支持协程，在 ConfigServer 中是为实例的每个 Group 开启一个协程，在协程中定时检测该 Group 对应的 Redis-Server 状态。

**自定义通讯协议：**在 Redis Sentinel 中，Sentinel 之间通过 Redis-Server 节点交换元数据信息，来发现负责同一个 Redis-Server 的 Sentinel 节点，以及交换观察的节点状态；而在 ConfigServer 中，ConfigServer 之间是采用自定义 TCP 协议直接通讯，交换信息更高效，也能缩短故障切换时间。

**故障检测**

-   每个 ConfigServer 定期给该实例的所有 Redis-Server 节点发送 Ping 和 Info 命令，用于检测节点的可用性和发现新的从节点。
-   当 ConfigServer 向 Redis-Server 节点发送命令超时时，将节点标记为主观下线，并传播节点的主观下线状态。
-   ConfigServer Leader 节点发现某节点处于主观下线时，会主动查询其他 ConfigServer 对该节点的状态判定，如果多数 ConfigServer 节点都将该 Redis-Server 节点标记为主观下线，则 Leader 节点将该 Redis 节点标记为客观下线，并发起故障转移流程。

‍

**故障转移**

-   从故障 Redis 主节点的所有从节点中选择一个最优的从节点，选择策略包含：过滤掉不健康的从节点，比如处于主观下线或者客观下线状态。选择 Slave-Priority 最高的从节点。选择复制偏移量最大的从节点。
    
    选择 Runid 最小的从节点。
    
-   将选取出来的从节点提升为新的主节点，即向该节点执行 slaveof no one 命令。
-   将其他从节点设置为新主节点的从节点。
-   并保持对旧主节点的状态关注，如果旧主节点恢复，将旧主节点也更新为新主节点的从节点。

## Redis-Proxy

Redis-Proxy 组件是自建 Redis 系统中的代理服务，负责接受客户端连接，然后转发客户端命令到后端相应的 Redis-Server 节点，使得后端 Redis-Server 集群部署架构对业务透明，Proxy 支持 Redis RESP 协议，业务访问 Proxy 就像访问一个单点 Redis 服务一样，业务可以把一个自建 Redis 集群当作一个容量无限大的单点 Redis 实例即可。

自建 Redis 为每个实例部署一组独立的 Proxy 节点，Proxy 是一个无状态服务，可以很方便的进行水平扩容，提高业务访问自建 Redis 系统的 QPS。

在自建 Redis 中，每个集群可能包含多个 Group，每个 Group 对应一组主从 Redis-Server 节点，每个 Group 负责一部分 Key，同时，整个集群划分为 1024 个槽（slot），每个 Group 负责其中一部分槽（slot），用户写入的 Key 通过以下算法来计算对应的 slot，然后存储到对应节点。

slot 计算公式： slot(key) = crc32(key) % 1024

![](https://doc.xiqi.site/media/202407/2024-07-26_223941_0212850.5440680135631599.jpeg)

Proxy 接收到用户命令后，提取访问的 Key，通过上面同样算法计算相应的 slot，获取负责该 slot 的对应 Redis-Server 实例的连接，再将用户命令转发到对应的 Redis-Server 实例上执行，读取 Redis-Server 返回的结果发送给用户。

DBA 团队针对 Proxy 组件做了大量性能优化，相比市面上开源的支持 Redis RESP 协议的 Proxy 版本，临时对象内存分配减少了约 20 倍，极大的减轻 GC 压力以及 GC 消耗的 CPU；大量短链接场景下，QPS 提升约10%。

同时，自建 Redis-Proxy 还支持同城双活、异步双写等特色功能。

### 同城双活

自建 Redis 为了保证数据的高可用和高可靠，每个 Redis 实例中每个分组采用至少一主一从的部署方案，且主从节点分别部署在不同可用区，在默认的访问模式下，业务读写都访问主节点，从节点仅仅作为热备节点。

为了提升业务在多可用区部署场景下访问缓存性能与降低延迟，以及最大化利用从节点的价值，自建 Redis-Proxy 支持同城双活功能。自建 Redis 同城双活采用**单写就近读**的方案实现，实现原理图如下所示：

![](https://doc.xiqi.site/media/202407/2024-07-26_223941_0773510.2732887464511504.jpeg)

注：需要通过以下方式之一来实现动态配置

-   通过容器的 ServiceName 实现同 AZ Proxy 节点优先访问 **(优先)。**
-   通过云厂商的 PrivateZone 实现智能 DNS 解析(容器和非容器应用都行)。

**Redis-Server**

-   采用至少一主一从的部署方案，并且主从节点跨可用区部署，分别部署在与业务对应的可用区。

**Redis-Proxy**

-   Redis-Proxy 同样采用多可用区部署，与业务可用区相同。
-   各可用区 Proxy 将写请求自动路由到主节点，依然写主节点。
-   读请求优先就近访问本可用区从节点，本可用区无可用从节点时，支持自动访问主节点或优先访问其他可用区从节点。

### 异步双写

针对业务从云 Redis 迁移到自建 Redis、以及大集群拆分场景，对于数据可靠性要求高的业务，Proxy 支持双写功能。

以从云 Redis 迁移到自建 Redis 为例，迁移期间 Proxy 同时写云 Redis 和自建 Redis，保证两边数据实时一致，从而可以随时回滚，做到平滑迁移。

Proxy 双写功能具备以下特性：

-   Proxy 双写功能采用异步双写操作实现，性能优异，双写操作对业务几乎无影响。
-   Proxy 支持转发、只读、双写等多种模式，业务接入自建 Redis 后，自建 Redis 通过在线动态更改配置，平滑的完成整个切换过程，无需业务频繁更改配置或者重启等。
-   Proxy 双写支持云 Redis 优先或者自建 Redis 优先（以云 Redis 迁移为例），且可在线动态调整。
-   同时，提供数据比对工具，用于双写期间数据对比，随时观察两边数据一致性情况；数据对比支持多种策略，包括对比类型、对比长度或元素数量。

## Redis-Server

Redis-Server 组件为开源 Redis 版本基础上，增加槽 slot 同步迁移与异步迁移等相关功能；支持原生开源 Redis 的所有特性，比如支持 String、Hash、List、Set、ZSet 等常用数据结构，AOF 持久化、主从复制、Lua脚本等等。

**Share-Nothing 架构：**自建 Redis 系统中，Redis-Server 服务采用集群化部署，整个集群由多个 Group 共同组成，每个 Group 中包含一主 N 从多个 Redis-Server 实例，**Group 之间的 Redis-Server 节点相互没有通信，为 Share-Nothing 架构**。同时，整个集群划分为 1024 个槽（slot），每个 Group 负责其中一部分槽（slot），用户写入的 Key 通过上面提到的算法来计算对应的 slot，然后存储到负责该 slot 的 Group 中的 Redis-Server 节点上。查询 Key 时，通过同样的算法去对应的节点上查询。

### Async-Fork 特性

在 Redis 中，在 AOF 文件重写、生成 RDB 备份文件以及主从全量同步过程中，都需要使用系统调用 Fork 创建一个子进程来获取内存数据快照，在 Fork() 函数创建子进程的时候，内核会把父进程的「页表」复制一份给子进程，如果页表很大，在现有常见操作系统中，复制页表的过程耗时会非常长，那么在此期间，业务访问 Redis 读写延迟会大幅增加。

自建 Redis 系统中，Redis-Server 通过优化并适配最新的支持 Async-Fork 特性的操作系统，极大的提升 Fork 操作性能：

-   **Fork 命令耗时大幅减小，并且不随数据量增长而增长**，基本稳定在 200 微秒左右；
-   TP100 抖动得到明显改善，TP100 值也不随数据量增长而变大，基本在 1-2 毫秒左右；
-   **相比原生 Redis Fork 耗时减少 98%**。日常运维中，添加从节点、主从切换、RDB 离线分析等常见运维操作均对业务无感知，不会造成业务性能抖动。

![](https://doc.xiqi.site/media/202407/2024-07-26_223941_1546830.08969990680789153.jpeg)

![](https://doc.xiqi.site/media/202407/2024-07-26_223941_0853030.44885185676969097.jpeg)

**注：该图表使用了双纵坐标**

详细内容可阅读[《VLDB 顶会论文 Async-fork 解读与 Redis 实践》](https://link.zhihu.com/?target=https%3A//mp.weixin.qq.com/s%3F__biz%3DMzkxNTE3ODU0NA%3D%3D%26mid%3D2247492721%26idx%3D1%26sn%3D687956fdad5c8263820c2bc3d11f092a%26scene%3D21%23wechat_redirect)。

### 数据迁移

为什么需要做数据迁移？主要是为了水平扩容，自建 Redis 将每个集群实例划分为固定数量的槽 slot，每个 Group 负责一部分槽，当进行水平扩容时，需要重新分配 slot 的分布，并且将一部分 slot 从原有节点迁移到新节点，同时将由 slot 负责的数据一起迁移到新节点。

数据迁移过程包括在源节点将 Key 对应的 Value 使用 Dump 命令进行序列化，然后将数据发送到目标节点，目标节点使用 Restore 命令将 Key 和 Value 存储到本地 Redis 中，最后源节点将该 Key 删除。

自建 Redis 支持同步迁移与异步迁移两种方式。

![](https://doc.xiqi.site/media/202407/2024-07-26_223941_1301060.07488679729041581.jpeg)

![](https://doc.xiqi.site/media/202407/2024-07-26_223943_3746020.512901402621253.jpeg)

**同步迁移**：即在上述整个迁移过程中，源端的 Migrate 命令处于阻塞状态，直到目标端成功加载数据，并且返回成功，源节点删除该 Key 后，Migrate 命令才响应客户端成功。由于 Redis 数据操作是一个单线程模型，所有命令的处理的都在主线程中处理，因此 Migrate 命令会极大地影响其他正常业务的访问。

**异步迁移**：Migrate 命令仅阻塞 Dump 序列化数据、并且异步发送到目标节点，然后即返回客户端成功；目标节点接收到数据后，使用 Restore 命令进行保存，保存成功后，主动给源节点发送一个 ACK 命令，通知源节点将迁移的 Key 删除。异步迁移减少源端 Migrate 命令的阻塞时间，减少了 slot 迁移过程中对业务的影响。

## 三、自动化运维平台

自建 Redis 系统拥有功能完善的自动化运维平台。其主要功能包括：缓存实例自动化部署、快速水平扩容与垂直扩容、多维度资源管理、诊断与分析等。

## 运维平台架构

自建 Redis 自动化运维平台包括Redis 管控平台、Kv-Admin、Kv-Agent、Prometheus 等组件，部署架构如下图所示：

![](https://doc.xiqi.site/media/202407/2024-07-26_223941_0670540.7848321927854807.jpeg)

**Redis 管控平台**

Redis 管控平台是自建 Redis 综合运维管理平台，自建 Redis 的可视化操作均在 Redis 管控平台上完成，包括**实例部署、扩容、数据迁移**等在内的所有日常运维操作均可在管理平台上完成。

**Kv-Admin**

Kv-Admin 是自动化运维平台的核心组件，负责处理所有前端发送过来的请求，核心功能包括：

-   负责完成实例部署时任务调度、机器推荐、端口分配、SLB 推荐与绑定。
-   实例列表展示、实例基本信息查询。
-   数据离线分析与保存。
-   资源池管理及生成资源报表。

**Kv-Agent**

每个 ECS 上会部署一个 Kv-Agent 组件，Kv-Agent 负责完成实例部署、实例启停等操作；基于心跳元数据的 Exporter 自动注册与解除；

同时，Kv-Agent 包含 Exporter 模块，负责 Redis-Server 节点的监控信息采集，然后将数据规范化后通过端点暴露给 Prometheus。

**APM / Prometheus**

APM 监控平台或者 Prometheus 负责从 Exporter 暴露的端点拉取监控数据；自建 Redis 监控与告警均接入公司 APM 平台。

## 实例自动化部署

一个缓存实例的部署非常复杂，涉及机器选择、配置文件准备、节点安装与启动、槽位分配、主从关系设置、SLB 分配与绑定、以及相关组件的部署等一系列动作。

自动化运维平台支持安装包版本管理，在部署页面选择合适的包版本、配置对应实例可用区、规格等基本信息后，一键操作即可完成 ConfigServer、Redis-Proxy、Redis-Server 等组件的部署，自动完成组件部署过程中涉及的上述机器推荐、配置文件准备、节点安装与启动等所有过程。

![](https://doc.xiqi.site/media/202407/2024-07-26_223941_1797970.5763209180387098.jpeg)

为了保证实例中所有组件的高可用，自动化部署过程中包含一些**必要的部署规则**：

-   ConfigServer 组件会部署在三个不同的可用区。
-   避免同一个集群实例的多个 Redis-Server、Redis-Proxy 节点部署在相同的 ECS 上，每个 ECS 上可部署的同一个集群实例的 Server 或 Proxy 组件数量可配置。
-   每个 ECS 最多分配总内存容量的 90%，预留一定的数据增长空间。
-   根据 ECS 可用内存，优先推荐剩余可用内存多的 ECS。
-   根据 Group 数量，自动均衡分配每个 Group 负责的 slot 数量。
-   根据 SLB 近三天的流量峰值，自动绑定最优的 SLB。

## 实例扩容

当业务数据增长导致实例内存使用率超过一定阈值后，根据单节点分配的最大内存、实例的 Group 数量等情况综合考虑，运维可选择为实例进行垂直扩容或者水平扩容。

**垂直扩容**，即动态修改单节点的 Maxmemory 参数，提高单节点的容量。

**水平扩容**，即增加实例的 Group 数量，对应增加主从节点数量，然后重新进行 slot 分配和对应的数据迁移动作。

一般来说，当单节点规格小于 4G 时，会优先考虑垂直扩容，简单快速，对业务无任何影响。

自动化运维平台支持方便的垂直扩容和水平扩容操作。

对于**垂直扩容**，运维平台支持批量调整实例 Redis-Server 节点的容量。

对于**水平扩容**，同实例初始部署一样，运维平台支持新增 Redis-Server 节点的自动化部署、主从关系设置等，同时支持按照实例总节点数重新自动均衡分配每个 Group 负责的 slot 数量，并自动完成数据迁移，数据迁移进度可视化。

## 资源管理

自建 Redis 运维平台目前管理的 ECS 超过数千台，运维平台支持 ECS 资源批量添加、资源分配、资源锁定、资源推荐等资源管理功能，以及提供资源利用率报表。

运维平台支持 ECS 可用内存的管理与分配，运维平台记录每台 ECS 的剩余可分配内存容量，Redis-Server 实例部署时，优先推荐剩余可分配内存多的 ECS，分配出去的 ECS 更新对应的可用内存容量。

Redis-Proxy 和 ConfigServer 部署时，优先推荐部署的实例数量较少的 ECS。

## 诊断与分析

**计算实例综合得分**：运维平台通过分析所有实例关键监控指标前一天的峰值，再根据各项指标的权重，每天自动计算所有实例的得分，根据各实例的得分即可快速了解各实例的使用健康度。

参与计算得分的关键指标包括：Proxy CPU、Redis CPU、Redis 内存使用率、Proxy 占用内存、Proxy GC 次数、最大 RT、Redis 流入流量、Redis 流出流量等。

**慢日志：**运维平台支持 Redis-Server 记录的慢日志和 Redis-proxy 记录的慢日志查询。

**RDB 离线分析：**运维平台支持生成 RDB 文件，并自动进行数据离线分析。分析结果包含 Top100 Value 最大的 Key 和元素个数最多的 Key；每种类型 Key，不同 Key 前缀包含的 Key 数量等。

![](https://doc.xiqi.site/media/202407/2024-07-26_223941_1159140.8345085630378789.jpeg)

## 四、监控与告警

自建 Redis 系统接入 APM 监控平台，提供了各种维度的监控指标和告警功能，及时对异常情况进行预警，当出现问题时，也能帮助快速定位问题。

## 监控

ECS：CPU、系统 Load、内存、网络流量、网络丢包、磁盘 IO 等。

Proxy：QPS、TP999/TP9999/TP100、连接数、CPU、 内存、GC、Goroutine 数量等。

Server：CPU、内存、网络、连接数、QPS、Key 数量、命中率、访问 RT等。

## 告警

自建 Redis 包含大量的告警指标：

-   ECS CPU 使用率、内存使用率、系统 Load（5 分钟平均值）、流量。
-   SLB 流量。
-   Server、Proxy、ConfigServer 节点宕机。
-   主节点缺失从节点、主节点可用区不一致、主从角色切换

## 五、稳定性治理

## 资源隔离

自建 Redis 目前所有组件都是部署在 ECS 上，为了提高资源利用率节约成本，大部分业务域的 Redis 集群都是混布的。自建 Redis 运维平台目前管理 ECS 超过数千台，接入的业务也涵盖营销、风控、算法、投放、社区、大数据等等，每个业务的实例等级、QPS、流量等指标各有差异，少数业务 Redis 可能存在突发写入流量高、Proxy CPU毛刺等现象，可能会引起相同 ECS 上其他实例性能抖动。

**按标签分类：**为了方便资源隔离与资源分配时管理，所有 ECS 资源**按标签进行分类管理**，针对特殊需求业务、大流量实例、通用资源池等划分不同的资源标签，实例部署时选择合适的标签、或者频繁出现告警时调整到对应资源池进行隔离，避免相互影响。

**Proxy CPU 限制：**为了防止单个 Redis-Proxy 进程抢占过多 CPU 资源，Redis-Proxy 支持配置 Golang GOMAXPROCS 参数来设置单个进程允许使用的最大 CPU 核数。

## 巡检

为了提前发现潜在的风险，除了日常告警外，我们支持自动巡检工具和巡检信息页面，建立了定期巡检机制。

**实例综合得分排名：**运维平台通过分析所有实例关键监控指标前一天的峰值，再根据各项指标的权重，每天自动计算所有实例的得分，在巡检信息页面进行展示，通过得分排序即可快速发现风险实例。

![](https://doc.xiqi.site/media/202407/2024-07-26_223940_9884740.8420030539597549.jpeg)

**ECS 资源大盘：**实时展示所有 Redis-Proxy 和 Redis-Server 使用 ECS 的重要指标，通过排序即可快速浏览各 ECS 各项重要指标，如 CPU 使用率、内存使用率、IOPS 使用率、磁盘读取/写入、上传/下载带宽等。

**自动巡检工具：**定期检查所有实例的配置、节点数量等基本信息，对于如从节点缺失、可用区不一致、节点配置不一致等异常情况进行提示。

## 故障演练

为了提高自建 Redis 系统在异常场景下的可用性、检验自建 Redis 系统在各异常场景的恢复时间，我们不定期进行多次故障演练。

故障演练涵盖所有组件在ECS、网络、磁盘等出现故障的场景，以及多个组件组合同时出现这些故障的场景。

经过故障演练检验，自建 Redis 系统 Redis-Server 主节点故障恢复时间 12s，Redis-Proxy 故障业务恢复时间 5s 内。

## 六、总结

本文详细介绍了自建 Redis 架构和现有一些重要特性，我们还在持续不断地迭代优化和丰富支持的特性，为我们的业务提供一个功能更强大、性能更优异的分布式缓存系统。未来我们还会迭代的方向可能包括且不限于：

-   目前 Redis-Server 为了兼容云上版本和分布式架构做了很多定制化，所以未使用最新社区版本，未来会升级到最新的社区版本如 7.0。
-   热 Key 访问一直是 Redis 使用中对业务影响较大的一个问题，未来我们考虑支持热 Key 统计与读热 Key 本地缓存。
-   Golang 版本 Proxy 在高 QPS 请求时，GC 是性能提升的一个瓶颈，未来考虑使用 Rust 重构 Proxy。

‍

\*文 / Miro

本文属得物技术原创，更多精彩文章请看：[得物技术官网](https://link.zhihu.com/?target=https%3A//tech.dewu.com/)

未经得物技术许可严禁转载，否则依法追究法律责任！