Question

我们有一个系统（Java Web应用程序），现在已经进行了很长时间的开发/维护（大约十年）。

我们正在做的是为Web应用程序实现RESTful API。这个使用Jersey的Web应用程序将是一个单独的项目，其目的应该是能够与主应用程序一起运行或部署在云中。

由于我们的应用程序的性质和年龄，我们必须在数据库（postgres）之上实现一个（有些）全面的缓存层，以帮助保持负载。无论如何，对于RESTful API，我们的想法是GET请求将首先进入缓存而不是数据库以保持数据库的负载。

将以一种方式填充缓存，以帮助确保注册的API用户所需的大多数东西都应该在那里。

如果存在高速缓存未命中，则应从数据库中检索所需的数据（也将在此过程中输入到高速缓存中）。

显然，我的代码中的RESTful端点方法应保持透明。我们想出了创建一个'Broker'来处理与DB和缓存的通信的想法。 REST层将简单地传递id（如果要查找）或填充的Java对象（如果要插入/更新），并且代理将负责检索/更新/无效等。

还存在可扩展性问题。首先，API将与其他服务器一起生存，因此访问数据库不会成为问题，但是如果我们部署到云，我们将需要一个与系统通信的不同Broker实现（即数据库）以不同的方式（可能通过使用内部API）。

我已经对如何实现这一点有了一个大致的想法，但令我印象深刻的是可能存在合适模式的问题。如果我能够遵循既定模式而不是提出我自己的解决方案，那么这可能是更好的选择。有什么想法吗？

Answer 1

Ehcache实现了这样一个缓存，它调用SelfPopulatingCache。

请求缓存，而不是数据库。然后，如果有缓存未命中，Ehcache将代表您调用数据库（或您拥有的任何外部数据源）。

您只需要实现一个CacheEntryFactory，它只有一个方法：

Object createEntry(Object key) throws Exception;

顾名思义，Ehcache使用非常标准的工厂模式实现了这个概念......

Answer 2

没有模式。只需隐藏接口后面的初始数据库服务，围绕其预期行为构建测试，然后切换使用缓存层的实现。我想依赖注入是帮助你做到这一点最好的事情吗？

Answer 3

听起来像装饰模式将满足您的需求：http://en.wikipedia.org/wiki/Decorator_pattern。

您可以为数据访问创建DAO界面，例如：

Value get(long id);

首先创建一个直接的数据库实现，然后创建一个调用底层DAO实例的Cache实现，在这种情况下它应该是数据库实现。

缓存实现将尝试从其自己的托管缓存中获取值，如果失败则从{@ 1}}下载。

因此，您的旧应用程序或REST都只会看到DAO接口，而不知道任何实现细节，将来您可以自由更改实现。

Answer 4

透明缓存HTTP请求的最佳设计模式是使用an HTTP cache。