Я пытаюсь понять, когда использовать Akka Futures и нашел эту статью немного более полезными, чем основные документы Akka. Таким образом, похоже, что Akka Futures делает то же самое, что Java 7 Futures. Поэтому я спрашиваю:
Akka Futures реализует асинхронный способ связи, в то время как Java7 Futures реализует синхронный подход. Да, они делают то же самое - общение - но совершенно по-другому.
Папка производителя-потребителя может взаимодействовать двумя способами: синхронно и асинхронно. Синхронный способ предполагает, что потребитель имеет свой собственный поток и выполняет операцию блокировки для получения следующего подготовленного сообщения, например. BlockingQueue.take(). В асинхронном подходе потребитель не имеет нити, это всего лишь объект с по меньшей мере двумя способами: хранить сообщение и обрабатывать его. Производитель вызывает метод store, так же как он вызывает Queue.put(m) в синхронном подходе, но этот метод также инициирует выполнение метода обработки потребителя в общем пуле потоков.
UPDT Что касается второго вопроса (зачем когда-либо использовать будущее Akka): Будущее создание выглядит (и есть) проще, чем у Актера; код для цепочки фьючерсов более компактен и более нагляднее, чем у Actors. Однако обратите внимание, что будущее может передавать только одно значение (сообщение), в то время как актер может обрабатывать последовательность сообщений. Но последовательности можно обрабатывать с помощью Akka Streams. Поэтому возникает вопрос: зачем когда-либо использовать Акку Актеры? Я приглашаю более опытных разработчиков ответить на этот вопрос. Как правило, я думаю, что если ваша задача может быть решена с помощью Futures, тогда используйте Futures, иначе, если с Streams, используйте Streams, иначе, если с Аккой Актеры, затем используйте Actors, иначе ищите другую инфраструктуру.
В первой части вашего вопроса я согласен с ответом Алексея Кайгородова.
Для второй части вашего вопроса:
Полезно использовать Future внутри, когда ответы с актерами необходимо комбинировать очень определенным образом. Например, скажем, что актеру Master необходимо выполнить несколько запросов на блокировку базы данных, а затем агрегировать их результаты, и поэтому Master отправляет каждый запрос в Worker и затем агрегирует ответы. Если результаты запроса могут быть агрегированы в любом порядке (например, Master просто суммирует количество строк или что-то еще), тогда имеет смысл Worker отправлять свои результаты в Master через обратный вызов. Однако, если результаты нужно объединить в очень определенном порядке, для каждого Worker проще сразу вернуть a Future и для Master, чтобы затем манипулировать этими Futures в правильном порядке. Это можно сделать и с помощью обратных вызовов, но тогда Master нужно было бы выяснить, какой результат запроса - разместить их в правильном порядке, и будет намного сложнее оптимизировать код (например, если результаты запроса1 могут быть немедленно агрегированы с результатами запроса2, то с помощью Future эта логика может перейти непосредственно в код отправки, где идентификаторы всех запросов уже известны, тогда как для использования обратного вызова требуется Master идентифицировать результат запроса, а также определить, может ли он агрегировать запрос с любыми другими результатами запроса, которые были возвращены).