如何在只有 2 个 Hazelcast 集群节点的 Hazelcast CP 子系统上使用 AtomicLong？答案

【问题标题】：How to use AtomicLong on Hazelcast CP Subsystem with just 2 Hazelcast cluster nodes?如何在只有 2 个 Hazelcast 集群节点的 Hazelcast CP 子系统上使用 AtomicLong？
【发布时间】：2019-09-21 04:47:17
【问题描述】：

我正在更新到最新的 Hazelcast 版本 [3.12]，我在获取 AtomicLong 实例时遇到了问题。新版本，HZ 引入了 CAP Theorem 的概念，赋予 Consistency 和 Partition Tolerance，但问题是 CP 子系统必须至少有 3 个成员。

Config config = new Config();
config.getCPSubsystemConfig().setCPMemberCount(3);
config.getCPSubsystemConfig().setGroupSize(3);

HazelcastInstance instance1 = Hazelcast.newHazelcastInstance(config);

如何配置 CP 子系统，以便为我提供只有两个 hazelcast 节点的 atomicLong 实例？

如果我只使用一个节点启动我的应用程序，则会打印以下消息：

MetadataRaftGroupManager.log:65 [127.0.0.1]:6000 [dev] [3.12] CP 子系统正在等待 3 个成员加入集群。当前成员数：1

我将只有两个节点，因此，CP 子系统不允许我使用 atomicLong，因为它会永远等待至少 3 个节点..

我刚刚调用的 3.11 版本hazelcast.getAtomicLong("count")。我该如何处理？

【问题讨论】：

标签： java hazelcast subsystem cap atomic-long

【解决方案1】：

在 3.12 中，CP 子系统不能配置为使用少于 3 个节点运行，因为这会牺牲“一致性”，这是 CP 子系统在某些故障情况下（网络分区）的全部目的。 [编辑：请参阅下面关于 4.0 及更高版本行为的新评论]

您仍然可以使用 3.11 API，因此您的 3.11 实现中的代码将继续工作。尽管 3.11 API 被标记为已弃用，但它们并未被删除或禁用；弃用是一个警告，即已知 API 在脑裂情况下容易受到一致性问题的影响。一些应用程序代码可以容忍此类问题，并且该漏洞不是问题；如果您的应用程序不能容忍与 atomic long 的潜在一致性问题，则需要添加一个额外的节点以迁移到 CP 实现。

【讨论】：

嗨，迈克，感谢您的回答。我不确定是否是最好的方法至少强制应用程序的树节点依赖于 CP 子系统提供的 IAtomicLong、IAtomicReference、FencedLock、ISemaphore 和 ICountDownLatch。也许 API 的客户端应该定义它是否关心一致性。 . 这个新功能可能无法在许多节点上运行的许多应用程序中不可用.. 顺便说一下，旧的实现已被弃用，将在 4.0 版本中删除。
我明白你为什么弃用旧的 API 并迁移到 CP 实现，但这会导致一些问题。例如，如果由于某种原因 3 个必需节点之一出现故障，整个应用程序将不再工作。如果您只有 3 个节点，这可能由于多种原因而发生，例如服务器故障、维护等。虽然只有 2 个节点可用，但应用程序不能使用 Locks、Atomic Longs 等，这并不总是好的。我建议在 CP 子系统旁边保留并且不要删除旧方法，然后开发人员可以决定使用哪个...
在 4.0 版本中，将对 CP 子系统进行修改以支持在不安全模式下运行。对于许多用户来说，一致性是一项硬性要求 - 不可用比返回不正确的结果要好。这就是 CP 子系统设计的情况。使用新的不安全模式，您可以优先考虑可用性，并允许 FencedLock 等 API 继续运行，即使没有完整的 CP 仲裁。