redis慢的问题定位和分析(转载)

看到一个写的很棒的关于【redis慢的问题定位和分析】
决定把他转过来给更多人分享

业务层面
业务层面主要是开发人员需要关注,也就是开发人员在写业务代码时,如何合理地使用 Redis。
开发人员需要对 Redis 有基本的了解,才能在合适的业务场景使用 Redis,从而避免业务层面导致的延迟问题。

在开发过程中,业务层面的优化建议如下:

  • Key 的长度尽量要短,在数据量非常大时,过长的 Key 名会占用更多的内存。
  • 一定避免存储过大的数据(大 Value),过大的数据在分配内存和释放内存时耗时严重,会阻塞主线程。
  • Redis 4.0 以上建议开启 lazy-free 机制,释放大 Value 时异步操作,不阻塞主线程。
  • 建议设置过期时间,把 Redis 当做缓存使用,尤其在数量很大的时,不设置过期时间会导致内存的无限增长。
  • 不使用复杂度过高的命令,例如 SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE,使用这些命令耗时较久,会阻塞主线程。
  • 查询数据时,一次尽量获取较少的数据,在不确定容器元素个数的情况下,避免使用 LRANGE key 0 -1,ZRANGE key 0 -1 这类操作,应该设置具体查询的元素个数,推荐一次查询 100 个以下元素。
  • 写入数据时,一次尽量写入较少的数据,例如 HSET key value1 value2 value3…,控制一次写入元素的数量,推荐在 100 以下,大数据量分多个批次写入。
  • 批量操作数据时,用 MGET/MSET 替换 GET/SET、HMGET/MHSET 替换 HGET/HSET,减少请求来回的网络 IO 次数,降低延迟,对于没有批量操作的命令,推荐使用 Pipeline,一次性发送多个命令到服务端。
  • 禁止使用 KEYS 命令,需要扫描实例时,建议使用 SCAN,线上操作一定要控制扫描的频率,避免对 Redis 产生性能抖动。
  • 避免某个时间点集中过期大量的 Key,集中过期时推荐增加一个随机时间,把过期时间打散,降低集中过期 Key 时 Redis 的压力,避免阻塞主线程。
  • 根据业务场景,选择合适的淘汰策略,通常随机过期要比 LRU 过期淘汰数据更快。
  • 使用连接池访问 Redis,并配置合理的连接池参数,避免短连接,TCP 三次握手和四次挥手的耗时也很高。
  • 只使用 db0,不推荐使用多个 db,使用多个 db 会增加 Redis 的负担,每次访问不同的 db 都需要执行 SELECT 命令,如果业务线不同,建议拆分多个实例,还能提高单个实例的性能。
  • 读的请求量很大时,推荐使用读写分离,前提是可以容忍从节数据更新不及时的问题。
  • 写请求量很大时,推荐使用集群,部署多个实例分摊写压力。

运维层面
运维层面主要是 DBA 需要关注的,目的是合理规划 Redis 的部署和保障 Redis 的稳定运行

主要优化如下:

  • 不同业务线部署不同的实例,各自独立,避免混用,推荐不同业务线使用不同的机器,根据业务重要程度划分不同的分组来部署,避免某一个业务线出现问题影响其他业务线。
  • 保证机器有足够的 CPU、内存、带宽、磁盘资源,防止负载过高影响 Redis 性能。
  • 以 master-slave 集群方式部署实例,并分布在不同机器上,避免单点,Slave 必须设置为 Readonly。
  • Master 和 Slave 节点所在机器,各自独立,不要交叉部署实例,通常备份工作会在 Slave 上做,做备份时会消耗机器资源,交叉部署会影响到 Master 的性能。
  • 推荐部署哨兵节点增加可用性,节点数量至少 3 个,并分布在不同机器上,实现故障自动故障转移。
  • 提前做好容量规划,一台机器部署实例的内存上限,最好是机器内存的一半,主从全量同步时会占用最多额外一倍的内存空间,防止网络大面积故障引发所有 master-slave 的全量同步导致机器内存被吃光。
  • 做好机器的 CPU、内存、带宽、磁盘监控,在资源不足时及时报警处理,Redis 使用 Swap 后性能急剧下降,网络带宽负载过高访问延迟明显增大,磁盘 IO 过高时开启 AOF 会拖慢 Redis 的性能。
  • 设置最大连接数上限,防止过多的客户端连接导致服务负载过高。
  • 单个实例的使用内存建议控制在 20G 以下,过大的实例会导致备份时间久、资源消耗多,主从全量同步数据时间阻塞时间更长。
  • 设置合理的 slowlog 阈值,推荐 10 毫秒,并对其进行监控,产生过多的慢日志需要及时报警。
  • 设置合理的复制缓冲区 repl-backlog 大小,适当调大 repl-backlog 可以降低主从全量复制的概率。
  • 设置合理的 Slave 节点 client-output-buffer-limit 大小,对于写入量很大的实例,适当调大可以避免主从复制中断问题。
  • 备份时推荐在 Slave 节点上做,不影响 Master 性能。
  • 不开启 AOF 或开启 AOF 配置为每秒刷盘,避免磁盘 IO 消耗降低 Redis 性能。
  • 当实例设置了内存上限,需要调大内存上限时,先调整 Slave 再调整 Master,否则会导致主从节点数据不一致。
  • 对 Redis 增加监控,监控采集 info 信息时,使用长连接,频繁的短连接也会影响 Redis 性能。
  • 线上扫描整个实例数时,记得设置休眠时间,避免扫描时 QPS 突增对 Redis 产生性能抖动。
  • 做好 Redis 的运行时监控,尤其是 expired_keys、evicted_keys、latest_fork_usec 指标,短时间内这些指标值突增可能会阻塞整个实例,引发性能问题。

原文链接:https://www.cnblogs.com/lzghyh/p/13535626.html
如有侵权,请联系本人删除。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值