我的系統使用一堆微服務來處理一個項目，並且我計劃創建一個有狀態的MicroService來保存該項目的最新狀態。在該服務中，我打算將所有項目狀態存儲在可靠的字典中，並且每當訪問項目時都會更新項目的最後訪問字段。可靠集合緩存作爲服務結構中的緩存
我的要求是，我只想將最近使用的項目存儲在可靠的集合中，並且需要將不能長時間訪問的項目移動到外部存儲，如天藍色表格存儲， 以及外部存儲和可靠的採集需要同步。
含義所有項目應在外部存儲和最近使用的項目在可靠的集合。
這是爲了減少可靠收集的開銷。
像可靠的收集行爲作爲緩存。
如上所述，實施我的解決方案是否是最佳實踐？ 枚舉ReliableCollection是否是一個好習慣？
如果可靠字典是爲了充當緩存，那麼我真的沒有看到將未使用的項目卸載到Azure存儲的重點。如果它是一個緩存，我希望清除未使用的項目，並且調用者需要返回真實的來源以查找從緩存中過期的任何內容。但是這聽起來像你希望Reliable Dictionary成爲最新的真相源。所以我認爲你必須首先決定是否實際構建了一個緩存，或者是真實數據存儲的來源，這個數據存儲可以將內存中的數據分頁。聽起來更像後者。
無論是哪種情況，都可以按照您所描述的方式完成，但始終保持同步並不會很容易，因爲您沒有跨Reliable Dictionary和外部存儲進行事務處理。
枚舉集合是好的，但它是一個昂貴的操作，所以我不建議在熱路徑中的大量數據上執行它，例如用戶請求路徑。可以按照計劃的方式定期進行。
您是否需要將數據卸載到外部存儲？你可以卸載到本地磁盤？ Reliable Collections很快會自動將狀態卸載到磁盤。
我會用演員。給每個項目分配自己的演員並在那裏存儲狀態。當演員被垃圾收集後，你可以將狀態保存在別的地方，或者乾脆在演員定時器上做。
這樣做意味着您不必複製大量的actor代碼來管理大量實例。
CAVEAT
這是有道理的，如果你的整體設計是否合理。正如瓦茨拉夫在下面的評論所說的，由於演員的單線程模型，演員對通用緩存不太好。但是如果你的設計有一個代表單個實體的actor，並且緩存與該實體（比如用戶）有關，那麼把這個actor當作緩存就可以很好地工作。
參與者通常不是高速緩存的好主意，因爲每個參與者實例都強制執行單線程訪問。這意味着多個閱讀器不能同時訪問相同的數據，導致吞吐量不佳。 –
偉大的一點！我想這是關於緩存的用戶是否分區與演員分區相同的方式。 –
是的，它可以在沒有併發讀取的特殊情況下工作，就像每個actor實例表示一個用戶，其中客戶端和actor實例映射到1：1一樣。但作爲通用緩存，這不是一個好主意。 –
我只需要從Reliable集合中卸載數據。如果卸載到本地磁盤可用，這將是很好的....謝謝。 –
它正在進行中。在最新版本（5.1）中，數據總是在內存和磁盤上。在未來的發行版中，只有熱數據纔會在內存中，所有數據仍將保留在磁盤上。 –
我很期待 - 有沒有辦法看到內存中有多少？ –