我们正在尝试在我们的应用程序中使用 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 的对象放入映射中,内存中可以有大约 400-500 个这样的活动对象。我们在应用程序中经常使用缓存。
早些时候,我们使用 EhCache 和为缓存实现配置的 JGroups。操作速度相当快。但当我们尝试使用 Hazelcast 时,我发现运行时间存在相当大的差异。我可以理解 Hazelcast 不仅仅是一个缓存实现。但只是想知道为什么与 EhCache(使用 jgroups)相比操作变得非常慢。我们所做的配置是否有问题?请建议!
另请注意,我正在单节点计算机上对此进行测试。
所有分布式缓存解决方案都会产生序列化方面的成本。由于您希望数据位于 JVM 之外,因此没有办法绕过它。
使用 JGroups 进行复制的 Ehcache 可能通过异步执行复制来隐藏此成本,但您有效地zero此设置中的一致性保证。
分布式解决方案,无论是使用 Ehcache 还是 Hazelcast,都将提供一致性保证。但这会增加由于一致性执行而导致的成本。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)