我关心的是持久性的故障转移场景，我正在考虑应该如何正确实施它。 根据以往的经验，我认为如果基础持久性未能存储实体，只要问题得到解决，就应该能够将其存储起来。 就在地图中缓存的Hazelcast实体而言，它具有管理它与MapStore的关系的状态。
如果MapStore实现无法存储，会发生什么情况？ 如何让实体重新应用到MapStore业务？
更新：
在MapStore中实现故障转移并不是一个问题，除非基础持久性业务可用，否则这会破坏分布式存储器的想法，从而使条目保持在队列中。 另一方面，如果MapStore中出现的数据将被放回缓存中，可能会导致不一致，不是吗？
I'm concerning a failover scenario for a persistence and I'm considering the way it should be properly implemented. Out of previous experience I'm thinking that in case underlying persistence failed to store entity, it should be able to store it later as soon as problem will be solved. In terms of Hazelcast entity being cached in map has states that manage it's relation to MapStore.
What happens if MapStore implementation fails to store? How to make entity to be re-applyied to MapStore business?
Update:
It's not a problem to implement failover in MapStore itself to keep entries in queue unless underlying persistence business will become available but this breaks ideas of distributed memory. On the other hand it potentially can cause inconsistencies if data appeared in MapStore will be put back to cache, isn't it?
最满意答案
持久性也可以配置
通过写 写在后面。在通过写入的情况下，如果MapStore由于某种原因失败，您将在map.put上遇到异常。
在写入后面的情况下，每10（默认）秒钟，Hazelcast会将所有脏项目作为批量持续存储。 如果MapStore抛出异常，那些条目将被标记为脏，并且在下一次运行中，它们会再次传递给MapStore。 基本上Hazelcast将继续存储它们，直到MapStore.storeAll（）成功。 根据我的理解，你的情况会变成这个类别，而Hazelcast确实提供了故障转移。
A persistency can be configured either
Write through Write behind.In case of write through, if MapStore fails for some reason, you'll get exception on map.put.
In case of write behind, Every 10(default) seconds Hazelcast will persist all dirty entries as a bulk. If MapStore throws an Exception, those entries are marked as dirty and in the next run, they are passed to the MapStore again. Basically Hazelcast will continue to store them until the MapStore.storeAll() succeeds. From what I understand, your case fals into this category and Hazelcast does provide a failover.
更多推荐
发布评论