hazelcast_Hazelcast的MapLoader陷阱

最新推荐文章于 2023-11-14 17:45:37 发布

cunhu2961

最新推荐文章于 2023-11-14 17:45:37 发布

阅读量192

点赞数

文章标签：分布式 java 缓存 python redis

原文链接：https://www.javacodegeeks.com/2014/09/hazelcasts-maploader-pitfalls.html

版权

hazelcast

Hazelcast提供的核心数据结构之一是IMap<K, V> ，它扩展了java.util.concurrent.ConcurrentMap这基本上是一个分布式地图，通常用作缓存。您可以将此类地图配置为使用自定义MapLoader<K, V> –每次尝试从该地图(通过键)获取.get()尚不存在的某些内容时，都会询问该段Java代码。当您将IMap用作内存中的分布式缓存时，这特别有用–如果客户端代码要求尚未缓存的内容，Hazelcast将透明地执行MapLoader.load(key) ：

public interface MapLoader<K, V> {
    V load(K key);
    Map<K, V> loadAll(Collection<K> keys);
    Set<K> loadAllKeys();
}

其余两种方法在启动期间用于通过加载预定义的键集来预热缓存。您的自定义MapLoader可以连接到(否)SQL数据库，Web服务，文件系统(您命名)。使用这样的缓存要方便得多，因为您不必执行繁琐的“如果不在缓存负载中并放入缓存”循环。此外， MapLoader具有出色的功能-如果许多客户端同时(从不同的线程，甚至从不同的集群成员，因此从机器)要求相同的密钥，则MapLoader仅执行一次。这显着减少了外部依赖项的负担，而没有引入任何复杂性。

从本质上说IMap与MapLoader类似于LoadingCache中发现的番石榴-但分布。但是，强大的功能会带来极大的挫败感，尤其是当您不了解API的特殊性和分布式系统固有的复杂性时。

首先，让我们看看如何配置自定义MapLoader 。您可以hazelcast.xml使用hazelcast.xml ( <map-store/>元素)，但是您无法控制加载程序的生命周期(例如，不能使用Spring bean)。一个更好的主意是直接从代码配置Hazelcast并传递MapLoader的实例：

class HazelcastTest extends Specification {
    public static final int ANY_KEY = 42
    public static final String ANY_VALUE = "Forty two"

    def 'should use custom loader'() {
        given:
        MapLoader loaderMock = Mock()
        loaderMock.load(ANY_KEY) >> ANY_VALUE
        def hz = build(loaderMock)
        IMap<Integer, String> emptyCache = hz.getMap("cache")

        when:
        def value = emptyCache.get(ANY_KEY)

        then:
        value == ANY_VALUE

        cleanup:
        hz?.shutdown()
    }

请注意，我们如何获取一个空的地图，但是当要求输入ANY_KEY ，我们得到ANY_VALUE作为回报。这不足为奇，这正是我们的loaderMock所期望的。我离开了Hazelcast配置：

def HazelcastInstance build(MapLoader<Integer, String> loader) {
    final Config config = new Config("Cluster")
    final MapConfig mapConfig = config.getMapConfig("default")
    final MapStoreConfig mapStoreConfig = new MapStoreConfig()
    mapStoreConfig.factoryImplementation = {name, props -> loader } as MapStoreFactory
    mapConfig.mapStoreConfig = mapStoreConfig
    return Hazelcast.getOrCreateHazelcastInstance(config)
}

任何IMap (按名称标识)都可以具有不同的配置。但是，特殊的"default"映射会为所有映射指定默认配置。让我们玩一下自定义加载器，看看当MapLoader返回null或引发异常时它们的行为：

def 'should return null when custom loader returns it'() {
    given:
    MapLoader loaderMock = Mock()
    def hz = build(loaderMock)
    IMap<Integer, String> cache = hz.getMap("cache")

    when:
    def value = cache.get(ANY_KEY)

    then:
    value == null
    !cache.containsKey(ANY_KEY)

    cleanup:
    hz?.shutdown()
}

public static final String SOME_ERR_MSG = "Don't panic!"

def 'should propagate exceptions from loader'() {
    given:
    MapLoader loaderMock = Mock()
    loaderMock.load(ANY_KEY) >> {throw new UnsupportedOperationException(SOME_ERR_MSG)}
    def hz = build(loaderMock)
    IMap<Integer, String> cache = hz.getMap("cache")

    when:
    cache.get(ANY_KEY)

    then:
    UnsupportedOperationException e = thrown()
    e.message.contains(SOME_ERR_MSG)

    cleanup:
    hz?.shutdown()
}

到目前为止，不足为奇。您可能遇到的第一个陷阱是线程在这里如何交互。永远不会从客户端线程执行MapLoader ，而总是从单独的线程池执行：

def 'loader works in a different thread'() {
    given:
    MapLoader loader = Mock()
    loader.load(ANY_KEY) >> {key -> "$key: ${Thread.currentThread().name}"}
    def hz = build(loader)
    IMap<Integer, String> cache = hz.getMap("cache")

    when:
    def value = cache.get(ANY_KEY)

    then:
    value != "$ANY_KEY: ${Thread.currentThread().name}"

    cleanup:
    hz?.shutdown()
}

该测试通过是因为当前线程是"main"而加载是从"hz.Cluster.partition-operation.thread-10" 。这是一个重要的观察结果，如果您记得当许多线程尝试访问相同的缺席密钥时，加载程序仅被调用一次，则这实际上很明显。但是，这里需要进一步说明。 IMap上的几乎每个操作都封装到一个操作对象中(另请参见：命令模式)。此操作随后分派给一个或所有群集成员，并在单独的线程池中甚至在另一台计算机上远程执行。因此，不要期望加载发生在同一线程，甚至同一JVM /服务器(！)中。

这会导致一种有趣的情况，您在一台计算机上请求给定密钥，而另一台计算机实际加载。甚至更史诗般的–机器A，B和C请求给定密钥，而机器D实际加载该密钥的值。基于一致的哈希算法确定哪个机器负责加载。

最后一句话–当然，您可以自定义运行这些操作的线程池的大小，请参阅“ 高级配置属性” 。

考虑到这一点，这是完全令人惊讶的，并且绝对可以期待：

def 'IMap.remove() on non-existing key still calls loader (!)'() {
    given:
    MapLoader loaderMock = Mock()
    def hz = build(loaderMock)
    IMap<Integer, String> emptyCache = hz.getMap("cache")

    when:
    emptyCache.remove(ANY_KEY)

    then:
    1 * loaderMock.load(ANY_KEY)

    cleanup:
    hz?.shutdown()
}

仔细看！我们要做的就是从地图上删除缺少的密钥。没有其他的。但是， loaderMock.load()已执行。这是一个问题，尤其是当您的自定义加载程序特别慢或昂贵时。为什么在这里执行？查找`java.util.Map＃remove()的API：

V remove(Object key)
[…]
返回此映射先前与该键相关联的值；如果该映射不包含该键的映射关系，则返回null。

也许这是有争议的，但有人可能会认为Hazelcast做的是对的。如果您认为附有MapLoader的地图就像外部存储的视图一样，那是有道理的。当删除缺少的密钥时，Hazelcast实际上会询问我们的MapLoader ：以前的值是什么？它假装地图好像包含从MapLoader返回的每个单个值，但延迟加载。这不是错误，因为有一个特殊的方法IMap.delete()就像remove()一样工作，但是不会加载“先前”值：

@Issue("https://github.com/hazelcast/hazelcast/issues/3178")
def "IMap.delete() doesn't call loader"() {
    given:
    MapLoader loaderMock = Mock()
    def hz = build(loaderMock)
    IMap<Integer, String> cache = hz.getMap("cache")

    when:
    cache.delete(ANY_KEY)

    then:
    0 * loaderMock.load(ANY_KEY)

    cleanup:
    hz?.shutdown()
}

实际上，存在一个错误： IMap.delete()不应调用在3.2.6和3.3中修复的MapLoader.load() 。如果尚未升级，则即使IMap.delete()也将转到MapLoader 。如果您认为IMap.remove()令人惊讶，请查看put()工作原理！

如果您认为remove()首先加载值是可疑的，那么显式put()首先为给定键加载值怎么办？毕竟，我们明确地通过键将某些内容放入地图，为什么Hazelcast首先通过MapLoader加载此值？

def 'IMap.put() on non-existing key still calls loader (!)'() {
    given:
    MapLoader loaderMock = Mock()
    def hz = build(loaderMock)
    IMap<Integer, String> emptyCache = hz.getMap("cache")

    when:
    emptyCache.put(ANY_KEY, ANY_VALUE)

    then:
    1 * loaderMock.load(ANY_KEY)

    cleanup:
    hz?.shutdown()
}

再次，让我们还原到java.util.Map.put() JavaDoc：

V put(K键，V值)
[…]
返回值：

与key关联的先前值；如果没有key映射，则为null。

Hazelcast假设IMap只是对某些外部源的懒惰视图，因此当我们put()某些内容put() IMAP put()之前不存在的IMap中时，它会首先加载“ previous”值，以便它可以返回它。同样，当MapLoader速度慢或价格昂贵时，这又是一个大问题–如果我们可以明确地将某些内容放入地图中，为什么要先加载它？幸运的是，有一个简单的解决方法putTransient() ：

def "IMap.putTransient() doesn't call loader"() {
    given:
    MapLoader loaderMock = Mock()
    def hz = build(loaderMock)
    IMap<Integer, String> cache = hz.getMap("cache")

    when:
    cache.putTransient(ANY_KEY, ANY_VALUE, 1, TimeUnit.HOURS)

    then:
    0 * loaderMock.load(ANY_KEY)

    cleanup:
    hz?.shutdown()
}

一个警告是您必须显式提供TTL，而不是依赖于已配置的IMap默认值。但这也意味着您可以为每个映射条目分配任意TTL，不仅可以全局分配给整个映射-很有用。

记住我们的比喻： IMap与后盾MapLoader行为就像在数据的外部源视图。这就是为什么在空地图上的containsKey()会调用MapLoader并不令人惊讶的原因：

def "IMap.containsKey() calls loader"() {
    given:
    MapLoader loaderMock = Mock()
    def hz = build(loaderMock)
    IMap<Integer, String> emptyMap = hz.getMap("cache")

    when:
    emptyMap.containsKey(ANY_KEY)

    then:
    1 * loaderMock.load(ANY_KEY)

    cleanup:
    hz?.shutdown()
}

每当我们请求地图中不存在的键时，Hazelcast都会询问MapLoader 。同样，只要装载机速度快，无副作用且可靠，这不是问题。如果不是这种情况，将会杀死您：

def "IMap.get() after IMap.containsKey() calls loader twice"() {
    given:
    MapLoader loaderMock = Mock()
    def hz = build(loaderMock)
    IMap<Integer, String> cache = hz.getMap("cache")

    when:
    cache.containsKey(ANY_KEY)
    cache.get(ANY_KEY)

    then:
    2 * loaderMock.load(ANY_KEY)

    cleanup:
    hz?.shutdown()
}

尽管containsKey()调用MapLoader ，它不会“缓存”加载的值以供以后使用。这就是为什么containsKey()后跟get()两次调用MapLoader ，这非常浪费。幸运的是，如果您在现有密钥上调用containsKey() ，则它几乎立即运行，尽管很可能需要网络跳转。不幸的是，Hazelcast 3.3版之前的keySet() ， values() ， entrySet()和其他一些方法的行为。如果一次加载任何密钥，这些将全部阻止。因此，如果您有一个包含数千个键的映射，并且要求提供keySet() ，则缓慢的MapLoader.load()调用将阻塞整个群集。幸运的是，此问题已在3.3中修复，因此即使当前正在计算某些键，也不会阻塞IMap.keySet() ， IMap.values()等。

如您所见， IMap + MapLoader组合功能强大，但也充满陷阱。其中一些由API规定，osme由Hazelcast的分布式性质决定，最后一些是特定于实现的。在实施加载缓存功能之前，请确保您了解它们。

翻译自: https://www.javacodegeeks.com/2014/09/hazelcasts-maploader-pitfalls.html

hazelcast

cunhu2961

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
hazelcast_Hazelcast的MapLoader陷阱

hazelcast Hazelcast提供的核心数据结构之一是IMap<K, V> ，它扩展了java.util.concurrent.ConcurrentMap这基本上是一个分布式地图，通常用作缓存。您可以将此类地图配置为使用自定义MapLoader<K, V> –每次尝试从该地图(通过键)获取.get()尚不存在的某些内容时，都会询问该段Java代码。当您将IMa...
复制链接

扫一扫