Buen caso de uso para Akka [cerrado]

Descargo de responsabilidad: Yo soy el PO para Akka

Además de ofrecer un smorgasbord de concurrencia que es mucho más simple de razonar y corregir (actores, agentes, concurrencia de flujo de datos) y con control de concurrencia en forma de STM.

Estos son algunos casos de uso que puede considerar:

1. Procesamiento de transacciones (en línea juegos de azar, finanzas, estadísticas, apuestas, redes sociales, telecomunicaciones, ...)
   • escalar, escalar, tolerancia a fallos / HA
2. Servicio backend (cualquier industria, cualquier aplicación)
   • servicio REST, SOAP, cometd etc
   • actuar como hub de mensajes / capa de integración
   • escalar, escalar, tolerancia a fallos / HA
3. Simultaneidad/paralelismo de complemento ( cualquier aplicación )
   • Correcto
   • Fácil de trabajar y entender
   • Simplemente agregue los jars a su proyecto JVM existente (use Scala, Java, Groovy o JRuby)
4. Procesamiento por lotes (cualquier industria )
   • Integración de Camel a conectar con fuentes de datos por lotes
   • Los actores dividen y conquistan las cargas de trabajo por lotes
5. Centro de comunicaciones (telecomunicaciones, medios web, medios móviles )
   • escalar, escalar, tolerancia a fallos / HA
6. Servidor de juegos (juegos en línea, apuestas)
   • escalar, escalar, tolerancia a fallos / HA
7. BI/datamining / crunching de uso general
   • escalar, escalar, tolerancia a fallos / HA
8. insertar otro niza casos de uso aquí

Un ejemplo de cómo lo usamos sería en una cola de prioridad de transacciones con tarjeta de débito/crédito. Tenemos millones de estos y el esfuerzo del trabajo depende del tipo de cadena de entrada. Si la transacción es de tipo CHECK tenemos muy poco procesamiento pero si se trata de un punto de venta entonces hay mucho que hacer como fusionar con metadatos (categoría, etiqueta, etiquetas, etc) y proporcionar servicios (alertas de correo electrónico/sms, detección de fraude, saldo de fondos bajos, etc). Basado en el tipo de entrada componemos clases de varios rasgos (llamados mixins) necesarios para manejar el trabajo y luego realizar el trabajo. Todos estos trabajos entran en la misma cola en modo en tiempo real desde diferentes instituciones financieras. Una vez que los datos se limpian, se envían a diferentes almacenes de datos para su persistencia, análisis o se envían a una conexión de socket, o para levantar comet actor. Los actores que trabajan están constantemente autoequilibrando la carga del trabajo para que podamos procesar los datos lo más rápido posible. También podemos ajustar en servicios adicionales, persistencia modelos, y stm para los puntos de decisión críticos.

La transmisión de mensajes de estilo OTP de Erlang en la JVM es un gran sistema para desarrollar sistemas en tiempo real sobre los hombros de las bibliotecas y servidores de aplicaciones existentes.

Akka le permite hacer el paso de mensajes como lo haría en un tradicional esb pero con velocidad! También le proporciona herramientas en el marco para administrar la gran cantidad de grupos de actores, nodos remotos y tolerancia a errores que necesita para su solución.

Utilizamos Akka para procesar llamadas REST de forma asíncrona - junto con el servidor web asíncrono (basado en Netty) podemos lograr una mejora de 10 veces en el número de usuarios atendidos por nodo/servidor, en comparación con el subproceso tradicional por modelo de solicitud de usuario.

Dígale a su jefe que su factura de alojamiento AWS va a caer por el factor de 10 y es una obviedad! Shh... pero no se lo digas a Amazon... :)

Si abstrae el servidor de chat hasta un nivel, entonces se obtiene la respuesta.

Akka proporciona un sistema de mensajería que es similar a la mentalidad de Erlang "let it crash".

Por lo tanto, los ejemplos son cosas que necesitan diferentes niveles de durabilidad y confiabilidad de la mensajería:

• Servidor de chat
• Capa de red para un MMO
• Bomba de datos financieros
• Sistema de notificación para una aplicación iPhone/móvil/lo que sea
• Servidor REST
• Tal vez algo similar a WebMachine (guess)

Lo bueno de Akka son las opciones que ofrece para la persistencia, su implementación de STM, servidor REST y tolerancia a fallos.

No se moleste por el ejemplo de un servidor de chat, piense en él como un ejemplo de una cierta clase de solución.

Con toda su excelente documentación, me siento como un vacío es esta pregunta exacta, casos de uso y ejemplos. Teniendo en cuenta que los ejemplos no son triviales.

(Escrito con solo la experiencia de ver videos y jugando con la fuente, no he implementado nada usando akka.)

Estamos usando Akka en un proyecto de Telecomunicaciones a gran escala (desafortunadamente no puedo revelar muchos detalles). Los actores Akka se implementan y se accede de forma remota a través de una aplicación web. De esta manera, tenemos un modelo RPC simplificado basado en Google protobuffer y logramos paralelismo utilizando Akka Futures. Hasta ahora, este modelo ha funcionado brillantemente. Una nota: estamos utilizando la API de Java.

Utilizamos Akka en varios proyectos en el trabajo, el más interesante de los cuales está relacionado con la reparación de accidentes de vehículos. Principalmente en el Reino Unido, pero ahora se está expandiendo a los Estados Unidos, Asia, Australasia y Europa. Utilizamos actores para garantizar que la información de reparación de accidentes se proporcione en tiempo real para permitir la reparación segura y rentable de los vehículos.

La pregunta con Akka es realmente más 'qué no puedes hacer con Akka'. Su capacidad de integración con marcos poderosos, su poderosa abstracción y todos los los aspectos de tolerancia a fallos lo convierten en un kit de herramientas muy completo.

Puedes usar Akka para varios tipos diferentes de cosas.

Estaba trabajando en un sitio web, donde migré la pila de tecnología a Scala y Akka. Lo usamos para casi todo lo que pasó en el sitio web. A pesar de que usted podría pensar que un ejemplo de Chat es malo, todos son básicamente lo mismo:

• Actualizaciones en vivo en el sitio web (por ejemplo, vistas, me gusta,...)
• Mostrando comentarios de usuarios en vivo
• Servicios de notificación
• Búsqueda y todos los demás tipos de servicios

Especialmente las actualizaciones en vivo son fáciles, ya que se reducen a lo que es un ejemplo de Chat. La parte de servicios es otro tema interesante porque simplemente puede elegir usar actores remotos e incluso si su aplicación no está agrupada, puede implementarla en diferentes máquinas con facilidad.

También estoy usando Akka para una aplicación de enrutador automático de PCB con la idea de poder escalar de una computadora portátil a un centro de datos. Cuanto más potencia le des, mejor será el resultado. Este es extremadamente difícil de implementar si intenta usar la concurrencia habitual porque Akka también le da transparencia de ubicación.

Actualmente como un proyecto de tiempo libre, estoy construyendo un marco web utilizando solo actores. Una vez más, los beneficios son la escalabilidad de una sola máquina a un clúster completo de máquinas. Además, el uso de un enfoque basado en mensajes hace que su servicio de software esté orientado desde el principio. Tienes todos esos buenos componentes, hablando entre sí pero no necesariamente conociéndote., vivir en la misma máquina, ni siquiera en el mismo centro de datos.

Y desde que Google Reader cerró empecé con un lector de RSS, utilizando Akka, por supuesto. Se trata de servicios encapsulados para mí. Como conclusión: El modelo actor en sí es lo que debe adoptar primero y Akka es un marco muy confiable que lo ayuda a implementarlo con muchos beneficios que recibirá en el camino.

Estamos usando akka con su complemento camel para distribuir nuestro análisis y procesamiento de tendencias para twimpact.com . Tenemos que procesar entre 50 y 1000 mensajes por segundo. Además del procesamiento de múltiples nodos con camel, también se utiliza para distribuir el trabajo en un solo procesador a varios trabajadores para obtener el máximo rendimiento. Funciona bastante bien, pero requiere cierta comprensión de cómo manejar las congestiones.

Estaba probando Akka (Java api). Lo que intenté fue comparar el modelo de concurrencia basado en actores de Akka con el modelo de concurrencia Java simple (java.útil.clases concurrentes).

El caso de uso fue una implementación de reducción de mapa canónico simple de conteo de caracteres. El conjunto de datos era una colección de cadenas generadas aleatoriamente (400 caracteres de longitud), y calculaba el número de vocales en ellas.

Para Akka utilicé un BalancedDispatcher (para equilibrar la carga entre hilos) y RoundRobinRouter (para mantener un límite en mis actores de función). Para Java, utilicé la técnica simple de unión por bifurcación (implementada sin ningún algoritmo de robo de trabajo) que mapearía/reduciría ejecuciones y uniría los resultados. Los resultados intermedios se mantuvieron en colas de bloqueo para que incluso la unión fuera lo más paralela posible. Probablemente, si no me equivoco, eso imitaría de alguna manera el concepto de" buzón " de los actores Akka, donde reciben mensajes.

Observación: Hasta cargas medias (~50000 entrada de cadena) los resultados fueron comparables, variando ligeramente en diferentes iteraciones. Sin embargo, a medida que aumentaba mi carga a ~100000 colgaría la solución Java. Configuré la solución Java con 20-30 hilos bajo esta condición y falló en todas las iteraciones.

Aumentar la carga a 1000000, también fue fatal para Akka. Puedo compartir el código con cualquier persona interesada en tener una comprobación cruzada.

Así que para mí, parece que Akka escala mejor que la solución multihilo tradicional de Java. Y probablemente la razón es la magia bajo el capó de Scala.

Si puedo modelar un dominio de problema como un mensaje impulsado por eventos que pasa uno, creo que Akka es una buena opción para la JVM.

Prueba realizada en: Versión de Java:1.6 IDE: Eclipse 3.7 Windows Vista 32 bit. 3GB de ram. Procesador Intel Core i5, velocidad de reloj de 2,5 GHz

Tenga en cuenta que el dominio del problema utilizado para la prueba puede ser debatido y traté de ser tan justo como mi conocimiento de Java me permitió : -)

Usamos Akka en sistemas de diálogo hablado ( primetalk). Tanto interna como externamente. Para ejecutar simultáneamente muchos canales de telefonía en un solo nodo de clúster, obviamente es necesario tener algún marco de multiproceso. Akka funciona perfectamente. Tenemos pesadilla previa con la concurrencia de java. Y con Akka es como un columpio - simplemente funciona. Robusto y fiable. 24 * 7, sin parar.

Dentro de un canal tenemos un flujo en tiempo real de eventos que son procesado en paralelo. Especialmente: - reconocimiento de voz automático largo - se hace con un actor; - productor de salida de audio que mezcla algunas fuentes de audio (incluyendo voz sintetizada); - la conversión de texto a voz es un conjunto separado de actores compartidos entre canales; - procesamiento semántico y del conocimiento.

Para hacer interconexiones de procesamiento de señales complejas usamos SynapseGrid. Tiene el beneficio de la comprobación en tiempo de compilación del flujo de datos en los sistemas actores complejos.

He implementado recientemente el ejemplo canónico de reducción de mapas en Akka: Word count. Así que es un caso de uso de Akka: mejor rendimiento. Fue más un experimento de JRuby y los actores de Akka que cualquier otra cosa, pero también muestra que Akka no es solo Scala o Java: funciona en todos los lenguajes encima de JVM.