在 TTL 强制驱逐 Hazelcast IMap 条目答案

【问题标题】：Force eviction of Hazelcast IMap entries at TTL在 TTL 强制驱逐 Hazelcast IMap 条目
【发布时间】：2018-03-08 16:34:21
【问题描述】：

我遇到了一个问题，即 Hazelcast 的地图在配置 TTL 的显着延迟时驱逐条目。在这里找到了一个解决方案来设置以下属性以在 TTL 处强制驱逐：https://github.com/hazelcast/hazelcast/issues/8894。属性可以重置为：

配置配置 = 新配置（）； config.setProperty("hazelcast.internal.map.expiration.task.period.seconds", "1"); config.setProperty("hazelcast.internal.map.expiration.cleanup.percentage", "100"); config.setProperty("hazelcast.internal.map.expiration.cleanup.operation.count", "271");

现在的问题是这些属性适用于整个 hazelcast 实例。有谁知道这是否只能为实例中的单个地图设置？ MapConfig 本身没有 setProperty() 方法。

P.S：以上属性仅适用于 hazelcast 3.8 及更高版本。

【问题讨论】：

Hazelcast 在明显延迟后驱逐是什么意思？您如何衡量这种延迟？
如果地图 TTL 为 20 秒，并且我的地图中同时添加了 100 个条目，但存在毫秒差异，我会看到 EntryEvictedListener 的 entryEvicted() 以 20 秒、25 秒、30 秒和 35 秒的时间批量调用。跨度>
这是因为周期性驱逐每 5 秒运行一次，它会删除已过期的条目。如果您对过期条目执行 map.get，您将看到在该 get 调用上发生驱逐。
条目，即使过期，也会保留在集群中，直到它们在定期驱逐或 map.get 调用中被驱逐。
我发现了一个 EntryExpiredListener，它的 entryExpired() 的行为也与 ExtryEvictedListener 的 entryEvicted() 相同。我希望在 TTL 之后调用 entryExpired()。你能解释一下为什么会这样吗？

标签： hazelcast hazelcast-imap

【解决方案1】：

即使该条目尚未删除，过期的条目也将无法访问，并且最终会通过定期清理过程或当用户尝试访问该条目时被清除。使用这些属性，您可以定义清理过程的行为。

关于你的第二个问题；是的，这些属性是集群级别的，它们不能在每个地图基础上应用。

【讨论】：

感谢您的澄清。问题是我在驱逐侦听器中有一些逻辑，必须在 TTL 之后立即调用这些逻辑，而不会有太多延迟。由于更改这些属性可能会影响性能，因此我只想将它们应用于该单个地图。
也许为这个要求打开一个github issue 将有助于开始讨论这个要求。