Hazelcast问题：分布式Map过期条目是否应同步移除近缓存条目？

这是预期行为吗？ #

是的，这是Hazelcast 5.x版本近缓存的默认行为，但可以通过配置优化来降低数据不一致的影响。

核心原因 #

Hazelcast的近缓存是节点本地的独立缓存，主Map中条目的TTL过期清理属于集群后台异步操作，不会主动向近缓存发送失效通知。近缓存的条目过期逻辑默认仅依赖自身配置的TTL（未单独设置时会继承主Map的TTL），但两者的过期时间计算相互独立，因此会出现主Map条目已删除、近缓存仍保留旧数据的情况。

解决思路 #

要缩小主Map与近缓存的数据不一致窗口，可通过以下配置调整：

• 同步近缓存与主Map的TTL：将近缓存的time-to-live-seconds设置为与主Map完全相同的值，让两者的条目在相近时间内过期，减少不一致的持续时间。
• 启用主动失效监听：开启近缓存的invalidate-on-change配置（默认已启用），该配置可处理主Map中条目被主动更新/删除的场景，但对TTL自动过期的场景无效，仍需依赖同步TTL来覆盖。

配置示例（XML） #

<map name="your-target-map">
    <!-- 主Map的TTL设置 -->
    <time-to-live-seconds>30</time-to-live-seconds>
    <near-cache>
        <!-- 近缓存TTL与主Map保持一致 -->
        <time-to-live-seconds>30</time-to-live-seconds>
        <!-- 启用主动更新/删除时的失效通知 -->
        <invalidate-on-change>true</invalidate-on-change>
        <eviction-policy>LRU</eviction-policy>
    </near-cache>
</map>

配置示例（Java代码） #

MapConfig mapConfig = new MapConfig("your-target-map");
// 设置主Map的TTL
mapConfig.setTimeToLiveSeconds(30);

NearCacheConfig nearCacheConfig = new NearCacheConfig();
// 同步近缓存TTL
nearCacheConfig.setTimeToLiveSeconds(30);
// 开启主动变更时的失效通知
nearCacheConfig.setInvalidateOnChange(true);
mapConfig.setNearCacheConfig(nearCacheConfig);

补充说明 #

如果需要严格的强一致性，建议禁用近缓存（但会牺牲读取性能），因为近缓存的设计初衷是通过牺牲一定的一致性来换取更高的读取效率，属于典型的“最终一致性”缓存模型。

内容的提问来源于stack exchange，提问作者RN8