受控分区和 MapStore答案

【问题标题】：Controlled partitioning and MapStore受控分区和 MapStore
【发布时间】：2019-06-06 10:12:49
【问题描述】：

可以说，我有几个 Hazelcast 成员（服务器）分布在世界各地（例如德国、俄罗斯等）。

需要按区域在数据库中存储/拆分数据，并且所有数据都应该可以通过IMap 支持的MapStore 从任何服务器访问。

我最近阅读了满足我要求的this article，但我不确定MapStore 的行为方式。

关键时刻是，如果member1（例如俄罗斯）使用member2 拥有的密钥（例如德国）从IMap 请求数据，那么MapStore.load() 将在哪一侧被调用？

【问题讨论】：

【解决方案1】：

您不应将同一集群的成员拆分到不同的数据中心。集群的成员依靠定期的心跳消息来检测集群的健康状况；广域网无法以一致的方式可靠地提供这些，您几乎肯定会遇到网络分区问题（脑裂综合症）。

每个数据中心（德国、俄罗斯等）都应该有一个带有特定区域地图的单独集群。然后可以将这些映射复制（WAN 复制）到远程数据中心，以进行灾难恢复并提供地理上接近的服务器来支持该区域中需要访问其他区域数据的用户。

由于数据库中的数据已经按区域拆分，因此在 Hazelcast 端匹配此拆分意味着 MapLoader 将始终从同一位置的数据库加载。

【讨论】：

如果map中的每一个key都被“Controlled Partitioning”控制，怎么会出现网络分区问题呢？由于分区是受控的，hazelcast 不会尝试在成员之间重新平衡内存。如果我错了，请纠正我。
如果集群认为某个成员已经崩溃，属于该成员的分区将被重新分配（基本上，任何持有这些分区备份的成员都将被指定为主，并且将创建新的备份其他成员）。分区重新平衡和迁移是容错的关键部分，在成员崩溃的情况下保持集群的可靠性。如果成员不在同一地点，则更有可能错误地认为成员已崩溃，然后主节点和备用节点都认为他们是主节点（因此脑裂）。
我们在开发服务器时牢记这一点，我知道脑裂问题。 WAN 复制不是我们现在需要的。我们可以使用的内存是有限的，我们需要每个成员在他的内存中只保存自己的条目。如果有人离开/崩溃是可以接受的，我们会处理这些错误。
如果我能回答我的关键问题，那就太好了：如果 member1 使用 member2 拥有的密钥从 IMap 请求数据，将在哪一侧调用 MapStore.load()？
MapStore.load() 将在管理找到密钥的分区的分区线程上调用，因此在本例中为 member2。