java - 使用 EhCache、Spring 和 Hibernate 验证缓存方法

Question

我有一个实现套接字连接以读取位置数据的应用程序。每个职位都与一项 Assets 相关。该流正在实时更新数百个 Assets 的位置数据。这是 2 个域对象的基本类表示:

public class Asset{
    long id;
    Set<Position> positions;
}


public class Position{
    long id;
    Double latitude;
    Double longitude;
    Date timestamp
}

现在，我希望远程客户端可以使用最近 1 天的位置数据进行轮询。将有数百个客户对每项 Assets 的最后一天的位置数据提出轮询请求。每个 Assets 将每 5 秒更新一次位置数据。要求是客户端请求与实时更新不同步的时间不得超过 10 秒。

这给数据库带来了巨大的负载——这正是 EHCache 的用武之地——也许……

一个更好的替代方案(值得商榷!)是配置一个缓存，任何新的 Assets 和关联的位置将在它们被套接字连接读取时存储在其中。该缓存将使一天前更新的任何 Assets 过期，并负责定期(大约每分钟)将新 Assets 和头寸写入数据库。远程客户端会访问 Assets 和位置数据的缓存。

我只是想就此方法是否合理以及 EHCache 的哪些功能可以促进它提供一些想法/建议。

非常感谢

Answer 1

这可能是 EhCache 和 Hibernate 的一个很好的用例 query cache .这是基本架构。首先，为 Position 对象启用二级缓存。我认为它遗漏了代表一对多关系的 asset 字段，但这没关系。

我假设客户正在运行与此类似的查询:

SELECT p
FROM Position p
WHERE timestamp >= :timestamp
  AND asset = :assert

:timestamp 参数表示最近 24 小时(当前时间 - 24 小时)。您需要对此查询启用可缓存查询提示。

事情是这样的:客户端使用一对(asset, timestamp) 参数间接运行这个查询。 Hibernate 尝试在查询缓存中为这对(简化)构成查询缓存键的查询结果。

如果查询结果丢失，它会运行查询并将结果放入查询缓存中。 但是它只放置匹配的 Position 实例的 id，而不是实例本身。下次某个客户端请求同一对 (asset, timestamp) 时，Hibernate 将在查询缓存中查找结果。然后，只有 id，它将在二级缓存中搜索 Position 实例。

如您所见，这种情况非常复杂，有几个因素会影响整体成功:

• 有多少对不同的(asset, timestamp)？大致:

.

86400 (number of different seconds in a day) times 
  number of different assets 

键和值必须适合缓存。请记住，每个值都是 Position id 的列表。那是很多内存。您可以通过限制不同时间戳的数量来减少这种情况。最后24小时有那么重要吗？可以在 23 到 24 小时之间吗？通过这种方式，您可以舍入时间戳并减小 key 空间的大小(缓存大小)。

• 查询缓存中通过 id 引用的所有 Position 实例必须适合缓存。这可能是巨大的。但是否则你会遇到 N + 1 问题，因为在从查询缓存中获取时，在 L2 缓存中没有 Position 实体的情况下，Hibernate 将通过 id 从数据库。

• 缓存失效由 Hibernate 执行。但是请记住，每次插入 Position 表都会使查询缓存失效。在您的情况下，完全预热缓存可能永远不可能。

话虽如此，您应该尝试在 Hibernate 中查询缓存。然而，查询缓存非常棘手，需要大量调整才能正确实现。

提示:如果内存不足，请尝试将 EhCache 溢出到磁盘。从未尝试过，但我相信从本地磁盘获取序列化缓存值(尤其是使用 SSD 时)可能比缓存未命中和数据库查询快得多。