我们一直在使用Hazelcast 2.6.8并升级到3.5。升级的原因似乎是缓存数据的间歇性问题。然而升级并没有解决问题。
我们正在尝试在Hazelcast IMap中缓存100个java普通对象,我们从外部数据库缓存这些对象。缓存对象通过Hazelcast的ConcurrentMap在集群中共享。我们有一个由6个节点组成的集群,每当我们从这6个节点中停止并启动2个节点时,我们发现有些java对象丢失了,它的出现以及丢失的数量会有所不同,但是当缺少这个数字通常是大约90个对象时在地图而不是100。
最初,backup-count属性已设置为3,但由于失败,我们将其增加到6。
使用的IMap方法是检索数据的loadAll方法。这是我们正在使用的配置,StoreClass实现了Hazelcast MapStore:
<map name="objectsMap">
<backup-count>6</backup-count>
<near-cache>
<time-to-live-seconds>0</time-to-live-seconds>
<max-idle-seconds>6000</max-idle-seconds>
<eviction-policy>LRU</eviction-policy>
<max-size>5000</max-size>
<invalidate-on-change>true</invalidate-on-change>
</near-cache>
<map-store enabled="true">
<class-name>StoreClass</class-name>
<write-delay-seconds>0</write-delay-seconds>
答案 0 :(得分:0)
std::num_put<char>
如果为true,则所有成员都会监听其缓存条目中的更改,并在更新或删除条目时逐出该条目。
将其更改为false并尝试。它有效。
现在可以将<invalidate-on-change>true</invalidate-on-change>
置于所需的较低数字。建议不要有大数作为备份。 1或2应该满足要求。