Q1：我说的对吗？只有这家供应商支持集群上的 Hibernate L2 缓存吗？
- 冬眠兵马俑（商业）
- SwarmCache（自 2003 年以来未发布）
- JBoss 缓存 1.x
- JBoss 缓存 2
Q2: Hibernate L2 缓存有什么替代品吗？（也许一些数据库缓存？）
问问题
8208 次
4 回答
10
Q1。EhCache 作为分布式的 Hibernate L2 Cache 工作得非常好。我们将其用于我们的项目。
Q2。多个缓存是可能的。
- 所有的数据库已经在内部做了很多缓存，所以不用担心这部分。
但是，数据库缓存的问题在于它在物理上位于数据库服务器上，因此每个查询都涉及网络调用（延迟、带宽……）。这就是应用服务器上缓存的全部意义所在。
- Hibernate L2 缓存有一些细节：
- 非常容易使用（没有代码，很少配置）
- 概念上在实体级别（这是非常细粒度的，我们有时需要缓存更大的粒度，以减少数据库请求），
- 通过 id 或 collection 工作（例如，默认情况下禁用缓存查询结果，因为在一般情况下不可能使其有用）。
- 当 Hibernate L2 不合适时，我们使用相同的 EhCache 库来缓存数据（不完全是实体）。用例示例：
- 当一个表很大时（记录长度和数量），内存使用不允许完全缓存它，但是只缓存所有记录的三个字段是可以的。这些字段可能是经常访问的字段，或者是不可变的......
- 当我们对缓存进行多次读取访问时，并且每个都将触发计算（在 L2 缓存上）给定我们拥有的实体：计算结果可以存储在缓存中。（典型示例，计算需要来自其他表的详细信息，但最终结果中未使用这些详细信息，因此缓存不存储这些详细信息）
- 当表中的实体按类别进行逻辑分组时，我们希望一次请求和缓存一个类别，而不是一次只处理一个实体的常规 L2 缓存策略。
在分布式上下文中，这通常转化为在修改其中一个实体时使类别无效，这在功能上对我们来说是合乎逻辑的（并且对于性能至关重要，否则我们将不得不使所有这些实体无效；这是因为缓存使整个区域或特定对象无效，但在两者之间你必须循环这对性能不利）
还有其他我确定...
所以这种情况与数据库没有密切关系，它通常不存储我们的 Hibernate 实体。我们将它放在业务层（而不是数据访问或 Daos），使其直接可用于业务代码。请注意，对我们而言，它不是透明缓存，而是对执行操作或传递值的显式业务服务（负责此缓存：如果数据不存在则加载它，根据需要使其无效）的调用。
这个缓存中的一个有趣的线程问题：因为这个缓存被我们的一百个网络线程访问，它需要是线程安全的。您可能知道为什么线程安全值在每次调用时要么是不可变的，要么是克隆的（这通常是一个性能问题）。所以我们所有的业务缓存都使用了不可变对象，性能非常好。
于 2009-08-28T10:56:29.033 回答
2
您还可以使用 [Infinispan（JBoss Cache 的演变）作为二级缓存提供程序！][1]
[1]：见http://infinispan.blogspot.com/2009/10/infinispan-based-hibernate-cache.html
于 2009-10-26T16:28:40.963 回答
1
EhCache 具有分布式模式，但我不确定 Hibernate 是否支持该模式。不过，我不明白为什么它不应该工作。
您是否因为某些特定原因而忽略了 JBossCache 3？
于 2009-08-27T08:40:35.003 回答
0
hibernate-redis lib 将是完美的选择。这是一个基于 Redis 的缓存。
为什么选择 Redis？它速度极快，可在云中运行，并拥有像AWS Elasticache这样的现成云解决方案，因此您无需自己管理它。
于 2017-01-23T17:41:31.663 回答