Hazelcast 以首选成员为主要成员的数据亲和性

Question

我有一个使用 Hazelcast 设置的集群系统来存储我的数据。集群中的每个节点都负责连接到 localhost 上的服务并将数据从该服务传送到 Hazelcast 集群。

我希望这些数据主要存储在接收它的节点上，并在该节点上进行处理。我希望数据在性能要求相对较低的其他节点上可读可写。

我从一个天真的实现开始，它完全按照我的描述进行，没有特殊考虑。我注意到性能受到了很大影响（我们使用 Infinispan 进行了单独的实现进行比较）。一般来说，我从每个单独的服务处理的数据之间几乎没有逻辑交集。它存储在 Hazelcast 集群中，因此可以从所有节点读取和偶尔写入，并用于故障转移场景。如果 Hazelcast 成员在该节点上失败或本地服务在该节点上失败，我仍然需要读取失败节点的最后良好状态。

因此，我第一次尝试共同定位数据并减少网络聊天是使用 serverId（例如，3 节点系统上的数字从 1 到 3）对大部分数据进行加密，并将其包含在密钥中。然后密钥实现 PartitionAware。我没有注意到性能的改进，所以我决定在集群上执行逻辑本身并以相同的方式对其进行键控（将 PartitionAware/Runnable 提交给 DurableExecutorService）。我想如果我不能选择可以处理逻辑的成员，我至少可以在同一个成员上一致地执行它并与数据位于同一位置。

这使得性能更加糟糕，因为所有数据和所有执行任务都在单个节点上存储和运行。我认为这意味着节点 #1 获得分区 1 到 90，节点 #2 获得分区 91 到 180，节点 #3 获得 181 到 271（或者在不完全了解密钥哈希算法以及我的int serverId 转换为分区号）。因此散列 serverId 1、2、3 并导致例如获得所有数据和执行任务的最老成员。

我的下一个尝试是将备份计数设置为（成员计数） - 1 并启用备份读取。这稍微改善了一些情况。

然后我查看了 ReplicatedMap，但它不支持索引或谓词。我迁移到 Hazelcast 的动机之一是它对索引和查询地图数据的更全面的支持（而且，据我所见，更好的性能）。

我不相信这些方法是正确的（尤其是因为将 3 个节点号映射到分区号与分区的预期使用方式不匹配）。还有什么我可以看的可以提供这种布局的东西，其中一个成员是数据的首选主节点，并且在失败后仍然对 1 个或多个其他成员具有可读备份？

谢谢！

Answer 1

数据网格提供可扩展性，您可以添加或删除存储节点以调整容量，为此网格需要能够重新平衡数据负载。重新平衡意味着将一些数据从一个地方移动到另一个地方。因此，作为一般规则，数据的放置不在您的控制范围内，并且可能会在网格运行时发生变化。

分区意识会将相关项目保持在一起，如果它们移动，它们就会一起移动。一个可运行/可调用的访问都可以从一个 JVM 满足这一点，因此效率更高。

如果您确实需要特定节点的本地数据，有两个可能的改进，read-backup-data 或 near-cache。见this answer。 两者或其中一个都有助于读取，但不利于写入。