当一个成员停止响应实际请求时宣布它死亡答案

【问题标题】：Declaring a Member dead when it stops responding to actual requests当一个成员停止响应实际请求时宣布它死亡
【发布时间】：2016-11-10 10:53:21
【问题描述】：

我们的 Hazelcast 设置（Payara 中嵌入的 Hazelcast）多次中断，在这种情况下，进程的非 hazelcast 工作负载导致 GC 开销错误。

在此期间，Hazelcast 响应了心跳，但没有响应获取数据的实际请求。这会导致系统停止，即使数据备份可用。

因此，我想问如果成员停止响应除了心跳之外的其他类型的请求，是否有办法将成员踢出集群。

【问题讨论】：

这更像是一个payara问题。我想可能会启动 Hazelcast 客户端（而不是嵌入式成员，这通常是推荐的部署策略）并使用单独的 Hazelcast 集群，这正是您提到的原因，GC。顺便说一句，只有在启用“从备份中读取”时才读取备份，并且它也只会在成员有本地备份时读取，它不会向其他成员询问备份！
是的，独立集群是我将追求的方向，只是 Devoxx 的 Hazelcast 展台的人建议在这里询问将这种行为作为一个功能是否是个好主意。跨度>

标签： hazelcast payara

【解决方案1】：

您可能需要考虑在 Payara 服务器实例上以“精简”模式使用 hazelcast。如果您在可能面临持续 GC 的实例上打开“精简”模式，这些实例不应影响 Hazelcast 性能，因为这些节点不会为 hazelcast 集群存储任何数据。

但是，有必要使用额外的完整实例来补充此解决方案，这样可以保留数据。这些额外的实例不应运行您的任何应用程序，并且仅用作单独的 hazelcast 节点。我的博客文章中的Focused on throughput and performance 部分描述了如何使用“Lite”Payara 集群成员（由 Lite hazelcast 成员支持）的一些场景。

总而言之 - 如果您将一些节点变成“Lite”并且为每个“Lite”节点添加一个单独运行的额外“完整”节点，没有部署应用程序，您将分离应用程序使用的内存并将 hazelcast 转换为单独的 JVM。 JVM 上的 GC 是“Lite”节点并且不包含 hazelcast 集群的数据，不应影响 Hazelcast 性能。

【讨论】：