Redis on AEP 实践

背景

由于公司 Redis 实例规模比较大 45000+，使用服务器数量多 2000+，而且使用内存存储成本相比磁盘要高很多，基于 Redis 集群进行现状分析，针对以下集群决定使用傲腾 AEP 存储进行成本优化。

1. 请求量低的小集群非常多，部署比较分散，服务器资源成本高。

2. 大容量集群每次申请 200G 到 2T 容量不等，使用服务器数量多。

傲腾 AEP 上线需要做什么

傲腾 AEP 性能如何

首先性能测试，整体来讲跟纯内存相比有 10%左右的损耗，测试数据如下。目前我们在该机型仅支持小集群、大容量的业务，目前不存在性能问题。

说明：上图为当 Redis 单进程 cpu 负载 80%左右的情况下，在内存和傲腾不同存储上分别运行在不同版本 3.2.11、4.0.12、5.0.8、6.0.5，当 set 命令 value 为 10、100、1000 字节每秒处理请求个数压测结果对比。

说明：上图为当 Redis 单进程 cpu 负载 80%左右的情况下，在内存和傲腾不同存储上分别运行在不同版本 3.2.11、4.0.12、5.0.8、6.0.5，当 get 命令 value 为 10、100、1000 字节每秒处理请求个数压测结果对比。

说明：上图为当 Redis 单进程 cpu 负载 80%左右的情况下，在内存和傲腾不同存储上分别运行在不同版本 3.2.11、4.0.12、5.0.8、6.0.5，当 set 命令 value 为 10、100、1000 字节响应时间分别为 1、2、3、4 毫秒的百分比压测结果对比。

说明：上图为当 Redis 单进程 cpu 负载 80%左右的情况下，在内存和傲腾不同存储上分别运行在不同版本 3.2.11、4.0.12、5.0.8、6.0.5，当 get 命令 value 为 10、100、1000 字节响应时间分别为 1、2、3、4 毫秒的百分比压测结果对比。

密集部署调度是否能打散

1. redis 集群 1 个节点下主从不在同一个机柜组。

2. redis 内存利用率大于 50%不再调度新实例

3. 一个机柜组承载每个集群不超过 25%的实例数。

4. 扩容 k8s 集群中 node 后新增实例的打散依然符合以上规则。

密集部署宕机业务影响范围

1. 业务恢复时间从实例不可用到域名切换完成耗时 20~40s 之间。

2. 拓扑恢复时间完全自动化，DBA 关注进度就好，宕机服务器 500+G 内存恢复需要 30min 左右。

管理方式变更

1).Redis 资源申请

1)目前可以做到 Redis 资源分钟级别交付。

2).增加异常诊断

1)基于 Redis、操作系统，中间件层快速聚合分析到历史时间段的异常指标。生成集群诊断报告。

2)通过获取 Redis 实时 monitor 日志，分析出热点数据，输出热点报表信息。

3).异常处理预案

1)增加了 sentinel 服务异常后宕机批量切换工具。

2)增加了主从同时宕机批量从异地备份机恢复数据的工具。

4).增加集群画像

1)集群列表页关联业务组，划分权限，只显示各自归属集群，方便业务方查看。

2)业务方更详细了解集群基础信息（架构、分片、机房等）和性能信息（访问量、容量等指标的实时统计和天级统计）。

3)基础数据完整和准确，有效实施后续自动化功能建设。

4)实时统计、天级统计信息可定时产出报表，分析低访问量、慢查询多等集群。

5)集群信息完整，出问题时可以快速定位业务方、访问源服务、关联申请原工单、操作类型统计等维度方便排查。

阶段工作成本对比

总结

1）非核心业务可以先上 AEP，如果性能不够再迁移到纯内存服务器上。

2）目前存量小实例继续进行迁移。

密集部署遇到的问题

1).整点 cpu 高，慢日志数量增多，业务出现规律性超时。

原因：

1.每个 docker 容器整点执行收集 Redis 客户端连接，遇到客户端连接多的情况尤为严重。

2.每个 docker 容器整点执行收集 Redis 元信息的任务。

3.每个 docker 容器整点执行 anacron 任务。

解决方案：

1.降低定时任务收集客户端连接的频率。

2.随机打散定时任务的执行时间。

3.去掉不必要的定时任务。

2).sentinel 高可用服务自动切换部分失败。

原因：

1.sentinel 服务线程数不够，丢弃部分待处理任务。

2.sentinel 元信息更新失败问题。

解决方案：

1.优化 sentinel 服务线程数。

2.优化更新 sentinel 元信息的版本控制。

3).sentinel 高可用服务异常切换慢。

原因：

1.异常检测周期长。

2.域名切换耗时高。

解决方案：

1.异常检测周期由原来 30s 降低到 10s。

2.优化域名切换接口索引缺失问题由原来平均 30s 降低到 3s。

4).Redis 负载高，操作系统卡顿。

原因：

1.docker 容器管理 Redis 进程，sentinel-agent 组件沿用物理机部署版本，线程数过高导致操作系统卡。

2.每个 docker 容器部署了 repl-agent 组件。

3.每个 docker 容器的 cadvisor 监控项过多。

解决方案：

1.优化 sentinel-agent 组件降低线程数。

2.下线 repl-agent 弃用组件。

3.优化 cadvisor 监控项数量。

5)./var 目录容量满出现 Redis 所在容器被驱逐。

解决方案：

1.将 coredump 日志记录到较大分区。

2.优化各个分区容量的使用的报警等级。

6).Redis 宿主机重启后二次调度，导致数据异常。

解决方案：

1.任务原因导致的宿主机宕机，自动进行调度隔离。