caching - SW-Architecture - 服务层和持久层之间的缓存

Question

我正在开发一个文件系统，它使用 fusion 库和 jnr-fuse ( https://github.com/SerCeMan/jnr-fuse ) 作为 java 绑定(bind)来封装对 Amazon S3 存储桶的访问。

我有第一个版本正在运行，目前正在做一些代码清理和重构工作，试图将所有内容纳入适当的多层架构。

到目前为止，我大致有以下内容:

• 前端:这是 jnr-fuse 的 FuseFileSystem 接口(interface)的实际实现。它对 jnr( native )类型有一些依赖性，并且这些方法是 fusion 的 c 函数的 java 等效项。
• 服务层:一个接口(interface)，具有来自前端层的所有文件系统方法的“非 native 依赖”版本，但不依赖于 jnr 或 fusion。这个想法是，这也可以用在其他上下文中(例如，作为 S3 的 java.nio.FileSystem-API 实现的核心组件，或者任何其他场景，其中有人需要一个 API 来使 S3 在“文件系统”中可访问-ish”时尚但不想通过 fuse 做到这一点，因此不需要所有 jnr 依赖项)

我目前遇到的困难是持久层:由于与 S3 的所有通信实际上都是通过 http 完成的，因此我正在进行一些相当数量的缓存以减少流量并提高性能。问题是缓存最适合在哪里......

显然，实际的 DAO 不应该受到任何类型的缓存/锁定逻辑的污染 - 它们应该只处理对数据的实际访问(即对 S3 进行 http 调用)。另一方面，服务层也不应该真正关心缓存(以防持久层及其缓存需求发生变化)，因此我正在考虑执行以下操作之一:

1. 使用“双重”持久层:每个 DAO 都会实现两次:一个版本保存缓存并从缓存中提供数据。如果对象不在缓存中，我们将委托(delegate)给第二个 DAO，它实际获取该对象(然后将其添加到缓存中)
2. 引入一个单独的“缓存”层，其接口(interface)与实际持久层略有不同，用于处理所有缓存需求并根据需要委托(delegate)给持久层。

从服务层的角度来看，版本 1 是更干净的版本 - 使用缓存和不使用缓存之间没有任何区别，因为对持久层的所有调用都将针对相同的接口(interface)。另一方面，它还将有关文件状态或“生命周期”的所有逻辑(打开 -> 读/写 -> 关闭)传输到持久层。版本 2 将管理“缓存”层内文件的生命周期，我认为这将使整个代码对于刚接触代码的人来说更容易理解。另一方面，它还假设总是存在缓存层(这可能是正确的)。

从设计的角度来看，上述方法还有其他优点和缺点吗？或者是否有任何模式可以解决此类问题？

现在我宁愿选择选项 2，但听到一些意见真的很有趣。

Answer 1

您为什么反对在 DAO 中进行缓存？这一直是我缓存的完美地方。这是一个数据访问问题，因此进入数据访问层。为了方便起见，我有几次使用了各种 AOP 实现，但 90% 的时间，我在 DAO 内实现缓存逻辑。

缓存本身并不存在于 DAO 中，它通常是它自己的接口(interface)，因此我可以在实现之间进行交换(内存中、磁盘上等)。

在使用 Apache HTTP 客户端自己的内置缓存时，我也很幸运。它允许您尊重 HTTP 缓存语义，或使用自定义逻辑覆盖它。