大家好，我是烤鴨：

????這個問題有點奇怪，新服務上線，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差不多。

總結

以上是生活随笔為你收集整理的redisson 大量ping操作，导致 tps过高的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。