Perché Akka è buono per la concorrenza?

Uno dei vantaggi dei modelli di elaborazione dei messaggi come attori e agenti è che i tradizionali problemi di concorrenza (principalmente la sincronizzazione dello stato condiviso) non sono più un problema. L'attore può mantenere uno stato privato e aggiornarlo liberamente senza blocchi. Il framework dell'attore garantisce che venga elaborato un solo messaggio alla volta. Con l'elaborazione serializzata, il codice può essere scritto in modalità lock-free.

Nel tuo esempio di utenti che salvano un modulo, supponendo che l'attore stia mantenendo un elenco di alcuni dati da ciascun modulo, l'attore può aggiornare l'elenco senza blocchi, poiché la struttura garantisce che solo un modulo verrà elaborato alla volta. Tradizionalmente, dovresti bloccare gli accessi alla lista o utilizzare un elenco simultaneo.

La strategia della concorrenza è leggermente diversa ed è ancora sotto la tua responsabilità (senza strategia che sia la strategia più comune). Per cambiare leggermente il tuo esempio, supponiamo che entrambi gli utenti tentino di aggiornare l'istanza del modulo SAME allo stesso tempo. Senza una strategia di concorrenza, le proprie modifiche sovrascriveranno l'altra (probabilmente l'ultima vince). Va bene, ma nella migliore delle ipotesi ciò comporta un comportamento imprevisto per l'utente le cui modifiche sono state sovrascritte. Se visualizzano il modulo appena modificato, avranno valori inattesi (dall'altro utente). Nel peggiore dei casi (quando non stiamo parlando solo di aggiornamenti dei moduli, ma di cose come ordini di spedizione) ciò potrebbe comportare perdite di vario tipo (tempo, entrate, ecc.).

L'utilizzo di una strategia di concorrenza aiuta a identificare questi casi ed è in grado di risolverli in base alle regole aziendali. Ad esempio, Optimistic Concurrency ha l'utente di inviare la versione del modulo che sta aggiornando. Quando l'attore va a elaborare la modifica, nota che il secondo utente pensa di aggiornare la Versione 5 quando il modulo è in realtà nella Versione 6 a causa dell'aggiornamento del primo utente. Ora almeno possiamo comunicare al 2 ° utente che il modulo è già cambiato da quando hanno iniziato a modificarlo. O quali sono le regole che l'azienda vuole imporre qui.

Nel caso di aggiornamento di un modulo, probabilmente non ti interessa tanto sulla concorrenza (dipende, suppongo). Ma in altri casi, potrebbe essere una cosa molto importante essere almeno in grado di controllare e gestire le violazioni. Potresti anche voler ignorare la violazione della concorrenza, come se gli utenti avessero cambiato sezioni diverse (per continuare l'analogia del modulo). O se la modifica ha un grande impatto sul business (un grande ordine), vuoi accettarlo e risolvere i conflitti minori in seguito (ad esempio, l'aggiornamento annuale delle informazioni di contatto non è stato completato).

Credo che Akka abbia una serie di altre dimensioni come il modo in cui gestisce i fallimenti, i supervisori, ecc. che sono considerazioni importanti per gli sviluppatori.

Scriverò sul modello di attore in generale (non solo su Akka) rispetto ad altri modelli di concorrenza come la classica concorrenza simultanea basata su lock e la memoria transazionale pulita.

Vantaggi

1. Concetto più semplice da comprendere e utilizzare

   • La concorrenza basata sul blocco è difficile; in particolare è molto difficile farlo bene perché ci sono molti concetti da capire e usare per essere corretti ed efficienti: serrature, semafori, thread, sincronizzazione, mutua esclusione, barriera di memoria ecc.

   • Gli attori, d'altra parte sono un concetto più astratto; hai attori che inviano e ricevono messaggi. Non è necessario cogliere e utilizzare concetti di basso livello come la barriera della memoria.

2. Impone l'immutabilità

   • La mutabilità è una fonte di molti errori e bug nella programmazione, specialmente nelle applicazioni multi-thread. Il modello di attore risolve questo problema rafforzando l'immutabilità.

3. Meno errori inclini

   • A causa dei due precedenti motivi

4. efficiente

   • Non così efficiente come una buona scrittura basata su un blocco, ma in generale più efficiente della memoria transazionale del software.

5. Facilmente scalabile

   • In teoria almeno, l'applicazione dovrebbe scalare abbastanza bene aggiungendo più attori per svolgere il tuo lavoro. Con lock-based è piuttosto difficile da ridimensionare.

Svantaggi

1. Non tutte le lingue applicano facilmente l'immutabilità;

   • Erlang, il linguaggio che per primo ha reso popolari gli attori ha immutabilità nel suo nucleo, ma Java e Scala (in realtà la JVM) non impongono l'immutabilità.

2. Ancora piuttosto complesso

   • Gli attori si basano su un modello di programmazione asincrona che non è così semplice e facile da modellare in tutti gli scenari; è particolarmente difficile gestire gli errori e gli scenari di errore.

3. Non impedisce deadlock o fame

   • Due attori possono trovarsi nello stato che attendono il messaggio l'uno dall'altro; quindi hai un deadlock proprio come con i blocchi, anche se molto più facile da eseguire il debug. Con la memoria transazionale, tuttavia, ti viene garantito il deadlock gratuito.

4. Non così efficiente

   • A causa dell'immutabilità forzata e perché molti attori devono passare utilizzando lo stesso thread gli attori non saranno efficienti come la concorrenza basata su lock.

Conclusione

La concorrenza basata su lock è la più efficiente ma è difficile da programmare e soggetta a errori; la memoria transazionale del software è la più chiara, facile da programmare e meno soggetta a errori, ma è anche la meno efficiente. Gli attori sono da qualche parte tra questi due modelli con tutti gli aspetti: facilità di programmazione, efficienza e inclinazione all'errore.