现象描述
现象1：出流量指标达到上限。用户收到出流量限流触发告警的消息。
现象2：响应时延变大。
可能原因
由大 Key 引发。
若请求 Key 的 Value 值较大，则易造成出流量过高的问题。
pipelines请求。
Pipeline 技术是把多次请求打包成一次请求发送给数据库服务端处理，在接收完所有命令执行结果后再返回给上层业务。如果一次请求较多，便会造成出流量过高。更多信息，请参见 Redis pipeline 官网介绍。
批量查询，如：mget、hmget 或 hgetall等。
单次批量查询 Key 的数量较多，引起出流量过高。
实例配置规格不足。
业务量上涨，数据量增大，实例配额出流量达到上限，无法满足当前业务流量需求。
解决方法
步骤1：排查大 Key 问题
2. 若存在大 Key，在不影响业务的前提下，减少对大 Key 访问。如果是 value 过大，可以将对象拆分成多个 key-value，将操作压力平摊到多个 Redis 实例；如果是 Key 过多，可以参考 hash 结构存储，将多个 Key 存储在一个 hash 结构中。
说明：
为防止产生大 Key，设计 Value 时，建议参考如下建议。
建议 String 类型控制在10KB以内，hash、list、set、zset 元素个数不要超过5000。
对于非字符串的大 Key，建议使用 hscan、sscan、zscan 渐进式删除。
步骤2：检查业务是否使用了 pipelines
步骤3：排查单次查询 Key 的数量
登录 Redis 控制台，通过数据库智能管家 DBbrain 的诊断优化功能，分析性能指标 Key 请求数量及 mget 请求数的变化趋势，排查是否存在 Key 请求突增的现象。具体操作，请参见 性能趋势。
通常，建议单次操作的 Key 的个数或者元素个数的大小不超过50个。如果 value 比较大，则需要继续减少。
步骤4：升级实例规格
2. 增加分片数量，系统将分配更多的标准带宽。若实例为标准架构，请优先升级标准架构为集群架构，提升 CPU 处理能力。具体操作，请参见 升级实例架构。升级集群架构之前需要检测兼容性，请参见 标准架构迁移集群架构检查。
步骤5：调整带宽
