有许多类似数据库查询的高速缓存管理

Question

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

与许多服务器应用程序一样，我们有数据层的概念。这个数据层有许多不同的方法返回域模型对象。例如，我们已经用类似方法雇员数据访问对象：

• findEmployeesForAccount（长的accountId）
• findEmployeesWorkingInDepartment（长帐户ID，长DepartmentID的）
• findEmployeesBySearch（长帐户ID，字符串搜索）

每种方法查询数据库并返回Employee域对象列表。

显然，我们想尽可能地尝试缓存来限制查询数据库的次数，但是我们将如何去做呢？

我看到一对夫妇可能的解决方案：

1）我们为每一个方法调用的缓存。例如。对于findEmployeesForAccount，我们将添加一个具有关键account-employees-accountId的条目。对于findEmployeesWorkingInDepartment，我们可以添加一个关键字department-employees-accountId-departmentId等等。我看到的问题是，当我们向系统中添加新员工时，我们需要确保将其添加到每个适当的列表中，这似乎很难维护并且易于出错。

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

我是新来的缓存，所以我想知道人们用什么策略来处理这种情况？任何建议和/或资源在这种类型的东西将不胜感激。

Answer 1

我一直在努力解决同一个问题，现在几个星期了......所以最好这是一个半答案。对我来说，一直很好的建议是使用装饰模式来实现缓存层。例如，下面是一篇文章在C＃中详述此：

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

这可以让你从字面上“包装”现有的数据访问方法不碰他们。它还使得在运行时很容易地将DAL的缓存版本替换为直接访问版本（这对于单元测试可能很有用）。

我仍在努力管理我的缓存键，当涉及大量参数时，缓存键看起来无法控制。不可避免的是，某些事情最终没有从缓存中正确地清除，我不得不采取强硬的ClearAll（）方法来清除所有内容。如果你找到缓存密钥管理的解决方案，我会感兴趣，但我希望装饰器模式层的方法是有帮助的。