大家好，我是烤鸭：

    这个问题有点奇怪，新服务上线，redis tps居高不下，还都是ping命令。

环境：

服务 ： 280台，redis集群：12主24从

问题

由于服务刚上线，还没有访问，发现ping命令的qps 7K，就很纳闷。运维帮忙看了下，确认这些命令的发起ip是业务服务。

问题排查

项目中用到了 lettuce和redisson，在测试环境测试，尝试把redisson去掉后，没有大量ping了。

加上之后，又有了，频率大概是 每分钟 26次。

看下源码

跟了源码发现是 PingConnectionHandler.sendPing 发起的ping操作。

如果触发了 channelActive 就会定时执行ping，检测channel 是否还保持连接。

protected void sendPing(final ChannelHandlerContext ctx) {final RedisConnection connection = RedisConnection.getFrom(ctx.channel());final RFuture<String> future = connection.async(StringCodec.INSTANCE, RedisCommands.PING);config.getTimer().newTimeout(new TimerTask() {@Overridepublic void run(Timeout timeout) throws Exception {CommandData<?, ?> commandData = connection.getCurrentCommand();if ((commandData == null || !commandData.isBlockingCommand()) && (future.cancel(false) || !future.isSuccess())) {ctx.channel().close();log.debug("channel: {} closed due to PING response timeout set in {} ms", ctx.channel(), config.getPingConnectionInterval());} else {sendPing(ctx);}}// 决定ping的频率,为0表示不再ping了，默认是0}, config.getPingConnectionInterval(), TimeUnit.MILLISECONDS);
}

大部分人都不会有这个问题，因为 redisson默认的 pingConnectionInterval 就是0…

主要是写公共组件那哥们把这个值默认写成了60s…

结论

这个值改了之后就没有这个问题了。不过ping tps: 7k 确实有点诡异。

这个7k 只是部分client发起的，再平均到redis 实例，每个实例150 tps，也还可以接受吧。

最终发现是发现不同的grafana统计数据有差异，估计150 tps差不多。