gpt4 book ai didi

java - Hazelcast 执行速度较慢

转载 作者:行者123 更新时间:2023-12-01 06:32:18 28 4
gpt4 key购买 nike

我们正在尝试在我们的应用程序中使用 Hazelcast 作为分布式缓存。这是我们的配置:

<hazelcast xsi:schemaLocation="http://www.hazelcast.com/schema/config hazelcast-config-3.7.xsd" xmlns="http://www.hazelcast.com/schema/config"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<group>
<name>sample_dev</name>
<password>dev@123</password>
</group>
<management-center enabled="false">http://localhost:8080/mancenter</management-center>
<properties>
<property name="hazelcast.logging.type">slf4j</property>
<property name="hazelcast.socket.bind.any">false</property>
</properties>
<serialization>
<serializers>
<global-serializer override-java-serialization="true">com.prasanth.common.KryoSerializer</global-serializer>
</serializers>
</serialization>
<network>
<join>
<multicast enabled="false"/>
<tcp-ip enabled="true">
<member-list>
<member>127.0.0.1:5701</member>
</member-list>
</tcp-ip>
</join>
<interfaces enabled="false">
<interface>192.168.3.*</interface>
</interfaces>
</network>
<map name="com.prasanth.cache.CachedAsset">
<in-memory-format>BINARY</in-memory-format>
<backup-count>1</backup-count>
<async-backup-count>1</async-backup-count>
<time-to-live-seconds>86400</time-to-live-seconds>
<max-idle-seconds>1200</max-idle-seconds>
<eviction-policy>LRU</eviction-policy>
<max-size policy="PER_NODE">4500</max-size>
<merge-policy>com.hazelcast.map.merge.LatestUpdateMapMergePolicy</merge-policy>
<!--<read-backup-data>true</read-backup-data>-->
<near-cache>
<in-memory-format>OBJECT</in-memory-format>
<cache-local-entries>true</cache-local-entries>
<time-to-live-seconds>86400</time-to-live-seconds>
<max-idle-seconds>1200</max-idle-seconds>
<invalidate-on-change>true</invalidate-on-change>
</near-cache>
</map>
</hazelcast>

从文档中,我可以看到每次调用 Hazelcast 时,都会涉及反序列化。因此,为了优化调用,我们使用 Kryo 作为默认序列化器并实现了近缓存。我们必须将每个大小为 500KB 的对象放入 map 中,内存中可以有大约 400-500 个这样的 Activity 对象。我们在应用程序中经常使用缓存。

之前我们使用 EhCache 和为缓存实现配置的 JGroups。操作相当快。但是,当我们尝试使用 Hazelcast 时,我发现运行时间存在一些相当大的差异。我可以理解 Hazelcast 不仅仅是一个缓存实现。但只是想知道为什么与 EhCache(使用 jgroups)相比操作变得非常慢。我们所做的配置有问题吗?请推荐!

另请注意,我是在单节点机器上对此进行测试。

最佳答案

所有分布式缓存解决方案都会产生与序列化相关的成本。由于您希望数据位于 JVM 之外,因此没有其他办法。

使用 JGroups 进行复制的 Ehcache 可能通过异步执行复制来隐藏此成本,但您在此设置中实际上一致性保证。

分布式解决方案,无论是使用 Ehcache 还是 Hazelcast,都将提供一致性保证。但这会因一致性强制执行而增加成本。

关于java - Hazelcast 执行速度较慢,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/42764205/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com