blocks|key|2983626|text|Ehcache的一个优势是它得到了一家公司(Terracotta)的支持，该公司在一个大型性能实验室中进行广泛的性能、故障转移和平台测试。Terracotta提供支持、赔偿等。对于许多公司来说，这类事情很重要。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2983627|我没有用过Hazelcast，但我听说它很容易使用，而且很管用。关于Hazelcast与Terracotta/Ehcache的可扩展性或性能，我没有听说过任何东西，但考虑到Terracotta所做的可扩展性和故障转移测试，我很难想象Hazelcast在生产部署中会有竞争力。但我认为它在较小的用途上会工作得很好。|2983628|偏见:我是Terracotta的前雇员。|2983629|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

One advantage of Ehcache is that it is backed by a company (Terracotta) that does extensive performance, failover, and platform testing in a large performance lab. Terracotta provides support, indemnity, etc. For many companies, that sort of thing is important. 

I have not used Hazelcast but I've heard that it is easy to use and that it works. I haven't heard anything with respect to scalability or performance of Hazelcast vs Terracotta/Ehcache but given the amount of scalability and failover testing that Terracotta does, it's hard for me to imagine that Hazelcast would be competitive in a production deployment. But I presume it would work fine for smaller uses.

[Bias: I'm a former employee of Terracotta.]

blocks|key|274975|text|我们在最大的在线分类广告和电子商务平台之一尝试了这两种方法。我们从ehcache/+Terracotta+(服务器阵列)开始，因为它很有名，由Terracotta支持，并且比hazelcast拥有更大的社区支持。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|274976|当我们在生产环境(分布式，超越一个节点集群)上获得它时，情况发生了变化，我们的后端架构变得非常昂贵，所以我们决定给hazelcast一个机会。|274977|Hazelcast非常简单，它做到了它所说的，并且在没有任何配置开销的情况下运行得非常好。|274978|我们的缓存层在hazelcast上已经有一年多了，我们对此非常满意。|274979|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

We tried both of them for one of the largest online classifieds and e-commerce platform. We started with ehcache/terracotta(server array) cause it's well-known, backed by Terracotta and has bigger community support than hazelcast. When we get it on production environment(distributed,beyond one node cluster) things changed, our backend architecture became really expensive so we decided to give hazelcast a chance. 
Hazelcast is dead simple, it does what it says and performs really well without any configuration overhead. 
Our caching layer is on top of hazelcast for more than a year, we are quite pleased with it.

blocks|key|277008|text|尽管Ehcache在Java系统中很流行，但我发现它不如其他缓存解决方案灵活。我尝试了Hazelcast，是的，它完成了工作，它很容易运行等，而且它比Ehcache更新。我可以说，Ehcache比Hazelcast有更多的功能，更成熟，并且背后有很大的支持。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|277009|还有其他几个很好的缓存解决方案，都有不同的属性和解决方案，比如旧的Memcache，Membase+(现在的CouchBase)，Redis，AppFabric，甚至几个提供键值存储的NoSQL解决方案，不管有没有持久化。它们都有不同的特点，因为它们与事务一起实现CAP定理或基本定理。|277010|你应该更多地关注，在你的应用程序中，哪一个具有你想要的功能，同样，你应该为你的应用程序考虑CAP定理或基础定理。|277011|这个test是Netflix最近在云端的Cassandra上完成的。他们使用了大约300个实例来访问million+writes+per+second。Cassandra不是一个内存缓存，但是您的数据模型就像一个缓存，它由键值对组成。您也可以像使用分布式内存缓存一样使用Cassandra。|offset|length|277012|entityMap|0|LINK|mutability|MUTABLE|url|http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html|1|http://cassandra.apache.org/|2|3^0|0|0|0|2|4|0|K|9|1|1E|P|2|3R|9|3|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|X|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|Y|8|@]|9|@$H|Z|I|10|1|11]|$H|12|I|13|1|14]|$H|15|I|16|1|17]|$H|18|I|19|1|1A]]|A|$]]|$1|J|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|K|$L|$5|M|N|O|A|$P|Q]]|R|$5|M|N|O|A|$P|S]]|T|$5|M|N|O|A|$P|Q]]|U|$5|M|N|O|A|$P|S]]]]

Even though Ehcache has been popular among Java systems, I find it less flexible than other caching solutions. I played around with Hazelcast and yes it did the job, it was easy to get running etc and it is newer than Ehcache. I can say that Ehcache has much more features than Hazelcast, is more mature, and has big support behind it. 

There are several other good cache solutions as well, with all different properties and solutions such as good old Memcache, Membase (now CouchBase), Redis, AppFabric, even several NoSQL solutions which provides key value stores with or without persistence. They all have different characteristics in the sense they implement CAP theorem, or BASE theorem along with transactions. 

You should care more about, which one have the functionality you want in your application, again, you should consider CAP theorem or BASE theorem for your application.

This <a href="http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html">test</a> was done very recently with <a href="http://cassandra.apache.org/">Cassandra</a> on the cloud by Netflix. They reached to <a href="http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html">million writes per second</a> with about 300 instances. Cassandra is not a memory cache but you data model is like a cache, which is consist of key value pairs. You can as well use <a href="http://cassandra.apache.org/">Cassandra</a> as a distributed memory cache.

blocks|key|2983684|text|Hazelcast一直是规模的噩梦，稳定性仍然是一个主要问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2983685|专用的客户端到网格组件的选择包括|2983686|2983687|是一个凌乱的版本，无法在任何地方的节点丢失中幸存下来，这否定了备份的要点(超级客户端)，或者|ordered-list-item|2983688|是一个极其缓慢的本机客户端选项，它不允许对网格中的处理节点进行任何类型的负载平衡。|2983689|2983690|如果任何主机可以从这个数据网格请求记录，这将是一个很好的设计，但您只能使用这两个平淡无奇的选项才能从中获得任何东西。|2983691|此外，数据库线程池锁定在单个成员上并且没有向数据库写入任何内容的多个问题，导致永久记录丢失是一个常见的问题，我们经常不得不将整个问题关闭几个小时来刷新JVM的任何一个。大脑分裂也仍然是一个问题，尽管在1.9.6中似乎已经平静了一些。|2983692|转向Ehcache并改进数据库层，而不是将其用作创可贴。|2983693|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|T|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|V|8|@]|9|@]|A|$]]|$1|H|3|I|5|G|7|W|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|Y|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|Z|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|10|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|R|$]]

Hazelcast has been a nightmare to scale and stability is still a major issue. 

The dedicated client to grid component choices are 

<ol>
<li>The messy version that cant survive node loss anywhere, negating the point of backups (superclient), or </li>
<li>An incredibly slow native client option that does not allow for any type of load balancing to processing nodes in the grid. </li>
</ol>

If any host could request records from this data grid it would be a sweet design, but you are stuck with those two lackluster option to get anything out of it. 

Also multiple issues with database thread pools locking up on individual members and not writing anything to the databases, causing permanent records loss is a frequent issue and we often have to take the whole thing down for hours to refresh any of the JVM's. Split brain is also still an issue, although in 1.9.6 it seems to have calmed down a little.

Rallying to move to Ehcache and improving the database layer instead of using this as a band-aid.

blocks|key|280613|text|只要有一个节点(standard-one)，Hazelcast就会序列化所有内容，因此您要保存到Hazelcast的数据必须实现序列化。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|280614|http://open.bekk.no/efficient-java-serialization/|offset|length|280615|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1D|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

Hazelcast serializes everything whenever there is a node (standard-one), so the data you will save to Hazelcast must implement serialization. 

<a href="http://open.bekk.no/efficient-java-serialization/" rel="noreferrer">http://open.bekk.no/efficient-java-serialization/</a>

blocks|key|275045|text|Hazelcast对我来说是一场噩梦。我能够让它在集群Websphere环境中“工作”。我松散地使用“工作”这个词。首先，Hazelcast的所有文档都过时了，并且只显示了使用不推荐使用的方法调用的示例。尝试在Javadoc中使用没有注释的新代码，并且在文档中没有示例，这是非常困难的。此外，J2EE容器代码在这一点上根本不起作用，因为它不支持Websphere中的XA事务。调用显式遵循其唯一J2EE示例的代码时会抛出错误(看起来里程碑3.0正在解决此问题)。我不得不忘记将Hazelcast加入到J2EE交易中。看起来Hazelcast确实是面向非EJB/非J2EE容器环境的。在从一个企业java+bean切换到另一个时，调用Hazelcast.getAllInstances()无法保留有关Hazelcast状态的任何信息。这迫使我创建一个新的Hazelcast实例，仅仅是为了运行允许我访问数据的调用。这会导致许多Hazelcast实例在同一JVM上启动。此外，从Hazelcast检索数据也不快。我尝试使用Native+Client和直接作为集群成员检索数据。我存储了51个列表，每个列表只包含Hazelcast中的625个对象。我不能直接在列表上执行查询，也不想仅仅为了访问该特性而存储地图(可以在地图上执行SQL操作)。检索每个包含625个对象的列表花费了大约半秒的时间，因为Hazelcast序列化了整个列表并通过网络将其发送给我，而不仅仅是给我增量(发生了什么变化)。另外，我必须切换到TCPIP配置，并显式列出我希望位于集群中的服务器的ip地址。默认的组播配置不起作用，从谷歌的小组讨论来看，其他人也遇到了同样的困难。总而言之，经过几个小时痛苦的编程配置和试错，我最终得到了8台机器在集群中通信(文档将没有什么帮助)，但当我这样做时，由于用于EJB/J2EE的Hazelcast的半成品性质，我仍然无法控制在每个JVM上创建的实例和分区的数量，而且速度非常慢。我在我工作的失业保险应用程序中实现了一个真实的用例，代码直接调用数据库的速度要快得多。如果Hazelcast像广告中所说的那样工作，那就太酷了，因为我真的不想使用单独的服务来实现我想要做的事情。我广泛地使用了MongoDB，所以我可以跳过整个内存缓存，只将我的对象序列化为单独存储库中的文档。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|275046|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Hazelcast has been a nightmare for me. I was able to get it "working" in a clustered Websphere environment. I use the term "working" loosely. First, all of Hazelcast's documentation is out of date and only shows examples using deprecated method calls. Trying to use the new code without comments in the Javadocs and no examples in the documentation is very hard. Also, the J2EE container code simply does not work at this point because it does not support XA transactions in Websphere. An error is thrown calling code that follows their only J2EE example explicitly(it does look like Milestone 3.0 is addressing this). I had to forget about joining Hazelcast to a J2EE transaction. It does seem Hazelcast is definitely geared to a non EJB/Non-J2EE container environment. Making calls to Hazelcast.getAllInstances() fails to retain any information about Hazelcast's state when switching from one enterprise java bean to another. That forces me to create a new Hazelcast instance just to run calls that give me access to my data. That causes many Hazelcast Instances to start up on the same JVM. Also,retrieving data from Hazelcast is not fast. I tried retrieving data using both the Native Client and directly as a member of the cluster. I stored 51 lists, each containing only 625 objects in Hazelcast. I could not perform a query directly on a list and did not want to store a map just to get access to that feature (SQL operations can be performed on a map). It took about a half second to retrieve each list of 625 objects because Hazelcast Serializes the entire list and sends it over the wire rather than just giving me the delta (what has changed). Another thing, I had to switch to a TCPIP configuration and explicitly list the ip addresses of the servers I wanted to be in the cluster. The default Multicast configuration did not work and from the group discussions in google, other people are experiencing that difficulty as well. To sum up; I did eventually get 8 machines communicating in a cluster through many hours of torturous programmatic configuration and trial and error (the documentation will be little help) but when I did, I still had no control over the number of instances and partitions being created on each JVM due to the half finished nature of Hazelcast for EJB/J2EE and it was VERY SLOW. I implemented a real use case in the unemployment insurance application I work on and the code was much faster making direct calls to the database. It would have been cool if Hazelcast worked as advertised because I really did not want to use a separate service to implement what I am trying to do. I have used MongoDB extensively so I may skip the whole in memory cache and just serialize my objects as documents in a separate repository.

blocks|key|3197265|text|开发人员将Ehcache描述为“Java最广泛使用的Cache”。Ehcache是一种开源的、基于标准的缓存，用于提高性能、减轻数据库负载并简化可伸缩性。它是使用最广泛的基于Java的缓存，因为它健壮、可靠且功能齐全。Ehcache从具有一个或多个节点的进程内扩展到具有to大小缓存的混合进程内/进程外配置。另一方面，Hazelcast被详细描述为“Java集群和高度可扩展的数据分发平台”。凭借其各种分布式数据结构、分布式缓存功能、弹性特性、memcache支持、与Spring和Hibernate的集成，更重要的是，拥有如此多的快乐用户，Hazelcast是一个功能丰富、企业就绪和开发人员友好的内存中数据网格解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3197266|Ehcache和Hazelcast主要分为“缓存”和“内存数据库”工具。|3197267|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Developers describe Ehcache as &quot;Java's Most Widely-Used Cache&quot;. Ehcache is an open-source, standards-based cache for boosting performance, offloading your database, and simplifying scalability. It's the most widely-used Java-based cache because it's robust, proven, and full-featured. Ehcache scales from in-process, with one or more nodes, all the way to mixed in-process/out-of-process configurations with terabyte-sized caches. On the other hand, Hazelcast is detailed as &quot;Clustering and highly scalable data distribution platform for Java&quot;. With its various distributed data structures, distributed caching capabilities, elastic nature, memcache support, integration with Spring and Hibernate and more importantly with so many happy users, Hazelcast is feature-rich, enterprise-ready and developer-friendly in-memory data grid solution.
Ehcache and Hazelcast are primarily classified as &quot;Cache&quot; and &quot;In-Memory Databases&quot; tools respectively.

Question is clear as you see in the title, it would be appreciated to hear your ideas about adv./disadv. differences between them.

UPDATE:
I have decided to use Hazelcast because of the advantages like distributed caching/locking mechanism as well as the extremely easy configuration while adapting it to your application.

hazelcast vs ehcache

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

问题很清楚，正如你在标题中看到的那样，如果能听到你对adv./disadv的想法，我将不胜感激。它们之间的差异。更新：我决定使用Hazelcast，因为它具有分布式缓存/锁定机制等优点，而且在适应您的应用程序时配置非常简单。

问hazelcast vs ehcache
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问hazelcast vs ehcacheEN