Gli attori remoti di AKKA potrebbero essere utilizzati in un contesto di sciame p2p?

Question

La maggior parte dei casi d'uso che ho visto per Akka attori sono altamente performanti server multicore o cluster locali.

mi incuriosisce è applicabilità al più remoto ad alta latenza e altamente mancanza di strutture sciame come le reti p2p.

L'applicazione che ho in mente avrebbe norme sulla TruStability eo resourcefullness dei nodi sciame dando loro un po 'di stato, come bittorrent avrebbe fatto. Dovrebbe anche essere in grado di propagare le transazioni attraverso lo sciame nel miglior modo possibile, ma la consistenza finale o parziale sarebbe accettabile. La scalabilità sarebbe una priorità più alta della coerenza.

AKKA è una potenziale soluzione per la costruzione di qualcosa del genere? Avrebbe eventuali vantaggi o svantaggi specifici rispetto ad altri approcci.

Answer 1

Il problema principale con l'utilizzo di Akka, in questo contesto è che il sistema Attore non dispone di un sistema di gestione di appartenenza in modo appropriato malleabile per tale calcolo distribuito decentrata.

avete bisogno di qualcosa in grado di gestire il tasso di abbandono del nodo che descrivi nel tuo scenario. In particolare, hai bisogno di qualcosa che possa monitorare quando i nodi si uniscono, partono, e sono presunti morti e scollegati a causa di guasti. Consiglierei di guardare Ibis: http://www.cs.vu.nl/ibis/ con un registro basato su gossip. Hai ancora bisogno di un nodo di bootstrap noto per portare il sistema in alto, ma altrimenti gli usi di Join, Elect, Leave del modello Ibis forniranno la scalabilità che stai cercando quando combinato con il registro basato su Gossip. Questo sistema è simile agli attori di Akka in un certo senso in quanto si basa su un sistema di chiamate verso l'alto o verso il basso e pipe unidirezionali su cui si passano messaggi. Molto facile da programmare materiale distribuito una volta ottenuto il Fu di esso.

In termini di consistenza finale, che è un problema difficile conosciuto in grandi ambienti distribuiti. Avrei bisogno di sapere di più sul tipo di transazioni che si desidera distribuire e sul livello di coerenza e conservazione della storia richieste per formulare più raccomandazioni. Alcuni lavori recenti hanno dimostrato che il meglio che si può ottenere in un ambiente così ostile è la coerenza causale delle forche, dove almeno tutti possono vedere che la storia ha biforcuto, se non determinare la forcella "vincente", senza qualche altra forchetta meccanismo di risoluzione.

Bitcoin è un esempio interessante in questo spazio, dove "vincere" è determinato dalla catena più lunga, ma ci sono altre soluzioni in questo spazio che possono o meno lavorare a seconda della semantica delle applicazioni. La tua domanda è un po 'vaga per dare consigli specifici in uno spazio di design così ampio.