In che modo il supporto di Erlang per la distribuzione * trasparente * degli attori influisce sul design dell'applicazione?

Question

Una delle caratteristiche del modello attore in Erlang è distribuzione trasparente. A meno che non stia interpretando male, quando si inviano messaggi tra attori, teoricamente non si deve presumere che si trovino nello stesso spazio del processo o addirittura collocati sulla stessa macchina fisica.

Ho sempre avuto l'impressione che i sistemi a tolleranza d'errore e distribuiti richiedano un'attenta progettazione dell'applicazione per risolvere problemi inerenti a ordering/causality e consensus (tra gli altri).

Sono sicuro che Erlang non promette di risolvere in modo trasparente queste classi di problemi, quindi la mia domanda è: come fanno gli sviluppatori di Erlang a far fronte a questo? Progetta la tua applicazione come se tutti gli attori si trovassero nello stesso spazio del processo e poi risolvessero solo i problemi di distribuzione quando arriva il momento di distribuirli effettivamente?

Se è così, è questa caratteristica distribuzionetrasparente di Erlang realtà solo interessati con il protocollo filo utilizzato per la messaggistica remota e non molto trasparente nel senso che una vera applicazione distribuita richiede ancora accurata progettazione nel livello applicazione?

Answer 1

È corretto che erlang non risolva intrinsecamente i problemi di ordine/causalità o consenso. Ciò che erlang fa per te è la differenza tra l'invio di messaggi a nodi locali o remoti.

Non sono sicuro che sarebbe davvero possibile risolvere questi problemi in un linguaggio design. Questo appartiene più propriamente a un quadro. Il framework OTP ha alcuni strumenti per aiutare in questo. Davvero è in qualche modo dipendente dal problema specifico che stai risolvendo.

Per un esempio di uno sguardo implementazione Erlang VectorClock a distributerl Erlang OTP Le autorità di vigilanza potrebbe anche fornire alcune delle infrastrutture necessarie per il consenso, ma c'è qualche pensiero che il consenso è una cosa impossibile nel messaggio asincrono passando sistemi distribuiti. Vedi la tua pagina wiki di riferimento per ulteriori informazioni su questo.

Answer 2

Erlang, infatti, risolve questi problemi in modo trasparente. Può farlo perché è un linguaggio funzionale con variabili immutabili (a assegnazione singola). Utilizza lo Actor model per la concorrenza ed è stato specificamente progettato per consentire l'hot-swap del codice e la programmazione simultanea senza che il programmatore debba preoccuparsi di synchronization.

Il Wikipedia article ha in realtà una buona descrizione di questo. Mi risulta che Ericsson abbia inventato la lingua come un modo pratico per programmare interruttori telefonici massivamente paralleli.

Answer 3

Erlang promette queste cose (http://www.sics.se/~joe/thesis/armstrong_thesis_2003.pdf sezione 3.1 (39-40)):

• Tutto è un processo.
• I processi sono fortemente isolati.
• La creazione e la distruzione dei processi è un'operazione leggera.
• Il passaggio di messaggi è l'unico modo per interagire con i processi.
• I processi hanno nomi univoci.
• Se si conosce il nome di un processo, è possibile inviare un messaggio.
• I processi non condividono risorse.
• La gestione degli errori non è locale.
• I processi fanno ciò che devono fare o fallire.

e il resto dipende da voi. Se vuoi sapere perché vedi il capitolo 2. In breve, puoi inviare un messaggio da elaborare se conosci il suo PID, anche se si trova su un altro pezzo di HW. Non puoi essere sicuro che il messaggio arrivi se non ricevi risposta con segreto comune. Si può essere certi che si riceverà un messaggio di errore quando si verifica un errore durante il monitoraggio (o il collegamento). Quelli sono elementi base con cui puoi costruire ciò che vuoi.