Linee guida e consigli per Reliable Collections in Azure Service Fabric

  • Articolo

Questa sezione fornisce le linee guida per l'uso di Reliable State Manager e Reliable Collections. L'obiettivo è quello di aiutare gli utenti a evitare errori comuni.

Linee guida per le raccolte affidabili

Le linee guida sono organizzate come semplici consiglisu cosa fare , prendere in considerazione , evitare enon fare.

  • Non modificare un oggetto di tipo personalizzato restituito dalle operazioni di lettura, ad esempio TryPeekAsync o TryGetValueAsync. Le raccolte Reliable Collections, così come le raccolte Concurrent Collections, restituiscono un riferimento agli oggetti, non una copia.
  • Eseguire una copia completa dell'oggetto di tipo personalizzato restituito prima di modificarlo. Poiché gli struct e i tipi predefiniti vengono passati per valore, non è necessario eseguirne una copia completa, a meno che non contengano campi di tipo Reference o proprietà che si intende modificare.
  • Non usare TimeSpan.MaxValue per i timeout. I timeout devono essere usati per rilevare i deadlock.
  • Non usare una transazione dopo che ne è stato eseguito il commit, è stata interrotta o eliminata.
  • Non usare un'enumerazione all'esterno dell'ambito di transazione nella quale è stata creata.
  • Non creare una transazione all'interno dell'istruzione using di un'altra transazione. Questa operazione può causare deadlock.
  • Non creare uno stato affidabile con IReliableStateManager.GetOrAddAsync e usare lo stato affidabile nella stessa transazione. Ciò comporta un'eccezione InvalidOperationException.
  • Verificare che l'implementazione di IComparable<TKey> sia corretta. Il sistema presenta dipendenze su IComparable<TKey> per l'unione di checkpoint e righe.
  • Usare il blocco di aggiornamento durante la lettura di un elemento con l'intenzione di aggiornarlo in modo da evitare una determinata classe di deadlock.
  • Si consiglia di mantenere un numero di raccolte Reliable Collections per partizione inferiore a 1000. Preferire le raccolte Reliable Collections con più elementi.
  • Prendere in considerazione l'opportunità di mantenere gli elementi (ad esempio TKey + TValue per Reliable Dictionary) sotto gli 80 Kbyte: più sono piccoli, meglio è. In questo modo, è possibile ridurre l'uso di heap di oggetti di grandi dimensioni, oltre che i requisiti di dischi e I/O di rete. Spesso si riduce anche la replica dei dati duplicati quando viene aggiornata solo una piccola parte del valore. Un modo comune per ottenere questo in Reliable Dictionary è interrompere le righe in più righe.
  • Prendere in considerazione l'uso della funzionalità di backup e ripristino per il ripristino di emergenza.
  • Evitare di combinare nella stessa transazione le operazioni a singola entità e a più entità, ad esempio GetCountAsync, CreateEnumerableAsync, a causa dei diversi livelli di isolamento.
  • Gestire InvalidOperationException. Le transazioni utente possono essere interrotte dal sistema per diversi motivi. Ad esempio, quando cambia il Gestore dello stato affidabile cambia il proprio ruolo da ruolo primario o quando una transazione a esecuzione prolungata blocca il troncamento del log delle transazioni. In questi casi, l'utente può ricevere un evento InvalidOperationException, che indica che la transazione è già stata terminata. Supponendo che l'interruzione della transazione non è stata richiesta dall'utente, il modo migliore per gestire questa eccezione è di eliminare la transazione, verificare se il token di annullamento è stato segnalato (o se il ruolo della replica è stato modificato) e in caso contrario creare una nuova transazione e riprovare.
  • Non applicare operazioni parallele o simultanee all'interno di una transazione. All'interno di una transazione è supportata una sola operazione di thread utente. In caso contrario, si verificheranno problemi di perdita di memoria e blocco.
  • Prendere in considerazione l'eliminazione della transazione il prima possibile dopo il completamento del commit (soprattutto se si usa ConcurrentQueue).
  • Non eseguire un codice di blocco all'interno di una transazione.
  • Quando stringa viene usata come chiave per un dizionario affidabile, l'ordinamento usa operatore di confronto di stringhe CurrentCulture predefinito. Si noti che l'ordinamento CurrentCulture è diverso da operatore di confronto di stringhe ordinali.
  • Non eliminare o annullare una transazione di commit. Questa operazione non è supportata e potrebbe arrestare in modo anomalo il processo host.
  • Assicurarsi che l'ordine dell'operazione di dizionari diversi rimanga invariato per tutte le transazioni simultanee durante la lettura o la scrittura di più dizionari per evitare deadlock.

Occorre tenere presente i concetti seguenti:

  • Il timeout predefinito di tutte le API delle raccolte affidabili è di 4 secondi. La maggior parte degli utenti deve usare il timeout predefinito.
  • Il token di annullamento predefinito è CancellationToken.None in tutte le API di Reliable Collections.
  • Il parametro di tipo di chiave (TKey) per un oggetto ReliableDictionary deve implementare correttamente GetHashCode() e Equals(). Le chiavi non devono essere modificabili.
  • Per ottenere una disponibilità elevata per le raccolte Reliable Collections, ogni servizio deve avere almeno un set di repliche di destinazione costituito da un minimo di 3 repliche.
  • Le operazioni di lettura sul secondario possono leggere le versioni che non sono vincolate a un quorum. Ciò significa che una versione dei dati che viene letta da un singolo secondario potrebbe essere elaborata in modo non corretto. Le letture della replica primaria sono sempre stabili: non sono mai elaborate in modo non corretto.
  • La sicurezza e la privacy dei dati resi persistenti tramite l'applicazione in una raccolta affidabile sono decisioni dell'utente e sono soggette a misure di protezione fornite dalla gestione dell'archiviazione, ad esempio la crittografia del disco del sistema operativo potrebbe essere usata per proteggere i dati inattivi.
  • L'enumerazione ReliableDictionary usa una struttura di dati ordinata in base alla chiave. Per rendere efficiente l'enumerazione, i commit vengono aggiunti a una tabella hash temporanea e successivamente spostati nella struttura dei dati ordinata principale dopo il checkpoint. Aggiunte/aggiornamenti/eliminazioni hanno il runtime dei casi migliore di O(1) e il runtime peggiore di O(log n), nel caso di controlli di convalida sulla presenza della chiave. Get può essere O(1) o O(log n) a seconda che si stia leggendo da un commit recente o da un commit precedente.

Linee guida aggiuntive per le raccolte affidabili volatili

Quando si decide di usare raccolte affidabili volatili, tenere presente quanto segue:

  • ReliableDictionary dispone di supporto volatile
  • ReliableQueue dispone di supporto volatile
  • ReliableConcurrentQueue NON dispone di supporto volatile
  • I servizi persistenti NON POSSONO essere resi volatili. La modifica del flag HasPersistedState in false richiede la nuova creazione dell'intero servizio da zero
  • I servizi volatili NON POSSONO essere resi persistenti. La modifica del flag HasPersistedState in true richiede la nuova creazione dell'intero servizio da zero
  • HasPersistedState è una configurazione a livello di servizio. Ciò significa che TUTTE le raccolte verranno rese persistenti o volatili. Non è possibile combinare raccolte volatili e persistenti
  • La perdita del quorum di una partizione volatile comporta una perdita di dati completa
  • Le funzionalità di backup e ripristino NON sono disponibili per i servizi volatili

Passaggi successivi