江苏龙网

  1. 主页 > 生活百科 > >

Redis常见延迟问题排查手册！附优化建议( 四 )

Redis


如果确实使用到了Swap，要及时整理内存空间，释放出足够的内存供Redis使用，然后释放Redis的Swap，让Redis重新使用内存 。
释放Redis的Swap过程通常要重启实例，为了避免重启实例对业务的影响，一般先进行主从切换，然后释放旧主节点的Swap，重新启动服务，待数据同步完成后，再切换回主节点即可 。
可见，当Redis使用到Swap后，此时的Redis的高性能基本被废掉，所以我们需要提前预防这种情况 。
我们需要对Redis机器的内存和Swap使用情况进行监控，在内存不足和使用到Swap时及时报警出来，及时进行相应的处理 。
网卡负载过高
如果以上产生性能问题的场景，你都规避掉了，而且Redis也稳定运行了很长时间，但在某个时间点之后开始，访问Redis开始变慢了，而且一直持续到现在，这种情况是什么原因导致的？
之前我们就遇到这种问题，特点就是从某个时间点之后就开始变慢，并且一直持续 。这时你需要检查一下机器的网卡流量，是否存在网卡流量被跑满的情况 。
网卡负载过高，在网络层和TCP层就会出现数据发送延迟、数据丢包等情况 。Redis的高性能除了内存之外，就在于网络IO，请求量突增会导致网卡负载变高 。
如果出现这种情况，你需要排查这个机器上的哪个Redis实例的流量过大占满了网络带宽，然后确认流量突增是否属于业务正常情况，如果属于那就需要及时扩容或迁移实例，避免这个机器的其他实例受到影响 。
运维层面，我们需要对机器的各项指标增加监控，包括网络流量，在达到阈值时提前报警，及时与业务确认并扩容 。
以上我们总结了Redis中常见的可能导致延迟增大甚至阻塞的场景，这其中既涉及到了业务的使用问题，也涉及到Redis的运维问题 。
可见，要想保证Redis高性能的运行，其中涉及到CPU、内存、网络，甚至磁盘的方方面面，其中还包括操作系统的相关特性的使用 。
作为开发人员，我们需要了解Redis的运行机制，例如各个命令的执行时间复杂度、数据过期策略、数据淘汰策略等，使用合理的命令，并结合业务场景进行优化 。
作为DBA运维人员，需要了解数据持久化、操作系统fork原理、Swap机制等，并对Redis的容量进行合理规划，预留足够的机器资源，对机器做好完善的监控，才能保证Redis的稳定运行 。
Redis的最佳实践方式：业务层面和运维层面
在上文中，主要讲解了 Redis 常见的导致变慢的场景以及问题定位和分析，主要是由业务使用不合理和运维不当导致的 。
我们在了解了导致Redis变慢的原因之后，针对性地优化，就可以让Redis稳定发挥出更高性能 。
接着就来总结一下，在使用Redis时的最佳实践方式，主要包含两个层面：业务层面、运维层面 。
由于我之前写过很多UGC后端服务，在大量场景下用到了Redis，这个过程中也踩过很多坑，所以在使用过程中也总结了一套合理的使用方法 。
后来做基础架构，开发Codis、Redis相关的中间件，在这个阶段关注领域从使用层面下沉到Redis的开发和运维，更多聚焦在Redis的内部实现和运维过程中产生的各种问题，在这块也积累了一些经验 。
下面就针对这两块，某公司我认为比较合理的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个以下元素；


推荐阅读


上一篇：CAD图纸怎么才能够打印出来？收好这个方法不再烦恼

下一篇：汽车贴膜一般要多少钱？ 汽车贴膜价格？