正如您在标题中看到的那样，问题很清楚，很高兴听到您对 adv./disadv 的想法。他们之间的差异。
更新： 我决定使用 Hazelcast，因为它具有分布式缓存/锁定机制等优点，以及在适应您的应用程序时配置极其简单。
问问题
40303 次
7 回答
93
我们为最大的在线分类广告和电子商务平台之一尝试了这两种方法。我们从 ehcache/terracotta（服务器阵列）开始，因为它是众所周知的，由 Terracotta 支持，并且比 hazelcast 拥有更大的社区支持。
当我们在生产环境（分布式，超出一个节点集群）上得到它时，事情发生了变化，我们的后端架构变得非常昂贵，所以我们决定给 hazelcast 一个机会。
Hazelcast 非常简单，它做到了它所说的并且执行得非常好，没有任何配置开销。
我们的缓存层在 hazelcast 之上使用了一年多，我们对此非常满意。
于 2011-03-11T09:59:19.840 回答
19
尽管 Ehcache 在 Java 系统中很流行，但我发现它不如其他缓存解决方案灵活。我玩过 Hazelcast，是的，它完成了这项工作，它很容易运行等，而且它比 Ehcache 更新。我可以说 Ehcache 比 Hazelcast 有更多的功能，更成熟，背后有很大的支持。
还有其他几个很好的缓存解决方案，具有所有不同的属性和解决方案，例如很好的旧 Memcache、Membase（现在的 CouchBase）、Redis、AppFabric，甚至还有几个提供带或不带持久性的键值存储的 NoSQL 解决方案。它们在实现 CAP 定理或 BASE 定理以及事务的意义上都有不同的特征。
您应该更关心哪一个具有您想要的应用程序功能，同样，您应该为您的应用程序考虑 CAP 定理或 BASE 定理。
这项测试是最近由 Netflix 在云上使用Cassandra完成的。他们通过大约 300 个实例达到每秒百万次写入。Cassandra 不是内存缓存，但您的数据模型就像一个缓存，由键值对组成。您也可以将Cassandra用作分布式内存缓存。
于 2011-11-04T18:50:20.157 回答
12
Hazelcast 一直是规模的噩梦，稳定性仍然是一个主要问题。
网格组件选择的专用客户端是
- 无法在任何地方丢失节点的混乱版本，否定备份点（超级客户端），或
- 一个非常慢的本机客户端选项，不允许对网格中的处理节点进行任何类型的负载平衡。
如果任何主机都可以从这个数据网格请求记录，那将是一个很好的设计，但你会被这两个乏善可陈的选项卡住以从中获取任何东西。
此外，数据库线程池的多个问题锁定在单个成员上并且没有向数据库写入任何内容，导致永久记录丢失是一个常见问题，我们经常不得不将整个事情停机数小时以刷新任何 JVM。虽然在 1.9.6 中它似乎已经平静了一点，但裂脑仍然是一个问题。
团结起来迁移到 Ehcache 并改进数据库层，而不是将其用作创可贴。
于 2012-02-24T00:29:26.493 回答
7
只要有节点（标准节点），Hazelcast 就会序列化所有内容，因此您将保存到 Hazelcast 的数据必须实现序列化。
于 2012-05-30T06:43:46.953 回答
6
Hazelcast 对我来说是一场噩梦。我能够让它在集群的 Websphere 环境中“工作”。我松散地使用术语“工作”。首先，Hazelcast 的所有文档都已过时，仅显示使用不推荐使用的方法调用的示例。尝试在 Javadocs 中使用没有注释且文档中没有示例的新代码非常困难。此外，J2EE 容器代码此时根本无法工作，因为它不支持 Websphere 中的 XA 事务。显式调用遵循其唯一 J2EE 示例的代码会引发错误（看起来 Milestone 3.0 正在解决此问题）。我不得不忘记将 Hazelcast 加入到 J2EE 事务中。看起来 Hazelcast 确实适用于非 EJB/Non-J2EE 容器环境。打电话给 Hazelcast。当从一个企业 java bean 切换到另一个时，getAllInstances() 无法保留有关 Hazelcast 状态的任何信息。这迫使我创建一个新的 Hazelcast 实例，只是为了运行允许我访问数据的调用。这导致许多 Hazelcast 实例在同一个 JVM 上启动。此外，从 Hazelcast 检索数据并不快。我尝试使用 Native Client 和直接作为集群成员检索数据。我在 Hazelcast 中存储了 51 个列表，每个列表仅包含 625 个对象。我无法直接对列表执行查询，也不想存储地图只是为了访问该功能（可以在地图上执行 SQL 操作）。检索每个 625 个对象的列表大约需要半秒，因为 Hazelcast 序列化整个列表并通过网络发送它，而不是只给我增量（发生了什么变化）。另一件事，我必须切换到 TCPIP 配置并明确列出我想在集群中的服务器的 IP 地址。默认的多播配置不起作用，从谷歌的小组讨论中，其他人也遇到了这个困难。总结一下; 经过数小时痛苦的编程配置和反复试验，我最终确实让 8 台机器在集群中进行通信（文档帮助不大），但是当我这样做时，由于 Hazelcast for EJB/J2EE 的半成品性质，我仍然无法控制在每个 JVM 上创建的实例和分区的数量，而且速度非常慢。我在我工作的失业保险应用程序中实现了一个真实的用例，代码直接调用数据库的速度要快得多。如果 Hazelcast 像宣传的那样工作会很酷，因为我真的不想使用单独的服务来实现我正在尝试做的事情。我已经广泛使用 MongoDB，所以我可以跳过内存缓存中的整个内容，而只是将我的对象序列化为单独存储库中的文档。如果 Hazelcast 像宣传的那样工作会很酷，因为我真的不想使用单独的服务来实现我正在尝试做的事情。我已经广泛使用 MongoDB，所以我可以跳过内存缓存中的整个内容，而只是将我的对象序列化为单独存储库中的文档。如果 Hazelcast 像宣传的那样工作会很酷，因为我真的不想使用单独的服务来实现我正在尝试做的事情。我已经广泛使用 MongoDB，所以我可以跳过内存缓存中的整个内容，而只是将我的对象序列化为单独存储库中的文档。
于 2012-10-24T15:16:23.990 回答
4
Ehcache 的一个优势是它得到了一家公司 (Terracotta) 的支持，该公司在大型性能实验室中进行了广泛的性能、故障转移和平台测试。Terracotta 提供支持、赔偿等。对于许多公司来说，这类事情很重要。
我没有使用过 Hazelcast，但我听说它很容易使用并且很有效。我没有听说过有关 Hazelcast 与 Terracotta/Ehcache 的可扩展性或性能方面的任何消息，但考虑到 Terracotta 所做的可扩展性和故障转移测试的数量，我很难想象 Hazelcast 在生产部署中会具有竞争力。但我认为它适用于较小的用途。
[偏见：我是Terracotta的前雇员。]
于 2011-03-09T14:51:37.280 回答
0
开发人员将 Ehcache 描述为“Java 最广泛使用的缓存”。Ehcache 是一个开源的、基于标准的缓存，用于提高性能、卸载数据库并简化可扩展性。它是使用最广泛的基于 Java 的缓存，因为它健壮、经过验证且功能齐全。Ehcache 从具有一个或多个节点的进程内扩展到具有 TB 级缓存的混合进程内/进程外配置。另一方面，Hazelcast 被详细描述为“Java 的集群和高度可扩展的数据分发平台”。凭借其各种分布式数据结构、分布式缓存能力、弹性特性、memcache 支持、与 Spring 和 Hibernate 的集成，更重要的是拥有如此多的快乐用户，Hazelcast 功能丰富，
Ehcache 和 Hazelcast 主要分别被归类为“缓存”和“内存数据库”工具。
于 2020-08-03T19:12:35.760 回答