hazelcast vs ehcache

Question

问题很明显，正如您在标题中看到的那样，我将很高兴听到您对adv./disadv的看法。他们之间的差异。

更新 我决定使用Hazelcast，因为它具有分布式缓存/锁定机制等优点，并且在适应您的应用程序时非常容易配置。

Answer 1

我们尝试了两种最大的在线分类和电子商务平台。我们从ehcache / terracotta（服务器阵列）开始，因为它是着名的，由Terracotta支持并且拥有比hazelcast更大的社区支持。
当我们在生产环境（分布式，超出一个节点集群）上获得它时，事情发生了变化，后端架构变得非常昂贵所以我们决定给榛树一个机会。

Hazelcast非常简单，它可以完成它所说的并且在没有任何配置开销的情况下表现非常好。

我们的缓存层在淡褐色的基础上超过一年，我们对它非常满意。

Answer 2

尽管Ehcache在Java系统中很受欢迎，但我发现它不如其他缓存解决方案灵活。我和Hazelcast一起玩，是的，它完成了工作，很容易运行等等，它比Ehcache更新。我可以说Ehcache比Hazelcast具有更多功能，更成熟，并且背后有很大的支持。

还有其他一些优秀的缓存解决方案，具有所有不同的属性和解决方案，例如良好的旧Memcache，Membase（现在的CouchBase），Redis，AppFabric，甚至几种NoSQL解决方案，它们提供具有或不具有持久性的密钥值存储。它们在实现CAP定理或BASE定理以及交易时都具有不同的特征。

您应该更关心，哪一个在您的应用程序中具有您想要的功能，您应该再考虑CAP定理或BASE定理。

此test最近由Netflix在云端进行了Cassandra。他们通过大约300个实例到达million writes per second。 Cassandra不是内存缓存，但您的数据模型就像一个缓存，它由键值对组成。您也可以使用Cassandra作为分布式内存缓存。

Answer 3

Hazelcast一直是规模化的噩梦，稳定性仍然是一个主要问题。

网格组件选择的专用客户端是

1. 凌乱的版本无法在任何地方丢失节点，否定备份点（超级客户端）或
2. 一个非常慢的本机客户端选项，它不允许任何类型的负载平衡来处理网格中的节点。

如果任何主机可以从这个数据网格中请求记录，那么这将是一个甜蜜的设计，但你仍然坚持使用这两个平淡无奇的选项来从中获取任何东西。

数据库线程池锁定单个成员而不向数据库写入任何内容时会出现多个问题，导致永久性记录丢失是一个常见问题，我们经常需要花费数小时来刷新任何JVM。裂脑仍然是一个问题，虽然在1.9.6中似乎已经平静了一点。

集会转移到Ehcache并改进数据库层，而不是将其用作创可贴。

Answer 4

只要有节点（标准节点），Hazelcast会将所有内容序列化，因此您保存到Hazelcast的数据必须实现序列化。

http://open.bekk.no/efficient-java-serialization/

Answer 5

对我而言，Hazelcast一直是个噩梦。我能够在集群的Websphere环境中“工作”。我松散地使用“工作”一词。首先，Hazelcast的所有文档都已过时，仅显示使用弃用方法调用的示例。尝试在Javadocs中使用没有注释的新代码，并且文档中没有示例是非常困难的。此外，J2EE容器代码此时不起作用，因为它不支持Websphere中的XA事务。抛出一个错误调用显式跟随他们唯一的J2EE示例的代码（它看起来像Milestone 3.0正在解决这个问题）。我不得不忘记将Hazelcast加入到J2EE事务中。看起来Hazelcast肯定适用于非EJB /非J2EE容器环境。当从一个企业java bean切换到另一个企业java bean时，调用Hazelcast.getAllInstances（）无法保留有关Hazelcast状态的任何信息。这迫使我创建一个新的Hazelcast实例，只是为了运行允许我访问我的数据的调用。这导致许多Hazelcast实例在同一个JVM上启动。此外，从Hazelcast检索数据并不快。我尝试使用Native Client和直接作为群集成员检索数据。我存储了51个列表，每个列表在Hazelcast中只包含625个对象。我无法直接在列表上执行查询，并且不希望存储地图只是为了访问该功能（可以在地图上执行SQL操作）。检索每个625个对象列表需要大约半秒钟，因为Hazelcast序列化整个列表并通过网络发送它而不是仅仅给我三角形（已经改变了）。另一件事，我不得不切换到TCPIP配置并明确列出我想要在群集中的服务器的IP地址。默认的多播配置不起作用，并且从谷歌的小组讨论中，其他人也遇到了这种困难。总结一下;通过数小时的曲折编程配置和反复试验，我最终得到8台机器在集​​群中进行通信（文档将没什么帮助）但是当我这样做时，我仍无法控制每个机器上创建的实例数和分区数。 JVM由于Hazelcast for EJB / J2EE的半成品特性而且非常慢。我在我工作的失业保险申请中实施了一个真实的用例，并且代码更快地直接调用数据库。如果Hazelcast像宣传的那样工作会很酷，因为我真的不想使用单独的服务来实现我想要做的事情。我已经广泛使用了MongoDB，所以我可以跳过整个内存缓存，只是将我的对象序列化为一个单独的存储库中的文档。

Answer 6

Ehcache的一个优势是它得到了一家公司（Terracotta）的支持，该公司在大型性能实验室中进行广泛的性能，故障转移和平台测试。 Terracotta提供支持，赔偿等。对于许多公司来说，这类事情很重要。

我没有使用Hazelcast，但我听说它易于使用且有效。关于Hazelcast与Terracotta / Ehcache的可扩展性或性能，我没有听说过任何内容，但考虑到Terracotta的可扩展性和故障转移测试的数量，我很难想象Hazelcast在生产部署中具有竞争力。但我认为它适用于较小的用途。

[偏见：我是Terracotta的前雇员。]

Answer 7

开发人员将Ehcache描述为“ Java最广泛使用的缓存”。 Ehcache是​​基于标准的开源缓存，可提高性能，减轻数据库负担并简化可伸缩性。它是最广泛使用的基于Java的缓存，因为它功能强大，经过验证且功能齐全。 Ehcache从具有一个或多个节点的进程内扩展一直到具有TB级缓存的进程内/进程外混合配置。另一方面，Hazelcast被详细描述为“用于Java的集群和高度可扩展的数据分发平台”。 Hazelcast具有各种分布式数据结构，分布式缓存功能，弹性特性，内存缓存支持，与Spring和Hibernate的集成以及更重要的是与众多快乐用户的集成，是功能丰富，面向企业且对开发人员友好的内存中数据网格解决方案

Ehcache和Hazelcast主要分别分类为“缓存”和“内存数据库”工具。