记一次事故看 Redis 开发规范

一、背景

某一天中午，收到反馈，app卡顿甚至无响应，随即监控中心报出大量慢请求。慢请求来源直指网关和 DP（集中鉴权中心）占慢请求总数的 80%以上。

二、事故处理

• 10 分钟，收集事故现场（thread dump，heap dump）重启网关，慢请求暂时恢复 

• 20 分钟，定位为 darkportal 所使用的 redis 集群异常（响应时间 200ms） 

• 30 分钟，分析 redis 和其他业务线共用，会受业务线影响，决定申请新的 redis 实例，将 dp 的 redis 迁移到新集群。

• 24 小时，redis 迁移完成，慢请求消失。

三、Root Cause 分析

24hDP应用的三波慢请求

Redis 响应时间异常

发现 Redis 中大量的慢查询 

通过 slowlog-log-slower-than 等命令查询慢查询，发现大量明令禁止在生产环境使用的命令在这段 时间被执行。

结论

由于darkportal的redis 和其他业务线共用，业务线应用引入了大量的耗时操作，最终引发故障。这 也给我们敲响警钟。

管理角度，梳理核心应用，积极将 redis 等基础组件隔离，敦促业务线加大力度做代码 review。 

运维角度，服务端禁用高危命令，做好中间件和核心接口的监控

四、处理方案

1. 【服务端】服务器端禁用高危险性命令 

rename-command FLUSHALL "" 
rename-command FLUSHDB "" 
rename-command KEYS ""

2. 【客户端】在客户端 SDK 中过滤掉高危命令 

3. 【告警和预防】加大监控力度，尤其是中间件和核心业务接口的监控 

4. 【业务隔离】这次故障另一个关键点是，错误发生在非核心业务，却影响了核心业务，应将核心业务的 redis 独立出来，避免相互干扰和故障的放大，尤其是要避免非核心业务故障对核心业务的影响。（不 仅限于 redis）

五、Redis 开发和使用规范

1.key名设计

1) 【建议】: 可读性和可管理性

以业务名(或数据库名)为前缀(防止 key 冲突)，用冒号分隔，比如业务名:

表名:id
ugc:video:1

2)【建议】：简洁性<