在特定Hazelcast地图上执行IMap.get()时，我们遇到的效果非常不一致。
我们的Hazelcast群集运行版本3.8，有8个成员，我们作为Hazelcast客户端连接到群集。我们遇到问题的地图的备份数为1.
我们已经将慢速操作隔离到单IMap.get操作，并记录了该行代码的两侧。 get通常需要几毫秒，但是对于几个键，它需要30到50秒。我们可以在同一个地图上进行多次get操作，除了相同的几个键外，它们都快速返回。特定地图相对较小，仅约2000个条目，类型为<String,String>
如果我们重新启动集群中的成员，我们仍然会遇到相同的延迟但使用不同的密钥。这似乎表明特定成员存在问题，因为当我们停止/启动成员时，集群会重新平衡。我们已经尝试单独停止每个成员并进行测试但遇到相同的症状，每个成员都被隔离停止。我们还尝试减少和增加群集中的成员数量，但无论如何都会遇到相同的症状。
我们已经通过线程转储确认通用操作线程没有被阻塞，并且尝试增加操作线程的数量以及启用并行化但是看不到行为的变化。我们还在群集中启用了诊断日志记录，并且没有看到任何明显的问题（没有报告慢速操作）。
看看Hazelcast JMX MBeans，特定地图上的maxGetLatency只有1秒左右，远低于我们实际遇到的情况。这似乎表明客户端连接或底层网络存在问题。但是，慢键的数量只占总键数的1％左右，因此，除非我们失去平衡，否则问题似乎不会出现在单个成员中，因为您希望大约有8个键中的1个慢。我们还从Hazelcast日志中确认群集稳定。成员们不会辍学并重新加入。
有趣的是，如果我们停止并重新启动整个群集，我们最初会获得良好的性能，但几分钟后它会降级回相同的状态，其中一些特定的IMap.get操作需要30秒以上。
这个确切的代码并不是新的，并且已经运行了很长一段时间。但是，一旦这种行为开始，它在这里始终可以重现。据我们所知，没有环境变化。
我们是否可以启用任何诊断日志记录来深入了解Hazelcast客户端？是否有其他诊断选项可用于追踪延迟的来源？不幸的是，我们无法在任何其他环境中重现这一点，这些环境似乎指向环境或此环境中群集特有的东西。
另一个可能有趣的事情是我们在每个集群成员中每隔6秒看到以下日志语句。 “备份超时：1”是有关的，但我们不确定它的含义。
INFO: [IP]:[PORT] [CLUSTER_NAME] [3.8] Invocations:1 timeouts:0 backup-timeouts:1
非常感谢任何有关如何进一步调试的想法或建议。