tutorial - Akka vs Java 7 Futures

scala vs kotlin

Question

Estoy tratando de entender cuándo usar Akka Futures y encontré que este artículo es un poco más útil que los documentos principales de Akka. Así que parece que Akka Futures hace exactamente lo mismo que Java 7 Futures . Entonces pregunto:

• Fuera del contexto de un sistema de actor, ¿qué beneficios tiene Akka Futures sobre Java Futures? ¿Cuándo usar cada uno?
• En el contexto de un sistema de actores, ¿por qué usar un Akka Future? ¿No son todos los mensajes de actor a actor asíncronos, concurrentes y sin bloqueo?

Answer 1

Akka Futures implementa una forma asíncrona de comunicación, mientras que Java7 Futures implementa un enfoque sincrónico. Sí, hacen lo mismo, la comunicación, pero de una manera muy diferente.

La pareja productor-consumidor puede interactuar de dos maneras: síncrona y asíncrona. La forma síncrona asume que el consumidor tiene su propio hilo y realiza una operación de bloqueo para obtener el siguiente mensaje producido, por ejemplo, BlockingQueue.take() . En el enfoque asíncrono, el consumidor no posee un hilo, es solo un objeto con al menos dos métodos: almacenar un mensaje y procesarlo. El productor llama al método de almacenamiento, igual que llama a Queue.put(m) en un enfoque sincrónico, pero este método también inicia la ejecución del método de procesamiento del consumidor en un grupo de subprocesos comunes.

UPDT En cuanto a la segunda pregunta (por qué usar un Akka Future): la creación futura parece (y es) más simple que la de un Actor; El código para una cadena de futuros es más compacto y más demostrable que el de los actores. Sin embargo, tenga en cuenta que un futuro solo puede pasar un solo valor (mensaje) mientras que un actor puede manejar una secuencia de mensajes. Pero las secuencias se pueden manejar con Akka Streams . Entonces surge la pregunta: ¿por qué usar Akka Actors? Invito a desarrolladores más experimentados a responder esta pregunta. En general, creo que si su tarea se puede resolver con Futures, entonces use Futures, si no con Streams, use Streams, si no con Akka Actors, use Actors, o busque otro framework.

Answer 2

Para la primera parte de su pregunta, estoy de acuerdo con la respuesta de Alexei Kaigorodov.

Para la segunda parte de su pregunta:

Es útil usar un Future internamente cuando las respuestas de los actores deben combinarse de una manera muy específica. Por ejemplo, supongamos que el actor Master debe realizar varias consultas de base de datos de bloqueo y luego agregar sus resultados, por lo que el Master envía cada consulta a un Worker y luego agregará las respuestas. Si los resultados de la consulta se pueden agregar en cualquier orden (por ejemplo, Master solo está sumando los recuentos de filas o lo que sea), entonces tiene sentido que Worker envíe sus resultados al Master través de una devolución de llamada. Sin embargo, si los resultados deben combinarse en un orden muy específico, es más fácil para cada Worker devolver inmediatamente un Future y para que el Master luego manipule estos Futures en el orden correcto. Esto también podría hacerse a través de devoluciones de llamada, pero luego el Master tendría que averiguar qué resultado de la consulta es cuál para ponerlos en el orden correcto y será mucho más difícil optimizar el código (por ejemplo, si los resultados de la consulta1 pueden ser inmediatamente agregada a los resultados de query2, luego, utilizando un Future esta lógica puede ir directamente al código de envío donde ya se conocen las identidades de todas las consultas, mientras que usar una devolución de llamada requeriría que el Master identifique el resultado de la consulta y también determine si puede agregar el consultar con cualquier otro resultado de consulta que haya sido devuelto).