一、现象
流式计算团队反馈他们那边有一个流式计算pipeline算子访问redis慢，导致处理数据积压。当流式计算将该算子从访问redis模式切换回local cache模式后，积压消除，故怀疑是redis服务器有问题。
由于是线上环境的问题，研发同学无法直接上去操作，所以找运维同学查看相关指标。他们反馈从cat打点上看，redis服务器没有明显异常；网络运维同学也反馈网络方面也没有明显异常。
图1.1 流式计算对应的kafka消费有积压现象
图1.2 流式计算执行时间
流式计算访问redis背景情况： 流式计算该算子在630版本下，没有使用redis的pipeline模式。当前环境有积压的流式计算的算子，需要需要根据设备数量和测点数量，去多次访问redis服务器获取数据。使用的是redis的hmget和hmset等命令。如下图所示，记录了该积压的流式计算算子去redis获取数据的统计指标。（此时间指标统计包含了多次去redis服务器端取数据时间）
图1.3 流式计算算子执行一批redis hmget、hmset的总耗时统计指标(此时间指标统计包含了多次去redis服务器端取数据时间）
二、应急步骤：
流式计算暂时使用local模式计算算子。
三、原因定位：
接到开发反馈后，去定位问题根源。根据流式计算方反馈出现此问题的环境（我们称之为环境A）下数据量和大小和环境B的体量相仿，故主要拿这两个环境做对比。
1、cat打点情况
下图为流式计算应用访问redis的的bull打点情况，左图为A环境，右图为B环境。可以看出来，从cat打点的avg和95线来看，A环境访问redis的耗时大约为B环境的10倍左右。
图2.1 B环境中流式计算应用bull打点情况
图2.2 A环境流式计算应用bull打点情况
2、排查redis性能端问题
2.1 访问延迟数据采样
后排查redis服务端是否有性能问题，使用redis官方的latency-history工具查看一段时间内的延迟，以及慢查询记录，并没有发现明显异常的慢查询出现。
图2.3 redis 服务端latency监测
2.2 慢查询日志分析
慢查询定义：redis服务端执行时间超过10ms的查询定义为慢查询，此时间不包括网络RTT时间。其中使用关键词LastChangedRecordAppender_01和LastRecordAppender查询两个环境的慢查询，使用B环境作为对比。
B环境存在部分慢查询，在一段时间内（大于6小时），出现的数量不算多（大约在50个左右），单次慢查询的时间也在10ms-20ms之间。理论上不会对性能造成太大影响。A环境的慢查询日志也是符合正常情况的。
2.3、排查数据是否存在bigkey
图3.1 流式计算其中一个hash表中的key情况。
我们导出了rdb文件分析流式计算所使用的哈希表的value大小。经过统计，每个哈希表平均有10几个fileds，较大的fileds的value值可达到20K以上。平均来看，fields数量在十几个上下，单个fileds对应的value平均大小为4K左右。具体信息可以查看文件2.
流式计算访问使用的命令为hmget和hmset。经过测试，使用这些命令访问key这些key，也不会造成出现较多慢查询的情况。
图3.2 流式计哈希表中最大的field-value对的长度统计信息
2.4、排查网络问题
通过对redis服务端的排查，基本上排除了redis服务端存在明显的性能问题，接下来排查网络问题。
由于流式计算方和网络运维不认cat中的bull打点结果，所以我们需要实际执行一些操作来定位网络问题。我们首先选择了通过ping命令来查看延迟问题。最开始没有发现明显的问题。但是后续几天排查，发现访问不同的机器的网络延迟有明显差别，差距可达到10倍以上。图4.1是2月2号网络排查结果。
图4.1 2月2日22：33分左右，从大数据集群ping其中三台redis的延迟统计结果
接下来我们使用redis命令，去执行redis请求，记录实际的网络请求延迟，并和调整了网络参数后的请求时间进行对比，结果如图4.2所示。因此定位问题原因为网络问题。
图4.2 网络调整前后访问时间统计
四、问题解决方案
运维同学调整了网络参数后，然后我们将流式计算的重新从local模式切换成redis模式，数据积压情况并没有再出现。 bull的cat打点指标，流式计算的应用的平均执行时间从12ms降低为不到2ms，降低了6倍时间。
网络方面的调整：
根据运维同学描述，本次大数据机器访问redis延迟高，是因为虚拟机负载均衡被迁移到机房中的另外一个服务器中，导致访问需要走交换机，造成网络延迟增高。后运维手动将其迁移会原服务器，网络延迟问题改善。
A环境已启用cgroup，未来离线集群对cup的抢占导致cup资源不够，虚拟机自动迁移的问题应该会有所改善。
图1 调整了网络参数后，重新切换回redis，数据积压情况消失
图2 调整参数后，A环境访问redis的指标打点
