我们正在使用Redisson连接到具有1个主节点和2个副本节点的AWS Elasticache上的复制Redis。
该应用程序利用了多个RLocalCachedMap，Lock和数千个Topics来跟踪用户状态。 （随着用户上线和下线，主题和订阅的来回变化）。
但是，我们经常会收到一系列RedisTimeoutException，这些最初是在服务器运行了几天之后出现的，并且会连续发生直到服务器重新启动，否则会因内存不足错误而崩溃。这使我认为缺少可用的订阅，但是，如果我正确理解订阅设置，则我们的设置（如下所示）应该可以支持100,000个以上的订阅，而我们离这个范围还很近。
此外，其中的一些情况将在预热期间发生，在此期间服务器上的负载相对较小，在少数例外之后，连接仍处于连接状态，并且几天内没有重大问题，这表明这不是纯粹的订阅问题。每次命令都是简单的锁定/发布/订阅，而不是复杂的批处理。
AWS Elasticache节点上的负载始终很小，我们的服务器部署在AWS EC2实例上，因此应该具有相对良好的连接性！
我们获得的2个例外情况要么是锁定要么是订阅主题：
Caused by: org.redisson.client.RedisTimeoutException: Subscribe timeout: (7500ms)
at org.redisson.command.CommandAsyncService.syncSubscription(CommandAsyncService.java:142) ~[redisson-3.8.2.jar!/:na]
at org.redisson.RedissonLock.lockInterruptibly(RedissonLock.java:149) ~[redisson-3.8.2.jar!/:na]
at org.redisson.RedissonLock.lockInterruptibly(RedissonLock.java:136) ~[redisson-3.8.2.jar!/:na]
at org.redisson.RedissonLock.lock(RedissonLock.java:118) ~[redisson-3.8.2.jar!/:na]
和
java.util.concurrent.CompletionException: org.redisson.client.RedisTimeoutException
at org.redisson.misc.RedissonPromise.await(RedissonPromise.java:197) ~[redisson-3.8.2.jar!/:na]
at org.redisson.misc.RedissonPromise.await(RedissonPromise.java:206) ~[redisson-3.8.2.jar!/:na]
at org.redisson.command.CommandAsyncService.syncSubscription(CommandAsyncService.java:141) ~[redisson-3.8.2.jar!/:na]
at org.redisson.RedissonTopic.addListener(RedissonTopic.java:133) ~[redisson-3.8.2.jar!/:na]
at org.redisson.RedissonTopic.addListener(RedissonTopic.java:109) ~[redisson-3.8.2.jar!/:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_111]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_111]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_111]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_111]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_111]
Caused by: org.redisson.client.RedisTimeoutException: null
at org.redisson.pubsub.PublishSubscribeService$4.run(PublishSubscribeService.java:220) ~[redisson-3.8.2.jar!/:na]
at io.netty.util.HashedWheelTimer$HashedWheelTimeout.expire(HashedWheelTimer.java:670) ~[netty-common-4.1.30.Final.jar!/:4.1.30.Final]
at io.netty.util.HashedWheelTimer$HashedWheelBucket.expireTimeouts(HashedWheelTimer.java:745) ~[netty-common-4.1.30.Final.jar!/:4.1.30.Final]
at io.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:473) ~[netty-common-4.1.30.Final.jar!/:4.1.30.Final]
我们的配置是：
"subscriptionConnectionMinimumIdleSize":32,
"subscriptionConnectionPoolSize":128,
"slaveConnectionMinimumIdleSize":32,
"slaveConnectionPoolSize":128,
"masterConnectionMinimumIdleSize":64,
"masterConnectionPoolSize":128,
"subscriptionsPerConnection": 1000,
"timeout": 3000,
"retryAttempts": 3,
"retryInterval": 1500,
"readMode": "SLAVE",
"subscriptionMode": MASTER
我已经阅读了有关超时的Redisson FAQ，我们的超时异常显然不是服务器或客户端，因此不确定哪个超时参数最好进行调整，再加上它们是7.5秒，对于用户请求来说这是很长的时间等待。同样，我找不到有关连接池大小或每个连接的预订的建议值以及生产部署的合理值的建议文档。