logo标签列表

Hazelcast与Ehcache对比

ehcachehazelcast
64

正如您在标题中所看到的那样，问题很明确，希望听听您对它们之间优缺点差异的看法。

更新： 我决定使用Hazelcast，因为它具有分布式缓存/锁定机制以及极其简单的配置，可将其适应于您的应用程序，这些都是它的优点。

7个回答
94

我们为最大的在线分类广告和电子商务平台尝试了两种技术。我们首先选择了ehcache/terracotta(服务器数组)，因为它很著名，由Terracotta支持，并且拥有比hazelcast更大的社区支持。
但当我们将其应用于生产环境（分布式、超出一个节点集群）时，情况发生了变化，我们的后端架构变得非常昂贵，因此我们决定给hazelcast一个机会。

Hazelcast非常简单易用，不需要任何配置就可以实现良好的性能表现。

我们的缓存层已经使用hazelcast一年多了，我们对它非常满意。

1
从内存中的单节点Java缓存切换到Hazelcache时，是否会出现明显的减速？ - Pinch
19
尽管Ehcache在Java系统中很受欢迎，但我发现它比其他缓存解决方案不够灵活。我试用了Hazelcast，确实做得很好，易于运行等等，而且它比Ehcache更新。我可以说，Ehcache比Hazelcast拥有更多的功能，更加成熟，并且有强大的支持。
还有其他几种好的缓存解决方案，具有不同的属性和解决方案，如老牌的Memcache、Membase（现在是CouchBase）、Redis、AppFabric，甚至几个提供带或不带持久性的键值存储的NoSQL解决方案。它们在实现CAP定理或BASE定理以及事务方面具有不同的特点。
你应该更关心哪一个在你的应用程序中具有所需的功能，同样，你应该考虑应用程序的CAP定理或BASE定理。
这项测试最近由Netflix在云上使用Cassandra完成。他们使用大约300个实例达到了每秒百万次写入。Cassandra不是内存缓存，但你的数据模型就像一个缓存，由键值对组成。你也可以将Cassandra用作分布式内存缓存。
1
如何实现CAP定理？ - Kyle
2
CAP并不是要被实现的，因为它表明在分布式系统中你不能同时拥有一致性、可用性和分区容错性。基本上，可用性优先于一致性，但数据最终将达到一致性，软状态意味着数据存储在易失性存储器中，例如RAM。大多数分布式缓存和NoSQL产品都实现了BASE...所以BASE是处理CAP的一种方式。 - user454322
12

Hazelcast在扩展性方面一直是一个噩梦，稳定性仍然是一个主要问题。

专用客户端到网格组件的选择有：

  1. 混乱版本无法在任何地方生存，否则会使备份丧失意义（超级客户端）。
  2. 非常缓慢的本地客户端选项，不允许在网格中处理节点之间进行任何类型的负载平衡。

如果任何主机都可以从此数据网格请求记录，那将是一个很好的设计，但您只能使用这两种平庸的选项来获取任何信息。

此外，数据库线程池在个别成员上锁定并且不写入任何内容到数据库时出现多个问题，导致永久记录丢失是一个经常性的问题，我们通常需要关闭整个系统数小时以刷新任何JVM。虽然在1.9.6中发生分裂大脑的情况似乎已经有所减少。

我们正在努力转移到Ehcache并改进数据库层，而不是将其用作应急措施。

38
PS：我在Hazelcast工作。James，真的很抱歉你在使用Hazelcast时遇到了严重的问题。据我记得，您当时使用Hazelcast就像关系型数据库一样进行查询，我们建议您将其改为键/值模式。使用键的访问模式比执行查询要快得多。然而，我同意，在Hazelcast 1.9中，有时节点丢失会强制重新启动集群。在1.9之后，我们发布了Hazelcast 2，现在已经是2.6.2版本，最近还发布了Hazelcast 3。我们大大改进了集群层。 - Fuad Malikov
1
詹姆斯，你是否對不同的解決方案進行了 PoC 測試？結果如何？你是否需要更改應用程式架構？ - Ajay Gautam
7
1
Terracotta在流式传输对象时不进行序列化吗？ - FreeDevz
@FreeDevz - 根据其文档，TerraCotta正在使用字节码插入来自动序列化对象，而无需编写序列化代码。但我不能确定这是否比标准或手工编码的序列化更有效率。 - Tom Dibble
6
Hazelcast对我来说是一场噩梦。在集群的WebSphere环境中，我能够让它“工作”。我使用“工作”这个词很宽泛。首先，所有Hazelcast的文档都已经过时了，并且只显示使用已弃用的方法调用的示例。尝试在没有Javadocs注释和文档中没有示例的情况下使用新代码非常困难。此外，J2EE容器代码目前根本不起作用，因为它不支持Websphere中的XA事务。调用遵循他们唯一的J2EE示例的代码会抛出错误(看起来里程碑3.0正在解决这个问题)。我不得不忘记将Hazelcast加入到J2EE事务中。似乎Hazelcast绝对是面向非EJB/非J2EE容器环境的。当从一个企业Java Bean切换到另一个时，调用Hazelcast.getAllInstances()无法保留任何关于Hazelcast状态的信息。这迫使我创建一个新的Hazelcast实例，只是为了运行给我访问数据的调用。这会导致许多Hazelcast实例在同一个JVM上启动。此外，从Hazelcast检索数据并不快速。我尝试使用Native Client和直接作为集群成员检索数据。我在Hazelcast中存储了51个列表，每个列表仅包含625个对象。我无法直接在列表上执行查询，并且不想存储映射以获取该功能的访问权限(SQL操作可以在映射上执行)。由于Hazelcast序列化整个列表并将其发送到网络上，而不是只给我增量(已更改的内容)，因此检索每个625个对象的列表需要大约半秒钟。另外一件事，我必须切换到TCPIP配置，并显式列出我想要加入集群的服务器的IP地址。默认的多播配置不起作用，从谷歌的组讨论中可以看出其他人也遇到了这个困难。总之，通过漫长的编程配置和试错(文档几乎没有帮助)，我最终确实让8台机器在集群中通信，但当我这样做时，由于Hazelcast对EJB/J2EE的半成品性质，我仍然无法控制每个JVM上创建的实例和分区的数量，而且速度非常慢。我在失业保险应用程序中实现了一个真正的用例，使用直接调用数据库的代码要快得多。如果Hazelcast按照广告宣传的那样工作，那就太棒了，因为我真的不想使用单独的服务来实现我想做的事情。我已经广泛使用了MongoDB，所以我可能会跳过整个内存缓存，只将我的对象序列化为单独存储库中的文档。
你有没有将其与hazelcast的“弹性memcached”配置进行比较？http://www.hazelcast.org/use-cases/caching/ 我很想知道将文档存储与本机接口进行比较的情况。 - elwarren
4
Ehcache的一个优点是它由一家公司（Terracotta）支持，该公司在一个大型性能实验室中进行了广泛的性能、故障转移和平台测试。Terracotta提供支持、保障等服务。对于许多公司来说，这种支持至关重要。
我没有使用过Hazelcast，但我听说它易于使用且有效。我还没有听说过Hazelcast与Terracotta/Ehcache在可扩展性或性能方面的比较，但考虑到Terracotta进行的大量可扩展性和故障转移测试，很难想象Hazelcast在生产部署中会有竞争力。但我认为对于小规模的使用，它应该可以正常工作。
[偏见：我曾经是Terracotta的员工。]
0
开发者描述Ehcache为“Java最广泛使用的缓存”。Ehcache是一个基于标准的开源缓存，用于提高性能、卸载数据库和简化可扩展性。它是最广泛使用的基于Java的缓存，因为它强大、经过验证且功能齐全。Ehcache从进程内，带有一个或多个节点，一直扩展到混合进程/外部进程配置，具有千兆字节级别的缓存。另一方面，Hazelcast被详细描述为“用于Java的群集和高度可扩展的数据分发平台”。由于其各种分布式数据结构、分布式缓存能力、弹性特性、内存缓存支持、与Spring和Hibernate的集成以及众多用户的积极反馈，Hazelcast是功能丰富、企业就绪并且开发人员友好的内存数据网格解决方案。
Ehcache和Hazelcast主要被归类为“缓存”和“内存数据库”工具。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接