2011-09-06 18 views
5

¿Cuándo debo usar Actors vs. Remote Actors en Akka?Cuándo usar actores locales vs remotos?

Entiendo que ambos pueden escalar una máquina, pero solo los actores remotos pueden escalar, entonces ¿hay algún uso de producción práctico del Actor normal?

Si un actor remoto solo tiene una sobrecarga de configuración inicial menor y no tiene ninguna otra sobrecarga importante a la de un Actor normal, entonces creo que usar un Actor remoto sería el estándar, ya que puede escalar y fuera con facilidad. Incluso si nunca hay una necesidad de escalar el código de producción, sería bueno tener la opción (si no viene con el equipaje).

Cualquier observación sobre cuándo usar un Actor frente a un Actor remoto sería muy apreciada.

Respuesta

8

Los actores remotos no pueden escalar, solo son referencias remotas a un actor local en otra máquina.

Para Akka 2.0 presentaremos actores agrupados, lo que le permitirá escribir una aplicación Akka y escalarla solo usando config.

1

La pregunta es "Si un agente remoto sólo tiene una configuración inicial menor sobrecarga y no tiene ninguna otra sobrecarga mayor, entonces yo creo que el uso de un actor remoto sería el estándar ". Sin embargo, el Fallacies of distributed computing aclara que es un error de diseño suponer que la comunicación remota con cualquier tecnología no tiene carga. Tiene la responsabilidad de copiar los mensajes en bytes y transmitirlos a través de la interfaz de red. También tiene toda la complejidad de los diferentes procesos que están arriba, abajo, estancados o inalcanzables y de que la red tiene problemas para perder, duplicar o reordenar mensajes.

This great article tiene ejemplos del mundo real de errores de red extraños que hacen que la comunicación remota sea difícil de hacer a prueba de balas. El líder del proyecto Akka, Roland Kuln, en su free video course about akka dice que en su experiencia por cada 1T de mensajes de red enviados ve una corrupción. Notes on Distributed Systems for Young Bloods dice que "los sistemas distribuidos tienden a necesitar distribución real, no simulada, para eliminar sus errores", por lo que incluso las buenas pruebas unitarias no conformarán un sistema perfecto. Hay muchos consejos de que la comunicación remota no es "gratuita", sino que es un trabajo duro para ser perfecto.

Si necesita utilizar la comunicación remota para disponibilidad, o para moverse a gran escala, entonces tenga en cuenta que akka hace entrega at-least-once con posible duplicación. Por lo tanto, debe asegurarse de que los mensajes duplicados no generen malos resultados.

En el momento en que comienza a utilizar la comunicación remota, tiene un sistema distribuido que crea desafíos que se tratan en Distributed systems for fun and profit. A menos que esté haciendo cosas muy simples como las calculadoras sin estado que son idempotentes para los mensajes duplicados, las cosas se vuelven complicadas. Una de las asignaciones en ese curso de video de akka en el enlace anterior es crear una tienda de valores-clave replicada que pueda manejar los mensajes perdidos escribiendo usted mismo la lógica. Está lejos de ser una tarea fácil. El estado distribuido a través de los diferentes procesos se vuelve muy difícil, los actores encapsulan el estado, por lo tanto, distribuir actores puede ser muy difícil, dependiendo de los requisitos de coherencia y disponibilidad del sistema que está creando.

Todo esto implica que si puede evitar la interacción remota y lograr lo que necesita lograr, entonces sería prudente evitarlo. Si necesita conexión remota, Akka lo hace fácil debido a su location transparency. Así que, si bien es una gran caja de herramientas para llevar con usted en el trabajo; debe verificar si el trabajo necesita todas las herramientas o solo las más simples en la caja.

Cuestiones relacionadas