concurrency - 如何在少于 3 个节点的情况下使用 Hazelcast 的 CPSubsystem？

Question

我看到 Hazelcast 3.12 引入了 CPSubsystem()适用于具有 3-7 个节点的系统。我明白其中的道理。但是，如果我试图设计一个可以在 1-n 个节点之间的任何地方运行的解决方案，我是否需要使用不同的逻辑来验证 CPSubsystem 是否已启用？我什至如何检查？

我会想/希望只是打电话

hazelcastInstance.getCPSubsystem().getLock()

无论节点数量如何，都可以工作，但如果节点少于 3 个，则会引发异常。而且我找不到任何允许我检查 CPSubsystem 的方法。是否启用。

我当前的实现使用已弃用的方法 getLock()获取分布式锁:

   LOG.debug("Creating a distributed lock on username for a maximum of 5 minutes {}", username);
    ILock usernameLock = hazelcastInstance.getLock(this.getClass().getName() + ":" + username);
    try {
        if (usernameLock.tryLock (5, TimeUnit.MINUTES)) {
            clearUserData(cacheEntryEvent);
        }
    } catch (InterruptedException e) {
        LOG.warn("Exception locking on : {} ", username, e);
        LOG.warn("Invoking clearUserData without synchronization : {}", username);
        clearUserData(cacheEntryEvent);
    } finally {
        usernameLock.unlock();
    }

如何在不知道这一点的情况下获得 Hazelcast 的锁定？ hazelcastInstance.getLock()被标记为已弃用并打算在 HC4 中移除。

Answer 1

如您所知，CPSubsystem是 CP系统方面 CAP定理。它必须明确启用才能使用，因为它有一些限制和先决条件。其中之一是，集群中至少应存在 3 个 Hazelcast 成员。实际上，2个成员就足够了，但是Hazelcast的CPSubsystem拒绝与 2 个成员一起工作，因为 2 个成员中的大多数又是 2 个，并且一旦其中一个成员崩溃，它很容易不可用。
HazelcastInstance.getLock()用途 async replication of Hazelcast并且不能提供 CP故障下的保证。这适用于某些系统/应用程序，但不适用于所有系统/应用程序。这就是为什么在尽力而为锁定机制与基于 CP 的锁定机制之间进行选择应该是明确的，并且应该根据这种选择来设计依赖于锁定的应用程序。见 Daniel Abadi 的 The dangers of conditional consistency guarantees与此选择相关的帖子。这就是为什么，CPSubsystem().getLock()不回退到 best-effort/unsafe集群大小小于 3 时的锁定机制。
HazelcastInstance.getLock()在 3.12 中已弃用，并将在 4.0 中删除。但是 Hazelcast 会提供一个 unsafe (development) mode for CP data structures ，它将与任意数量的成员一起使用，并将基于类似于 Hazelcast AP 数据结构的异步复制。