有許多類似數據庫查詢的高速緩存管理

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（）方法來清除所有內容。如果你找到緩存密鑰管理的解決方案，我會感興趣，但我希望裝飾器模式層的方法是有幫助的。