APPFabric緩存或SQL服務器 - 特定場景

Question

我很難弄清楚APPFabric緩存或SQL Server應該在我們需要的上下文中使用（考慮到我們當前正在使用SQL服務器的事實）。

我們只需要（現在）緩存與其中一個應用服務器（外發請求）發送的特定請求相關的信息對應的每個小塊數據（〜16KB）。

任何應用服務器都可以接收與初始傳出請求相關的傳入請求，並且對於我們的需要，我們需要找回與此傳出請求關聯的原始信息...因此，我們無法保留本地內存緩存在每個應用服務器中，因爲我們無法確定傳入的請求是否會到達發送傳出請求的應用服務器。儘管我們基本上只需要堅持16kb的信息一次（很少有更新的可能性），並且能夠從任何應用服務器訪問它，但只能在廣闊的區域訪問它一次大部分情況。 因此，基本上大部分時間都是從應用服務器（緩存）寫入，之後從相同或另一個應用服務器讀取。

在這個特定的上下文中，是否有任何獲得通過AppFabric緩存集羣而不是直接進入數據庫（考慮到它將是一個簡單的插入/選擇語句）？

記住可擴展性，這意味着我們目前沒有put_data/get_data操作的高吞吐量（~160ops/sec），但我們可能會達到1K/s .. 10k/s，並且在不久的將來可能會更多。

在此先感謝您的答案。

Answer 1

與SQL DB相比AppFabric Cache的收益將是訪問時間。由於AppFabric將所有內容存儲在內存中（RAM），因此您需要更快地訪問AppFabric，而SQL需要從磁盤查詢其數據。

AppFabric Cache的缺點是，除非您在羣集中實施HA（高可用性），否則系統出現故障時可能會丟失數據，否則可能會丟失數據。 SQL DB在這裏獲勝是因爲它支持數據可恢復性（通過備份日誌 - LDF），如果數據庫系統發生故障。

如果您需要有保證的消息傳遞，由於其強大的數據恢復支持，您可能不應該使用AppFabric緩存集羣，而是使用SQL DB進行臨時持久化。