分佈式二級緩存與正在調優數據庫的優缺點相比有什麼優勢和缺點

Question

我們有一個使用nhibernate和二級緩存的網站。我們正在進行辯論，因爲一個人想要關閉二級緩存，因爲我們正在轉向多Web服務器環境（前面有一個負載均衡器）。

一個參數是擺脫二級緩存，並專注於優化和調整Db。另一個說法是推出分佈式緩存作爲二級緩存。

我好奇地聽到人們贊成和反對此DB的調整與分佈式緩存（保理在努力參與，成本，複雜性等）

Answer 1

在負載平衡方案的情況下，你必須使用分佈式緩存提供者獲得最佳性能和一致性，這與優化數據庫無關。在任何情況下，你應該優化你的數據庫。

Answer 2

兩個字：測量它。

由於您已經擁有緩存，因此您可以衡量將其關閉以達到基準測試的影響。

Answer 3

這是一個非常困難的話題。無論哪種情況你都需要熟練。無論是非常熟練的DBA，還是非常熟練的NHibernate/Cache管理員。

個人而言，我更喜歡完全控制我的SQL並調整數據庫。由於您只有多個Web服務器（並且不一定是多個數據庫實例），因此您可能會更好。現代數據庫具有非常高效的緩存，所以通常在應用程序中配置錯誤的二級緩存中造成更多的傷害，而不是讓數據庫緩存sql語句，遊標，數據，緩衝區等。我已經體驗到了這一點，大約有15個weblogic服務器，只有一個數據庫有很多內存。因爲你已經有NHibernate了，但是，離開它，回到SQL（也許與LINQ？）可能是一個相當昂貴的任務，這是不值得的努力。

Answer 4

兩者。您應該有一個分佈式緩存以防止對數據庫和調優數據庫的不必要的調用，以便快速返回初始調用。舉個例子，Facebook需要大量的緩存來擴展，但我相信如果最初的查詢花費了10分鐘，它就不會有太大的好處。 :)

Answer 5

我認爲多Web服務器和分佈式二級緩存可以 - 也許應該 - 共存。

首先，如果我們以memcached爲例，它支持分佈式對象存儲，所以如果你不使用它，你可以切換到那個。有用。

其次，我猜你正在引入Web服務器場來響應增加的Web請求，這反過來意味着對數據的請求增加。如果你殺了你的緩存，那麼你會用查詢來優化你的數據庫的優化程度並不重要。所以你會改善你的執行時間，但是當你等待數據庫返回你的數據時。

對於網絡節點1請求數據集A和網絡節點2請求數據集A - >您要執行相同的查詢兩次而使用二級緩存但只執行一次的情況尤其如此。

所以我的建議是：

不要殺死你的二級緩存。您已經花費了資源來實現它，通過禁用它，您不會提高應用程序的性能。即使memcached的單個節點將比沒有任何節點更快。

做優化您的數據庫操作。這意味着從數據庫端（索引，視圖，sp，函數，也許是一個只讀和只寫節點的集羣）和應用程序端（優化您的查詢，懶惰/急切的加載分析，不會獲取數據不需要，通過Future，MutliQuery，MultiCriteria將多個查詢合併爲單次往返）

執行優化您的二級緩存實施。有數據集具有無限的截止日期，因此您只能爲它們查詢數據庫一次，並且有數據集的截止日期過短，因此可能會更頻繁地執行昂貴的查詢。通過優化您的查詢和數據庫，您將提高查詢的性能，但二級緩存將保護您的皮膚處於高峯負載，其中短期過期日期數據集將將更快地被緩存提取。

如果使用文本查詢是日常操作使用數據庫的全文能力，或者甚至更好，使用像Lucene.NET一個獨立的服務（其可以與NHibernate通過NHibernate.Search集成）

Answer 6

我們使用NHibernate在我們的多服務器環境中使用Microsoft AppFabric分佈式緩存框架（NHibernate Velocity Provider）獲得巨大成功的二級緩存。

話雖如此，使用二級緩存需要更深入地瞭解框架，以防止意外的結果。另外，在使用分佈式緩存之前，測量其開銷很重要。

所以我的回答基本上是 - 在使用二級緩存之前，您應該真正測試並確定它是否真的需要。