Azure Service Fabric 中 Reliable Collection 的指導方針與建議
本節提供使用 Reliable State Manager 和 Reliable Collection 的指導方針。 目標是要協助使用者避開常見的陷阱。
可靠的集合指導方針
指導方針會編排成簡單的建議，前面再加上「請」、「請考慮」、「請避免」或「請不要」字詞。
- 請不要修改讀取作業所傳回自訂類型的物件 (例如
TryPeekAsync或TryGetValueAsync)。 可靠的集合就像並行的集合一樣，會傳回物件參考而不是複本。 - 請不要在未經修改之前，就深層複製傳回的自訂類型物件。 由於結構和內建類型都是傳值 (pass-by-value)，因此您不需要在其上執行深層複製，除非其包含您想要修改的參考類型欄位或屬性。
- 請不要針對逾時使用
TimeSpan.MaxValue。 逾時應該用來偵測死結。 - 在認可、中止或處置交易之後，請勿使用該交易。
- 請不要在其所建立的交易範圍之外使用列舉。
- 請不要在另一個交易的
using陳述式內建立交易，因為它會造成死結。 - 請勿使用建立可靠的
IReliableStateManager.GetOrAddAsync狀態，並在相同的交易中使用可靠的狀態。 這會導致 InvalidOperationException。 - 務必確保
IComparable<TKey>實作是正確的。 系統會對IComparable<TKey>採取相依性以合併檢查點與資料列。 - 請不要在讀取需更新的項目時使用更新鎖定，以避免發生特定類別的死結。
- 請考慮將每個分割區可靠的集合數目保持小於 1000。 偏好具有較多項目可靠集合，勝過於具有較少項目的可靠集合。
- 請考慮將項目 (例如「可靠的字典」的 Tkey 和 TValue) 保持低於 80 KB (越小越好)。 這會減少大型物件堆積的使用量，並降低磁碟和網路 IO 需求。 通常這會在只更新一小部分的值時，減少重複資料的複寫次數。 在「可靠的字典」中達成此目的的常用方式，是將資料列分成多個資料列。
- 請考慮使用備份和還原功能以擁有災害復原。
- 避免在同一個交易中因為不同的隔離等級混用單一實體作業和多實體作業 (例如
GetCountAsync、CreateEnumerableAsync)。 - 請務必處理 InvalidOperationException。 系統有可能因為各種原因而中止使用者交易。 例如，當 Reliable State Manager 正由「主要」角色切換，或長時間執行的交易封鎖交易記錄檔的截斷時。 在這種情況下，使用者可能會收到 InvalidOperationException，指出他們的交易已終止。 假設終止交易不是使用者所要求，處理這個例外狀況的最佳方式是處置交易，請檢查是否已通知取消權杖 (或已變更複本的角色)，如果沒有，請建立新的交易並重試。
- 請勿在交易內套用平行或並行作業。 交易內僅支援一個使用者執行緒作業。 否則，將導致記憶體流失和鎖定問題。
- 請考慮在認可完成後儘快處置交易 (尤其是在使用 ConcurrentQueue 時)。
- 請勿在交易內執行任何封鎖程式碼。
- 將字串作為可靠字典的索引鍵時，排序順序會使用預設字串比較子 CurrentCulture。 請注意，CurrentCulture 排序順序與序數字串比較子不同。
- 請勿處置或取消認可交易。 此功能不受支援，且可能會導致主機處理序損毀。
- 請務必確保讀取或寫入多個字典時，所有並行交易的作業順序都保持不變，以避免死結。
以下是要牢記在心的一些事項：
- 所有可靠的集合 API 的預設逾時都是 4 秒。 大部分使用者應該使用的預設逾時。
- 在所有可靠的集合 API 中，預設的取消權杖為
CancellationToken.None。 - 可靠字典的索引鍵類型參數 (TKey) 必須正確實作
GetHashCode()和Equals()。 索引鍵必須是不可變的。 - 若要讓可靠的集合達到高度可用性，每個服務應至少有一個目標和大小為 3 的最小複本集。
- 次要複本上的讀取作業可能會讀取未認可的仲裁版本。 這表示從單一次要複本讀取的資料版本進度可能有誤。 從主要複本讀取一定最穩定︰進度一定不會有誤。
- 應用程式保存在可靠集合中的資料會有何種安全性/隱私權將由您決定，且會受到儲存體管理的保護；也就是說，作業系統磁碟加密可用來保護待用資料。
ReliableDictionary列舉會使用依索引鍵排序的已排序資料結構。 為了使列舉更有效率，認可會新增至暫存雜湊表，之後再移至主要排序的資料結構 post 檢查點。 新增/更新/刪除具有最大的 O (1) 和最糟的1和最糟的案例執行時間 (記錄 n) ，在驗證檢查是否有索引鍵的情況下也是如此。 根據您是從最近的認可或從較舊的認可讀取，取得 (1) 或 O (記錄 n)。
變動性可靠集合的其他指導方針
當您決定要使用易發散可靠的集合時，請考慮下列事項：
ReliableDictionary有易發散支援ReliableQueue有易發散支援ReliableConcurrentQueue沒有易發散支援- 持續性服務無法設為易發散。 將
HasPersistedState旗標變更為false需要從頭重建整個服務 - 無法保存暫時性服務。 將
HasPersistedState旗標變更為true需要從頭重建整個服務 HasPersistedState是服務層級設定。這表示所有集合都將是持續性或變動性集合。 您無法混合變動性和保存的集合- 暫時性資料分割的仲裁遺失會導致資料遺失
- 備份和還原不適用於暫時性服務