榛子vs ehcache
问题很明显，正如你在标题中看到的那样，我将不胜感激听到你对adv./disadv的想法。 他们之间的差异。
更新：我已经决定使用Hazelcast，因为分布式caching/locking机制的优点，以及非常容易的configuration，同时适应您的应用程序。
我们尝试了其中一个最大的在线分类和电子商务平台之一。 我们从ehcache / terracotta（服务器arrays）开始，因为它是众所周知的，由Terracotta支持，并且拥有比hazelcast更多的社区支持。
当我们在生产环境（分布式，超越一个节点集群）上做出改变时，我们的后端架构变得非常昂贵，所以我们决定给榛树一个机会。
Hazelcast是简单的死了，它没有任何configuration的开销，它performance得很好。
我们的caching层已经超过了一年的时间，我们对此非常满意。
尽pipeEhcache在Java系统中很stream行，但我发现它比其他caching解决scheme更不灵活。 我和Hazelcast一起玩过，是的，它做的很好，很容易跑步等等，比Ehcache更新。 我可以说Ehcache比Hazelcast有更多的function，比较成熟，并且有很大的支持。
还有其他几个好的caching解决scheme，以及所有不同的属性和解决scheme，比如老式的Memcache，Membase（现在的CouchBase），Redis，AppFabric，甚至还有几个NoSQL解决scheme，它们提供了有或没有持久性的关键价值存储。 它们在实现CAP定理或者BASE定理以及交易的意义上都有不同的特征。
你应该更关心，哪一个在你的应用程序中有你想要的function，再次，你应该考虑CAP定理或BASE定理。
Netflix最近在Cassandra上进行了这个testing 。 他们达到了每秒百万次 ，大约有300次。 Cassandra不是一个内存caching，但是你的数据模型就像一个caching，它由键值对组成。 你也可以使用Cassandra作为分布式内存caching。
Hazelcast一直是一个噩梦的规模和稳定性仍然是一个重大问题。
专用客户端到网格组件的select是
- 这个混乱的版本无法在任何地方节点丢失，否定备份（超级客户端），或者
- 一个令人难以置信的慢本地客户端选项，不允许任何types的负载平衡到网格中的处理节点。
如果任何主机可以从这个数据网格请求logging，这将是一个甜蜜的devise，但你坚持这两个平淡的select，以获得任何东西。
还有数据库线程池在单个成员上locking的多个问题，而不向数据库写入任何内容，导致永久性logging丢失是一个常见的问题，我们经常需要将整个事情放下几个小时才能刷新任何JVM。 分裂脑也仍然是一个问题，虽然在1.9.6似乎已经平静一点。
集合到Ehcache并改进数据库层，而不是将其用作创可贴。
每当有节点（标准一）时，Hazelcast就会将所有数据序列化，所以要保存到Hazelcast的数据必须实现序列化。
Hazelcast对我来说是一场噩梦。 我能够在集群Websphere环境中“工作”。 我用松散的术语“工作”。 首先，Hazelcast的所有文档都是过时的，只显示使用不推荐的方法调用的示例。 试图在Javadoc中使用没有注释的新代码，在文档中没有任何示例是非常困难的。 此外，J2EE容器代码现在根本不起作用，因为它不支持Websphere中的XA事务。 抛出一个错误，调用只显示其唯一J2EE示例的代码（看起来像Milestone 3.0正在解决这个问题）。 我不得不忘记joinHazelcast到J2EE交易。 看来Hazelcast绝对是面向非EJB /非J2EE容器环境的。 调用Hazelcast.getAllInstances（）时，如果从一个企业Java bean切换到另一个企业Java Bean，将无法保留有关Hazelcast状态的任何信息。 这迫使我创build一个新的Hazelcast实例，只是为了运行可以访问我的数据的调用。 这会导致许多Hazelcast实例在相同的JVM上启动。 另外，从Hazelcast获取数据并不快。 我尝试使用Native Client和直接作为群集成员检索数据。 我存储了51个列表，每个列表只包含625个Hazelcast对象。 我无法直接在列表上执行查询，也不想为了访问该function而存储地图（SQL操作可以在地图上执行）。 花了大约半秒钟的时间来检索625个对象的每个列表，因为Hazelcast将整个列表序列化并通过线路发送，而不是只给我三angular洲（发生了什么变化）。 另一件事，我不得不切换到TCPIPconfiguration，并明确列出我想要在群集中的服务器的IP地址。 默认的多播configuration不起作用，从谷歌的小组讨论中，其他人也遇到了这个困难。 总结一下; 我通过几个小时的程序化configuration和试验和错误（文档几乎没有什么帮助）最终得到了8台机器在集群中通信，但是当我这样做的时候，我仍然无法控制在每个集群上创build的实例和分区的数量JVM由于对于EJB / J2EE的Hazelcast的半完成性质，而且非常慢。 我在我工作的失业保险应用程序中实现了一个真正的用例，代码更快地直接调用数据库。 如果Hazelcast像广告一样工作的话，那本来是很酷的，因为我真的不想用一个单独的服务去实现我正在做的事情。 我已经广泛地使用了MongoDB，所以我可以跳过整个内存caching，只是序列化我的对象作为单独的存储库中的文档。
Ehcache的一个优势是它由一个在大型性能实验室中进行广泛的性能，故障转移和平台testing的公司（Terracotta）提供支持。 兵马俑提供支持，赔偿等。对于许多公司来说，这样的事情是重要的。
我没有使用Hazelcast，但是我听说它很容易使用，而且工作。 我还没有听说过有关Hazelcast和Terracotta / Ehcache的可扩展性或性能方面的事情，但是考虑到Terracotta的可扩展性和故障转移testing的数量，我很难想象Hazelcast在生产部署中将具有竞争力。 但我认为这对于较小的用途可以正常工作。
[偏见：我是兵马俑的前雇员]
