爲了性能的原因，我必須在內存中緩存一個對象層次結構，這反映了一個帶有列（ObjectID，ParentObjectID，Timestamp）和查看CurrentObjectHierarchy的簡單數據庫表。我查詢CurrentObjectHierarchy並使用散列表來緩存每個對象的當前父對象，以便在給定任何對象ID的情況下快速查找父對象ID。查詢數據庫表並構建緩存平均爲77ms操作，理想情況下，只有調用數據庫API中的方法纔會更改層次結構（添加/刪除/重新設置對象）時，纔會發生刷新。ASP.NET Web服務器中數據庫支持的內存駐留全局緩存的最佳位置是什麼？
如果這樣的緩存最好的地方在於它必須被多個ASP.NET Web應用程序訪問，可能運行在不同的應用程序池中，
最初，我將緩存存儲在由不同web應用程序共享的C＃dll中的靜態變量中。當然，問題是雖然可以跨線程訪問靜態變量，但不能跨進程訪問靜態變量，當涉及多個Web應用程序（可能運行在單獨的應用程序池中）時，這是一個問題。因此...同步，一個應用程序中的對象層次結構高速緩存的線程安全修改不反映在其他應用程序中，即使它們使用相同的代碼庫。
所以我需要一個更加全球化的位置來存放這個緩存。我不能使用靜態變量（正如我剛剛解釋的），會話狀態（基本上是每個用戶的存儲）和應用程序狀態（需要跨應用程序訪問）。
我一直在考慮可能的地方是：
- 某種類型的IIS本身全局對象存儲的，在任何應用程序池中的任何應用程序從任何線程訪問（如果這樣一個地方存在，是嗎？ ）
- 管理獨佔緩存的單獨自定義Web服務。
眼下，我認爲最好的解決辦法是SQL CLR集成，因爲：
- 我可以使用靜態變量保持我目前的設計
- 這是一個已經存在一個單獨的服務，因此我不必編寫自定義的一個
- 它將在單個進程（SQL Server）中運行，因此現有的基於鎖的同步將正常工作
- 緩存將盡可能接近它所代表的數據結構！
我會在SQL CLR DLL中嵌入層次遍歷方法，這樣我就可以進行單個SQL調用，我通常會進行常規方法調用。這一切都取決於在單個進程中運行的SQL Server，並且將CLR加載到該進程中，我認爲是這種情況。你覺得這怎麼樣？你可以看到這個想法有什麼明顯錯誤，我可能會失蹤？這不是一個好主意嗎？
編輯： 仔細看後，似乎不同的ASP.NET應用程序實際上運行在同一個進程中，但被AppDomain隔離。如果我能找到一種方法來跨AppDomain共享和同步數據，那將非常有用。我正在閱讀關於.NET Remoting。
在每臺機器上都有緩存存在問題，我認爲這是最簡單的方法嗎？ – orjan
只有一臺機器...它就是我在哪裏放置緩存在機器上，這樣就有一個緩存實例（快速/輕鬆/同步）可供任何Web應用程序訪問。我真的很喜歡把它放在SQL Server內部的想法，因爲那樣，無論何時直接修改表（即在SS Management Studio中，而不是通過調用數據庫API中的方法），都可以觸發緩存的同步刷新。 – Triynko
有一些分佈式緩存框架在那裏，你可能想給他們一個秒殺： http://stackoverflow.com/search?q=cache 我還沒有嘗試過任何一個，所以我沒有更多有關該主題的信息。 – orjan