好吧我有點不確定如何最好地命名這個問題:)但假設這個情況,你 出去,並提取一些網頁(與各種網址),並在本地緩存。即使使用多線程,緩存部分也很容易解決。併發緩存共享的模式
但是,想象一個線程開始提取一個url,幾毫秒後又想獲得相同的url。有沒有什麼好的模式讓第二個線程的方法等待第一個方法獲取頁面,將它插入到緩存中並返回,以便不必執行多個請求。即使對於需要大約300-700毫秒的請求,開銷也不夠大,值得做。而如果沒有經過對方鎖定爲其他URL
基本上請求時,對於相同的URL的請求進來緊密我想第二個請求,以「搭便車」的第一個請求
我有一本字典,你的一些鬆散的想法當您開始獲取頁面並鎖定頁面時,插入一個帶有密鑰的對象作爲url。如果已經有任何匹配的鍵,它將獲得該對象,鎖定該對象,然後嘗試獲取實際緩存的url。
我有點不確定的詳情然而,使其真正線程安全的,使用ConcurrentDictionary可能是它的一個組成部分......
是否有這樣的情況下任何共同的模式和解決方案?
擊穿錯誤的行爲:
線程1:檢查高速緩存,它不存在,所以開始取的URL
線程2:開始取相同的URL,因爲它仍然在緩存
不存在線程1:完成的,並插入到緩存中,返回頁
線程2:表面處理,並且還插入到高速緩衝存儲器(或丟棄),返回頁
擊穿正確的行爲:
線程1:檢查高速緩存,它不存在這樣開始取的URL
線程2:想相同的URL,但看到它目前正在取出等線程1
等待線程1:成品,並插入到緩存中,返回頁面
線程2:注意到線程1結束,返回頁主題1它取
編輯
大多數解決方案中辛勤似乎誤解了問題,只有解決了高速緩存,因爲我說的是心不是問題,問題做一個外部網絡時,取使第二取是前首先完成一個緩存了它使用第一個的結果而不是第二個
我的回答*確實*解決您在編輯中提出的問題。 – LukeH 2010-12-09 09:59:32
@Luke,你目前的解決方案似乎確實是我正在尋找的,謝謝!我將等待幾個小時的任何替代解決方案,然後我將結束這個問題 – Homde 2010-12-09 11:10:47
您是否考慮過一種解決方案,您將使用某種同步字典(例如ConcurrentDictionary),並將url作爲關鍵字,以及類似IAsyncResult的內容值?如果線程2嘗試獲取線程1當前正在下載的頁面,則只需等待IAsyncResult,直到它完成並獲取頁面內容(IAsyncResult可能不是正確的選擇,但是您可以獲得理念...)。 – Mike 2010-12-11 01:36:30