El modelo de actores
• Modelo matemático de computación concurrente
• Su primitiva es el Actor
• Unidad fundamental de computación o cómputo• Basado en comunicaciones asíncronas• “La motivación era la posibilidad de realizar
procesamiento paralelo masivo en docenas, cientos o miles de microprocesadores, cada uno con su memoria local y procesador de comunicaciones, capaces de comunicarse a través de una red de alta velocidad”
El modelo de actores• Su filosofía, todo es un actor.• Un actor
– Procesa– Almacena– Comunica
• Un actor actúa frente al estímulo de un mensaje. Axiomas:– Crear nuevos actores– Enviar mensajes a actores conocidos– Cambiar su comportamiento para el siguiente mensaje
• Desacoplar el mensajero del receptor, fue el avance fundamental del modelo– Todo comunicación es asíncrona– El receptor es identificado a través de una dirección
El modelo de actor• Un actor es una abstracción de concurrencia
– Threads– Locks– Un mensaje a la vez
• Una solución para el desafío de la programación multicore• Comunicación asíncrona a través de mensajes• Como la comunicación es asíncrona, poseen un mailbox para recibir
mensajes• Pattern Matching de mensajes• Un actor mantiene su estado de manera interna
– Estado cambiable (Mutable state) es privado
– Estado compartido no puede ser cambiado (immutable shared state)– Puede cambiar su estado a través de mensajes
Manifiesto Reactivo
Akka es un framekork y un ambiente de ejecución, para desarrollar aplicaciones con alta concurrencia, distribuidas, resilientes y basadas en mensajes, en la JVM
Mi primer Actor (Showtime)
Reactive Streams
Participantes
• Ingenieros de – Netflix– Pivotal– Red Hat– Typesafe
• Otros como Doug Lea y Todd Montgomery
11
Receta para el éxito
• Interfaces minimalistas (Cantidad y simplicidad)• Especificación rigurosa de la Semántica• Full TCK (Technology Compatibility Kit) para verificar
las implementaciones• Completa libertada para implementar las API’s en
distintos lenguajes.
12
Oferta y Demanda
• Los items de datos fluyen río abajo• La demanda fluye contra la corriente• Los items de datos solo fluyen cuando existe
Demanda– Es el recepor quien controla la tasa de emisión de datos– La cantidad de datos en transmisión está limitada por la demanda enviada.
13
Publisher Subscriber
data
demanda
Push–Pull dinámico
• “push” cuando el consumidor es más rápido• “pull” cuando el productor es más rápido• Puede haber comportamiento push/pull• Se aglutina demanda y eso permite algutinar datos
14
Publisher Subscriber
data
demand
Back-Pressure se contagia
• C es lento– B debe bajar su velocidad de producción• A debe bajar su velocidad de producción
15
CA B
Back-Pressure se propaga
• TCP por ejemplo lo tiene incorporado
16
CA B
netw
ork
host
s
Reactive Streams
• Flujo de datos asíncrono, no bloqueante.• Flujo de demanda asíncrono y no bloqueante. ¡• Mínima coordinación y contención coordination and
contention• El paso de mensajes permite la distribución
• A través de aplicaciones, nodos, CPUs, threads, actors
17
Akka Streams
Diseño de la API
• Objetivos:– Composición al extremo– Modelo que coloca límites al procesamiento
• Consecuencias:– Streams Inmutables y reusables– Paso de materialización explícito (No hay magia)
19
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0/stream-design.html
Materialización
• Akka Streams separa el qué del cómo–Utilizando un DSL se declaran Source/Flow/Sink DSL para crear un
blueprint o esquema
–ActorMaterializer los transforma en Actores al ejecutar
• Esto permite varias estrategias alternativas para la materialización–Optimización
–Verificación/ Validación
–Deployment en Cluster
• Solo actores Akka por ahora!
20
Streams en Akka
Streams en Akka
22
Streams en Akka
23
Streams en Akka
24
Streams en Akka
25
Streams en Akka
26
Streams en Akka
27
Streams en Akka
28
Show time
• Ejemplos en– https://github.com/utaladriz/akka-stream-sample
Top Related