现象描述
现象1:出流量指标达到上限。用户收到出流量限流触发告警的消息。
现象2:响应时延变大。
可能原因
由大 Key 引发。
若请求 Key 的 Value 值较大,则易造成出流量过高的问题。
pipelines请求。
Pipeline 技术是把多次请求打包成一次请求发送给数据库服务端处理,在接收完所有命令执行结果后再返回给上层业务。如果一次请求较多,便会造成出流量过高。更多信息,请参见 Redis pipeline 官网介绍。 批量查询,如:mget、hmget 或 hgetall等。
单次批量查询 Key 的数量较多,引起出流量过高。
实例配置规格不足。
业务量上涨,数据量增大,实例配额出流量达到上限,无法满足当前业务流量需求。
解决方法
步骤1:排查大 Key 问题
1. 登录 Redis 控制台,通过数据库智能管家 DBbrain 的诊断优化功能进行大 Key 排查,并创建大 Key 分析任务,根据分析报告,优化大 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
排查业务代码逻辑,建议不使用 pipeline 或者减少每次 pipelines 中的命令请求个数。如果无法确认,请 提交工单 进行排查。 步骤3:排查单次查询 Key 的数量
登录 Redis 控制台,通过数据库智能管家 DBbrain 的诊断优化功能,分析性能指标 Key 请求数量及 mget 请求数的变化趋势,排查是否存在 Key 请求突增的现象。具体操作,请参见 性能趋势。 通常,建议单次操作的 Key 的个数或者元素个数的大小不超过50个。如果 value 比较大,则需要继续减少。
步骤4:升级实例规格
1. 增加副本数量,并开启副本只读,分摊读负载,把当前实例的读请求转移在副本只读节点上,实现读取能力的弹性扩展,改善网络流量性能问题。具体操作,请参见 开关读写分离。 步骤5:调整带宽
如果升级实例规格之后,出流量依然很高,则将带宽调至最大。增加带宽目前免费,具体操作,请参见 带宽调整。
本页内容是否解决了您的问题?