Во-первых, «старые» системы сообщений (MQ) старше по реализации, но они новее в инженерной идее: постоянные очереди транзакций . Scala Actors и Akka, возможно, являются более новой реализацией, но построены на более старой модели параллелизма Actors.
Однако на практике эти две модели очень похожи, поскольку обе основаны на сообщениях о событиях: см. Мой ответ на RabbitMQ vs Akka .
Если вы собираетесь писать код только для JVM, тогда Akka, вероятно, будет хорошим выбором. В противном случае я бы использовал RabbitMQ.
Кроме того, если вы разработчик Scala, тогда Akka не должно вызывать проблем. Однако Java-привязки Akka не очень похожи на Java и требуют преобразования из-за системы типов Scala.
Также в Java люди обычно не создают неизменяемые объекты, что я рекомендую вам делать для обмена сообщениями. Следовательно, в Java очень легко случайно сделать что-то с помощью Akka, которое не будет масштабироваться (используя изменяемые объекты для сообщений, полагаясь на странное состояние обратного вызова закрытия). С MQ это не проблема, потому что сообщения всегда сериализуются за счет скорости. С Аккой их вообще нет.
Akka также лучше масштабируется с большим количеством потребителей, чем большинство MQ. Это связано с тем, что для большинства клиентов MQ (JMS, AMQP) каждое соединение очереди требует потока ... таким образом, много очередей == много постоянно работающих потоков. Однако это в основном проблема клиента. Я думаю, что ActiveMQ Apollo имеет неблокирующий диспетчер, который якобы исправляет эту проблему для AMQP. У клиента RabbitMQ есть каналы, которые позволяют объединять несколько потребителей, но по-прежнему существуют проблемы с большим количеством потребителей, которые могут привести к зависанию или отключению соединений, поэтому, как правило, добавляется больше потоков, чтобы избежать этой проблемы.
При этом удаленное взаимодействие Akka является довольно новым и, вероятно, все еще не предлагает всех надежных гарантий сообщений и QoS, которые предоставляют традиционные очереди сообщений (но это меняется каждый день). Это также обычно одноранговая связь, но думаю ли я, что она поддерживает одноранговую связь, которая, как правило, является тем, что делают большинство систем MQ (т.е. единственная точка отказа), но есть системы MQ, которые являются одноранговыми (RabbitMQ - это серверная точка). вглядываться).
Наконец, RabbitMQ и Akka действительно составляют хорошую пару. Вы можете использовать Akka в качестве оболочки для RabbitMQ, особенно потому, что RabbitMQ не помогает вам обрабатывать потребление сообщений и маршрутизировать сообщения локально (в одной JVM).
Когда выбирать Акка
- Иметь много потребителей (думаю, миллионы).
- Требуется низкая задержка
- Открыт для модели параллелизма акторов
Пример системы: интерактивная система чата в реальном времени.
Когда выбирать MQ
- Необходима интеграция с множеством разных систем (например, без JVM)
- Надежность сообщений важнее задержки
- Хотелось бы больше инструментов и интерфейса администратора
- Из-за предыдущих пунктов лучше для длительных задач
- Хотели бы использовать другую модель параллелизма, чем акторы
Пример системы: запланированная система пакетной обработки транзакций
ИЗМЕНИТЬ на основе соответствующих комментариев
Я сделал предположение, что OP был связан с распределенной обработкой, которую могут обрабатывать как Akka, так и очереди сообщений. То есть я предположил, что он имел в виду распределенный Акка . Использование Akka для локального параллелизма - это сравнение яблок с апельсином для большинства очередей сообщений . Я говорю больше, потому что вы можете применить модель очереди сообщений локально как модель параллелизма (то есть тему, очереди, обмены), что и библиотека Reactor, и simple-response .
Выбор правильной модели / библиотеки параллелизма очень важен для приложений с низкой задержкой. Решение распределенной обработки, такое как очередь сообщений, как правило, не идеально, потому что маршрутизация почти всегда выполняется по сети, что, очевидно, медленнее, чем внутри приложения, и поэтому Akka будет лучшим выбором. Однако я считаю, что некоторые проприетарные технологии MQ допускают локальную маршрутизацию. Кроме того, как я упоминал ранее, большинство клиентов MQ довольно глупо относятся к потоковой передаче и не полагаются на неблокирующий ввод-вывод и имеют поток для каждого соединения / очереди / канала ... по иронии судьбы неблокирующий io не всегда имеет низкую задержку, но обычно является более ресурсным эффективный.
Как вы можете видеть, тема распределенного программирования и параллельного программирования довольно велика и меняется каждый день, поэтому мое первоначальное намерение не было путаницей, а скорее сосредоточилось на одной конкретной области распределенной обработки сообщений, которой, как я думал, занимался OP. Что касается параллелизма, можно сосредоточить свои поиски на «реактивном» программировании (RFP / потоки), которое является «более новой», но похожей моделью на модель актора и модель очереди сообщений, в которых все эти модели могут быть объединены, поскольку они основаны на событиях.