2016-02-07 11 views
8

Ho letto nelle FAQ di Orleans quando potrebbe accadere una split-brain ma non capisco cosa può succedere e come gestirlo correttamente.Come gestire split-brain?

FAQ dice qualcosa di vago come:

Hai solo bisogno di prendere in considerazione la rara possibilità di avere due istanze di un attore durante la scrittura la vostra applicazione.

Ma come in realtà dovrei considerare questo e cosa può accadere se non lo farò?

Orleans Paper (http://research.microsoft.com/pubs/210931/Orleans-MSR-TR-2014-41.pdf) dice:

applicazione può contare su esterni persistente storage per fornire più forte coerenza dei dati

Ma io non capisco che cosa questo significa.

Supponiamo che il cervello diviso si sia verificato. Ora ho due istanze di un grano. Quando invierò alcuni messaggi potrebbero essere ricevuti da questi due (o ci possono essere anche più?) Istanze diverse. Supponiamo che ogni istanza prima di ricevere questi messaggi abbia lo stesso stato. Ora, dopo aver elaborato questi messaggi hanno stati diversi.

Come dovrebbero persistere i loro stati? Potrebbe esserci un conflitto.

Quando altre istanze verranno distrutte e solo una rimarrà ciò che accadrà agli stati delle istanze distrutte? Sarà come se i messaggi elaborati da loro non siano mai stati elaborati? Quindi lo stato del client e lo stato del server potrebbero essere desyncronized IIUC.

Vedo questo (split-brain) come un grosso problema e non capisco perché ci sia così poca attenzione ad esso.

risposta

7

Orleans sfrutta le garanzie di coerenza del provider di archiviazione. Quando si chiama this.WriteStateAsync() da una grana, il provider di archiviazione garantisce che il grano abbia visto tutte le scritture precedenti. In caso contrario, viene generata un'eccezione. È possibile rilevare tale eccezione e chiamare DeactivateOnIdle() e ripetere l'eccezione o chiamare ReadStateAsync() e riprovare. Quindi, se hai 2 grani durante uno scenario con cervello diviso, che mai uno chiama WriteStateAsync() impedisce innanzitutto all'altro di scrivere stato senza aver prima letto lo stato più aggiornato.

Aggiornamento: a partire da Orleans v1.5.0, una grana che consente a un InconsistentStateException di essere ricondotto al chiamante verrà automaticamente disattivato al completamento delle chiamate in esecuzione. Un grano può catch e gestire l'eccezione per evitare la disattivazione automatica.

+2

È vero, che "viene generata un'eccezione e Orleans legge lo stato prima di consentire al grano di elaborare il messaggio successivo" Come vedo, InconsistentStateException non è gestito dal framework. – lmagyar

+2

@LaszloMagyar il tuo sospetto è corretto. Ho aperto https://github.com/dotnet/orleans/issues/1420 e corretto la risposta. Grazie :) –

+0

Questo non copre ancora lo scenario in cui una grana riceve messaggi di sola lettura e la seconda riceve messaggi di lettura/scrittura - la prima risponderà con dati obsoleti. –