¿Cuándo NO es bueno usar actores en akka / erlang?

53

He estado trabajando con akka durante 7-8 meses ahora diariamente. Cuando empecé, estaría trabajando en aplicaciones y notaría que los actores se usarían básicamente en cualquier lugar una vez dentro del sistema de actores para la comunicación entre la mayoría de los objetos. Así que hice lo mismo: girar a otro actor para x / y / z.

Me parece que esto puede ser demasiado indiscriminado, agregando complejidad donde no es necesario, pero no puedo encontrar ninguna discusión sobre dónde se debe usar a los actores frente a la lógica sincrónica o incluso asíncrona a través de futuros. Comencé a reflexionar sobre mi postura después de que mi compañero de trabajo mencionó algo similar. Hace poco me di cuenta de varios casos en los que he reflexionado sobre una tarea y luego evité crear otro actor porque podía lograr el mismo resultado de forma segura en una implementación inmutable; esperar el resultado es el caso de uso real.

En particular, me parece que en cualquier caso en el que juegues con un estado inmutable, los actores crean complejidad y limitan el rendimiento; una función pura en un objeto, por ejemplo, puede llamarse simultáneamente sin riesgo alguno a cualquier nivel de concurrencia, sin embargo, un actor solo puede procesar un mensaje a la vez. La consideración alternativa es que usted estacionará el hilo si necesita esperar el resultado, a menos que comience a usar futuros, pero en los casos en los que no necesita preocuparse por los mensajes asíncronos o la escala, parece que puede ser excesivo contratar a un actor. / p>

Entonces, mi pregunta es: ¿hay un mal momento para usar actores? Tengo curiosidad por cómo se ve Erlang y me gustaría mucho la opinión de otras personas. O si hay algunos principios sobre el uso del actor.

    
pregunta JasonG 27.09.2013 - 21:16

5 respuestas

21

Vale la pena considerar para qué se utiliza el modelo de actor: el modelo de actor es

  1. un modelo de concurrencia
  2. que evita el acceso simultáneo al estado mutable
  3. utilizar mecanismos de comunicaciones asíncronas para proporcionar concurrencia.

Esto es valioso porque el uso del estado compartido desde varios subprocesos es realmente difícil, especialmente cuando hay relaciones entre los diferentes componentes del estado compartido que deben mantenerse sincronizados. Sin embargo, si tiene componentes de dominio en los que:

  • No permites la concurrencia, O
  • No permite el estado mutable (como en la programación funcional), O
  • Debe confiar en algún mecanismo de comunicaciones síncronas,

entonces el modelo de actor no proporcionará muchos beneficios (si los hay).

Espero que ayude.

    
respondido por el Aidan Cully 28.09.2013 - 22:14
20

Esta es una pregunta en la que estoy interesado y he estado investigando. Para otros puntos de vista, consulte esta publicación del blog de Noel Walsh o esta pregunta en desbordamiento de pila. Tengo algunas opiniones que me gustaría ofrecer:

  • Creo que Akka, porque funciona con mensajes, fomenta una "mentalidad de empuje". A menudo, para la concurrencia, diría que esto no es lo que quieres. Tirar es mucho más seguro. Por ejemplo, un patrón común para sistemas distribuidos es tener un conjunto de trabajadores que procesan información en una cola . Obviamente, esto es posible en Akka pero no necesariamente parece Sea el primer acercamiento de las personas . Akka también ofrece buzones de correo duraderos pero, nuevamente, depende de cómo los uses. una sola cola compartida es mucho más flexible que las colas por trabajador para equilibrar / reasignar el trabajo.
  • Es fácil llegar a la mentalidad de reemplazar tus clases con actores. De hecho, algunas personas incluso parecen recomendarlo diciendo que los actores solo deben hacer una cosa . Tomado en cuenta la conclusión lógica, esto aumenta la complejidad del código como lo describe Jason, porque si cada clase es un actor, eso es una gran cantidad de mensajes adicionales y bloques de recepción / envío. También hace que sea más difícil entender y probar el código porque pierde la formalidad de las interfaces, y no estoy convencido de que los comentarios son una solución para esto . Además, a pesar de la la eficiencia legendaria de Akka , sospecho que la proliferación de actores no es una buena idea En cuanto al rendimiento, cuando utilizamos hilos de Java, sabemos que son preciosos y los conservamos en consecuencia.
  • Está relacionado con el punto anterior, pero otra molestia es la pérdida de información de tipo que Noel y Pino resaltan, ya que para muchos de nosotros estamos usando Scala en lugar de otros idiomas como Python. Hay algunas formas de evitar esto, pero son no estándar , no se recomienda o experimental .
  • Finalmente, la concurrencia, incluso si tiene un " deje que se bloquee " la mentalidad, es difícil. Los modelos de programación alternativos pueden ayudar, pero no solucionan los problemas, los cambian, por eso es bueno piénsalos formalmente . También es la razón por la que el desarrollador de Joe Average busca herramientas ya construidas como las bases de datos RabbitMQ, Storm, Hadoop, Spark, Kafka o NoSQL. Akka tiene algunas herramientas y componentes precompilados, lo cual es genial, pero también tiene un nivel bastante bajo, por lo que un mayor número de elementos comunes de sistemas distribuidos ayudaría a los desarrolladores y garantizaría que los sistemas se construyan correctamente.

Al igual que Jason, estoy ansioso por escuchar la opinión de otras personas aquí. ¿Cómo puedo abordar algunos de los problemas anteriores y usar Akka mejor?

    
respondido por el Mark Butler 11.02.2014 - 03:32
12

Tu intuición es correcta, IMHO. Usar actores en todas partes es como tener el martillo proverbial y ver solo clavos.

La mejor práctica de Erlang es usar procesos / actores para todas las actividades que ocurren simultáneamente. Es decir, al igual que en la vida real. A veces es difícil encontrar la granularidad correcta, pero la mayoría de las veces solo se sabe mirando el dominio modelado y usando un poco de sentido común. Me temo que no tengo un método mejor que eso, pero espero que ayude.

    
respondido por el Vlad Dumitrescu 27.09.2013 - 22:59
0

En el orden de entrada / salida de mensajes:

Recientemente me reuní con una aplicación basada en akka donde el modelo de actor realmente causó problemas de concurrencia, un modelo más simple hubiera bastado con una mejor carga.

El problema fue que los mensajes entrantes se movían en diferentes 'carriles' (a través de diferentes rutas de actores) pero el código asumió que los mensajes llegarían a su destino final en el mismo orden en que llegaron. Mientras los datos llegasen con intervalos suficientemente grandes, funcionó, ya que solo habría un mensaje en conflicto hacia el destino. Cuando los intervalos disminuyeron, comenzaron a llegar fuera de orden y causaron un comportamiento extraño.

El problema podría haberse resuelto correctamente con un poco menos de actores, pero es un error fácil de cometer cuando se abusa de ellos.

    
respondido por el DHa 06.06.2017 - 00:23
-1

En mi opinión, hay dos casos de uso para los actores. Recursos compartidos tales como puertos y similares, y estado grande. El primero ha sido cubierto bien por la discusión hasta ahora, pero el estado grande también es una razón válida.

Una gran estructura que se pasa con cada llamada de procedimiento puede usar una gran cantidad de pila. Este estado se puede colocar en un proceso separado, la estructura reemplazada por un ID de proceso y ese proceso se puede consultar según sea necesario.

Las bases de datos como mnesia se pueden considerar como un estado de almacenamiento externo al proceso de consulta.

    
respondido por el tony wallace 02.04.2016 - 02:25

Lea otras preguntas en las etiquetas

Comentarios Recientes

Debido a que solo queremos usar buenos actores y esto tiende a reducir su complejidad y conducir a transacciones costosas que terminan siendo más lentas y más difíciles de garantizar mediante la desactivación. Un ejemplo podría ser una operación de protocolo de enlace que ocurre directamente después de vincular cosas. Suponga que está seguro de que el cliente ya ha visto algo, así que permita que el cliente descargue datos y luego verifíquelos extrayendo los datos de otro lugar. Otro ejemplo en el que se requiere... Lee mas