Hazelcast：持久性故障切换

我关心的是持久性的故障切换场景，我正在考虑应该如何正确实施它。根据以往的经验，我认为如果基础持久性未能存储实体，只要问题得到解决，就应该能够将其存储起来。就在地图中缓存的Hazelcast实体而言，它具有管理它与MapStore的关系的状态。Hazelcast：持久性故障切换

如果MapStore实现无法存储，会发生什么情况？如何让实体重新应用到MapStore业务？

更新：

这并不是实现MapStore本身的故障转移，以保持项目在队列中，除非底层持久的业务将变得可用，但这打破了分布式存储的思想有问题。另一方面，如果MapStore中出现的数据将被放回缓存中，可能会导致不一致，不是吗？

来源

2013-04-29 Viktor Stolbin

pryvit。对你/他人如何处理这个问题感兴趣。根据应用程序的要求，我认为如果持久性失败，可以简单地从地图中移除对象（直到可以重新插入到地图中并因此插入到数据存储区时可以工作，或者避免写入，因为它可能永远不会工作） - 删除处理程序将需要修改，以避免尝试从数据库中删除数据，可能不在那里开始。可以尝试使用状态标志来避免从地图读取此值，直到持久性工作或失败（以避免可能有效或无效的读取）。 – 2013-05-01 00:42:09

我确信这里有漏洞 - 有兴趣听到它。 – 2013-05-01 00:42:47

同意你的意见。我有一种感觉，用脏旗或其他内部生命周期业务来玩可能会感兴趣，但它是一个内部API，因为它在文档中没有提到。在这里有一个Hazelcast的人来获得一些线索是很好的。 – 2013-05-06 05:38:54

甲持久性可以配置成

写入通过
写入后面。

如果通过写入，如果MapStore由于某种原因失败，您将在map.put上发生异常。

在后面写入的情况下，每10（默认）秒Hazelcast会将所有脏条目作为批量持久化。如果MapStore抛出异常，那些条目将被标记为脏，并且在下一次运行中，它们会再次传递给MapStore。基本上Hazelcast将继续存储它们，直到MapStore.storeAll（）成功。根据我的理解，你的情况会变成这个类别，而Hazelcast确实提供了故障转移。

来源

2013-05-07 02:08:56

Hazelcast：持久性故障切换

回答

相关问题