具有大量类似数据库查询的缓存管理

Question

我正在尝试将缓存引入现有的服务器应用程序，因为数据库开始变得过载。

与许多服务器应用程序一样，我们拥有数据层的概念。此数据层具有许多返回域模型对象的不同方法。例如，我们有一个员工数据访问对象，其方法如下：

• findEmployeesForAccount（long accountId）
• findEmployeesWorkingInDepartment（long accountId，long departmentId）
• findEmployeesBySearch（long accountId，String search）

每个方法都会查询数据库并返回一个Employee域对象列表。

显然，我们希望尝试尽可能多地缓存以限制访问数据库的查询数量，但我们将如何去做呢？

我看到了几种可能的解决方案：

1）我们为每个方法调用创建一个缓存。例如。对于findEmployeesForAccount，我们将添加一个带有密钥account-employees-accountId的条目。对于findEmployeesWorkingInDepartment，我们可以添加一个带有关键部门 - employees-accounts-accountId-departmentId的条目，依此类推。我看到的问题是当我们将新员工添加到系统中时，我们需要确保将其添加到适当的每个列表中，这似乎很难维护并且容易出错。

2）我们为findEmployeesForAccount创建了一个更通用的查询（包含更多的连接和/或查询，因为需要更多信息）。对于其他方法，我们使用findEmployeesForAccount并从列表中删除不符合指定条件的条目。

我刚接触缓存，所以我想知道人们用什么策略来处理这样的情况？任何关于此类东西的建议和/或资源都将不胜感激。

Answer 1

我几个星期以来一直在努力解决同样的问题......所以最好考虑这个半答案。对我来说很好的一点建议就是使用Decorator Pattern来实现缓存层。例如，这是一篇在C＃中详细说明的文章：

http://stevesmithblog.com/blog/building-a-cachedrepository-via-strategy-pattern/

这使您可以直接“包装”现有的数据访问方法，而无需触及它们。它还可以非常轻松地在运行时轻松地将DAL的缓存版本替换为直接访问版本（这对于单元测试非常有用）。

我仍然在努力管理我的缓存键，当涉及众多参数时，缓存键似乎失控。不可避免地，某些东西最终没有从缓存中正确清除，我不得不采用严厉的ClearAll（）方法来消除一切。如果您找到缓存密钥管理的解决方案，我会感兴趣，但我希望装饰器模式层方法很有用。