当 Terracotta 服务器用作 Hibernate 的 EHCache 后端时，它会做什么？
我的 DAL 是使用 Hibernate 实现的，我想使用 EHCache 作为其二级缓存及其分布式功能（用于可扩展性和 HA）。
鉴于 EHCache 仅通过 Terracotta 提供分布式缓存，我的问题是 Terracotta 服务器实例的作用是什么？它也保存数据吗？它是否只协调分区缓存部分之间的分配？
我的困惑主要来自这个关于 TSA 的解释，其中说服务器保存数据，但我认为在我的场景中，缓存和 Terracotta 服务器可能是合并的。我说得对吗？
如果服务器确实保存数据，那么为什么瓶颈不应该从数据库转移到 Terracotta 服务器呢？
更新： Affe 的回答回答了我问题的第二部分，这是重要的部分，但以防万一有人来寻找第一部分，我会说 TC 服务器必须保存内存中 EHCache 保存的所有数据，所以如果你想要一个分布式缓存（不复制），那么 L2（TC 服务器）本身也必须保存所有对象。
预先感谢，
一泰
My DAL is implemented with Hibernate and I want to use EHCache as its second level cache with its distributed capabilities (for scalability and HA).
Seeing as EHCache provides distributed caching only with Terracotta my question is what is the role of the Terracotta server instance? Does it also hold data? Does it only coordinate the distribution between the partitioned cache parts?
My confusion derives mainly from this explanation regarding TSA which says the server holds the data but I think that maybe in my scenario the cache and the Terracotta server are sort of merged. Am I correct?
If the server does hold data then why shouldn't the bottleneck just move from the db to the Terracotta server?
Update:
Affe's answer answered the second part of my question which was the important part but just in case someone comes by looking for the first part I'll say that the TC server has to hold all the data that the EHCache in memory holds and so if you want a distributed cache (not replicated) then the L2 (TC server) must hold all the objects itself as well.
Thanks in advance,
Ittai
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这个想法是，通过 terracotta 驱动程序联系 terracotta 集群并执行基本的 Map 查找操作，仍然比获取数据库连接和执行 SQL 语句要快得多。即使这确实成为应用程序的瓶颈，总体吞吐量预计仍显着高于 JDBC 连接 + SQL 瓶颈。打开连接和打开游标是数据库中的大量资源消耗，而 terracotta 集群的打开套接字则不然！
The idea is it's still significantly faster to contact the terracotta cluster via the terracotta driver and do what's basically a Map lookup, than to acquire a database connection and execute an SQL statement. Even if that does become the application's choke point, overall throughput would be expected to still be significantly higher than a JDBC Connection + SQL choke point. Open connections and open cursors are big resource hogs in the database, an open socket to the terracotta cluster is not!
您可以在不使用 terracotta 的情况下获得 ehcache 集群。他们有通过 RMI、JGroups 和 JMS 执行此操作的文档。我们正在使用 JMS，因为我们已经拥有重要的 JMS 基础设施来处理通信。我不知道从长远来看它的扩展效果如何，但我们目前关心的只是 HA。
You can get ehcache clustered without using terracotta. They have documentation for doing it via RMI, JGroups and JMS. We are using JMS since we have a significant JMS infrastructure to handle the communication already. I don't know how well it will scale in the long term, but our current concern is just HA.