背景
我们基于Flink SQL及Table API实现数据转发的功能，晚上8点左右发现数据Kafka中数据积压严重。导致数据转发到SaaS系统，数据延长大。由于是生产环境，我们需要需要快速恢复，并定位出问题。
查询规则Job运行状态
通过Flink控制台查询此租户落在的job的运行情况，发现job正常运行，只是消费kafka消息比较慢。一并登录kafka机器，查看分组的消费情况，发现LAG严重，达到5，6万。再查询我们数据转发的日志表，发现数据时间和规则处理时间相差5，6分钟以上。断定：由于job消费慢，导致数据积压。
问题处理
通过Flink控制台查询此job涉及到的规则SQL数，发现达到20几个。查询了job相关的规则创建时间。未发现最近时间创建的。都是1个月之前的数据。然后我们分两步走：
1、减少规则数，快速恢复业务
将本账户所在JOB的其他规则信息禁用，然后重新本job，将规则数从20几个降为10个。然后观察LAG有明显好转。业务在趋向恢复。
2、查询相关的job涉及到的组件监控
vm、redis、kafka。
##kafka监控
下午4点，消息上报数量增加，由之前的50到目前的100。然后Flink消费有积压，LAG持续增大。
##redis监控
reds的访问评率持续升高，和flink、kafka完全对应起来。
##VM监控
Flink job所在机器内存充足。网络带宽占用有所上升。
#排查redis访问量骤升问题
然后我们看到redis升的比较快，想查看那些操作比较频繁及响应的慢查询。
##慢查询
slowlog get 10
查看最近10条的慢查询。通过此命令可以看到执行慢的命令。
##监控
通过monitor命令，redis日志全部打印出来，有时间，来源ip，来源端口，操作函数，操作key。我们可以基于这些日志对当前redis使用情况进行统计分析。命令如下：
./redis-cli -c -p 7000 -a passwd123 monitor >>monitor.log
监控时间根据实际业务量来设置，一般30秒就可以了。
结论
我们通过monitor.log中的ip信息，能判断出骤增的操作都是规则job发起的，结合转发逻辑。已经能定位出具体原因：规则job中有大量访问redis的操作，规则越多访问次数越多。我们在数据处理的时候存在redis读放大的问题。一个规则执行的时候，需要查询5次左右的redis，假如100个规则，则要500次redis查询。问题已定位出来，相应的优化方案也就很明了：
1、减少redis交互次数。
2、访问redis增加二级缓存。
网友评论