集群上的休眠 L2 缓存答案

【问题标题】：Hibernate L2 Cache on cluster集群上的休眠 L2 缓存
【发布时间】：2009-08-27 08:34:46
【问题描述】：

第一季度：我说的对吗，只有这家供应商支持集群上的 Hibernate L2 缓存？

第二季度： Hibernate L2 缓存有什么替代品吗？（也许是一些数据库缓存？）

【问题讨论】：

【解决方案1】：

第一季度。 EhCache 作为分布式的 Hibernate L2 Cache 工作得非常好。我们将其用于我们的项目。

第二季度。多个缓存是可能的。

但是，数据库的问题缓存是它在物理上数据库服务器，所以每次查询涉及网络调用（延迟，带宽..）。这就是重点应用程序上的缓存服务器。

Hibernate L2 缓存有一些细节：
- 非常易于使用（无需代码，只需少量配置）
- 在概念上在实体级别（这是非常细粒度的，我们有时需要缓存更大的粒度，以减少数据库请求），
- 按 id 或集合工作（例如，缓存查询结果默认禁用，因为在一般情况下无法使其有用）。

当 Hibernate L2 不合适时，我们使用相同的 EhCache 库来缓存数据（不完全是实体）。用例示例：
- 当一个表大（记录长度和数量）时，内存使用将不允许完全缓存它，但只缓存所有记录的三个字段是可以的。这些字段可能是经常访问的字段，或者是不可变的...
- 当我们对缓存进行多次读取访问时，每次都会根据我们拥有的实体触发一次计算（在 L2 缓存上）：计算结果可以存储在缓存中。（典型示例，计算需要来自其他表的详细信息，但最终结果中未使用这些详细信息，因此缓存不存储这些详细信息）
- 当表中的实体按类别进行逻辑分组时，我们希望一次请求和缓存一个类别，而不是一次只处理一个实体的常规 L2 缓存策略。

在分布式环境中，这通常转化为使 a 无效类别在他们之一的时候实体被修改，这在功能上对我们来说是合乎逻辑的（对于性能，否则我们会必须使所有这些无效实体；这是因为缓存使整个区域无效，或特定对象，但在之间必须循环，这对性能不利）

还有其他我确定...

所以这种情况与数据库没有密切关系，它通常不存储我们的 Hibernate 实体。我们将它放在业务层（而不是数据访问或 Daos），使其直接可用于业务代码。请注意，对我们而言，它不是透明缓存，而是对执行操作或传递值的显式业务服务的调用（负责此缓存：如果数据不存在则加载它，并根据需要使其无效）。

这个缓存中的一个有趣的线程问题：因为这个缓存被我们的一百个网络线程访问，它需要是线程安全的。您可能知道为什么线程安全值在每次调用时要么是不可变的，要么是克隆的（这通常是一个性能问题）。所以我们所有的业务缓存都使用了不可变对象，而且性能非常好。

【讨论】：

【解决方案2】：

您也可以使用[Infinispan（JBoss Cache 的演变）作为二级缓存提供者！][1]

【讨论】：

【解决方案3】：

EhCache 具有分布式模式，但我不确定 Hibernate 是否支持该模式。不过，我不明白为什么它不应该工作。

您是否出于某种特定原因省略了 JBossCache 3？

【讨论】：

【解决方案4】：

hibernate-redis lib 将是完美的选择。这是一个基于 Redis 的缓存。

为什么选择 Redis？它速度极快，可在云端运行，并拥有像 AWS Elasticache 这样的现成云解决方案，因此您无需自行管理。

【讨论】：