gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-02 04:11:28 26 4
gpt4 key购买 nike

我正在开发一个文件系统,它使用 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,但听到一些意见真的很有趣。

最佳答案

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

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

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

关于caching - SW-Architecture - 服务层和持久层之间的缓存,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36529803/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com