2011-10-26 74 views
1

本地緩存我有兩個單獨的Web應用程序:同步與外部應用

  1. 其中創建數據和更新
  2. 其中顯示數據的「公共」應用程序「管理」應用程序。

顯示在「公共」上的信息很少變化,所以我想緩存它。

我正在尋找的是在管理站點中進行更改時更新公共站點上緩存的「最簡單可能的事情」。

爲了避免一些複雜性,應用程序在Windows Azure上運行。這排除了文件和sql緩存依賴關係(至少是內置的)。

我正在一個Web角色實例上運行這兩個應用程序。

我曾考慮過爲此使用Memcached。但由於我並不是真的在分佈式緩存之後,並且性能不如使用內存緩存(System.Runtime.Caching),所以我想盡量避免這種情況。我也考慮過使用NServiceBus(或Azure等價物),但再次,這似乎矯枉過正只是發送一個通知來清除緩存。

我在想什麼(也許有點哈克,但簡單):

  1. 有清除內存高速緩存中的公共網站上的控制器動作。我對清除特定的緩存項目沒什麼困擾,數據沒有變化足夠讓我擔心這一點。當「管理」應用程序創建緩存時,我們會在公共站點的清除緩存操作中創建一個httpwebrequest。
  2. 由於數據庫是兩個應用程序之間唯一的共享資源,只需添加一個包含上次更新日期時間的表。公共站點將對每個請求進行查詢,並將數據庫的上次更新日期時間與我們將在內存中保留的日期時間進行比較。如果它不匹配,那麼我們清除緩存。

上述選項的其他建議或問題?這裏關鍵的是簡單和高性能。

+0

一般來說,我們使用redis來處理這種東西,它也爲我們提供了一條消息總線。在一個地方我使用了數據庫輪詢。 –

回答

1

1.,如果您有多個實例,則您有一個控制器操作來清除緩存,但不起作用;否則,如果你知道你有一個且只有一個實例,它應該工作得很好。

2.如果您有一個存儲最後一次更新時間的表,對於多個實例可以正常工作,但每次請求會產生SQL數據庫查詢的成本 - 對於重負載的網站,這可能是一個問題。

可能最快也最簡單的是使用選項2,但將最後一次更新時間存儲在表存儲中而不是SQL數據庫中。讀取表格存儲是很快快 - 它是一個簡單的HTTP GET。

+0

是的,我們將只有一個實例開始 - 我意識到選項1不會工作,當我們添加更多。 +1提示Azure表存儲,我沒有想到這一點。 –

+0

增加對那些陳舊的數據是否正確以及哪裏需要最新數據的想法。然後可以在不需要保持數據當前的數據集上使用高速緩存失效和重新加載。 – Chandermani

1

只要您只有一個主站點實例,就可以調用一個公共控制器來告訴站點清除其緩存。一旦添加第二個實例,當呼叫通過負載均衡器時,您的一個呼叫將只會轉到一個實例。

如果你不關心更新如何儘快使其從管理網站的主要場所,表現最好的和最簡單的(但不是最便宜)的解決辦法是用短期使用Azure AppFabric Cache然後configure it to use a a local (in memory) cache ish超時(比如10分鐘)。

第一次客戶端嘗試訪問,這將是怎樣發生在本地緩存

    1. 查找的項目它不存在的項目,所以在分佈式緩存查找項目
    2. 它不存在這樣或者從持久性存儲
    3. 加載項的項添加到緩存中長上下的生存時間(48小時我覺得默認的)
    4. 回報的項目

    步驟1和步驟2由圖書館負責照顧,其他位則需要編寫。在接下來的X分鐘內任何後續調用都會從內存緩存中返回該項目。經過X分鐘後,它不在本地緩存中。下一次調用將它從分佈式緩存加載回本地緩存,然後繼續。

    您的所有管理應用程序需要執行的操作是更新數據庫,然後從分佈式緩存中刪除項目。下次該項目從客戶端的本地緩存中退出時,它將僅從數據庫重新加載數據。

    如果你喜歡這個想法,但不想花費使用緩存服務,你可以做一些與你的數據庫想法非常相似的東西。將緩存的數據保存在一個靜態變量中,只需每x分鐘檢查一次更新,而不是每次請求。

  • +0

    感謝您的建議。說實話,如果我放棄分佈式緩存路由,我可能會使用Memcached,因爲我不喜歡在不必付錢的情況下支付更多費用的想法。關於何時檢查變量的好建議,我可以通過爲(本地)緩存項目聲明一個回調來很好地做到這一點。 –

    0

    最後,我使用Azure Blob作爲緩存依賴項。我創建了一個文件更改監視器來輪詢對這些文件所做的更改(詳細信息請參見http://ben.onfabrik.com/posts/monitoring-files-in-azure-blob-storage)。

    當在管理應用程序中進行更改時,我更新blob。當文件更改監視器檢測到更改時,我們清除本地緩存。