Tout d'abord, les systèmes de messagerie (MQ) «plus anciens» sont plus anciens dans l'implémentation, mais ils sont une idée plus récente de l'ingénierie: les files d'attente persistantes transactionnelles . Les acteurs Scala et Akka sont peut-être une implémentation plus récente, mais sont construits sur un modèle de concurrence d'accès plus ancien d'acteurs.
Les deux modèles finissent cependant par être très similaires dans la pratique car ils sont tous deux basés sur un message d'événement: voir ma réponse à RabbitMQ vs Akka .
Si vous envisagez de coder uniquement pour la JVM, Akka est probablement un bon choix. Sinon, j'utiliserais RabbitMQ.
De plus, si vous êtes un développeur Scala, Akka devrait être une évidence. Cependant, les liaisons Java d'Akka ne sont pas très Java-ish et nécessitent une conversion en raison du système de type de Scala.
De plus, en Java, les gens ne créent généralement pas d'objets immuables, ce que je vous recommande de faire pour la messagerie. Par conséquent, il est très facile en Java de faire accidentellement quelque chose en utilisant Akka qui ne sera pas mis à l'échelle (en utilisant des objets mutables pour les messages, en s'appuyant sur un état de rappel de fermeture étrange). Avec MQ, ce n'est pas un problème car les messages sont toujours sérialisés au détriment de la vitesse. Avec Akka, ils ne le sont généralement pas.
Akka s'adapte également mieux à un grand nombre de consommateurs que la plupart des MQ. C'est parce que pour la plupart des clients MQ (JMS, AMQP), chaque connexion de file d'attente nécessite un thread ... donc beaucoup de files d'attente == beaucoup de threads en cours d'exécution en permanence. C'est principalement un problème de client. Je pense qu'ActiveMQ Apollo a un répartiteur non bloquant qui résout prétendument ce problème pour AMQP. Le client RabbitMQ dispose de canaux qui vous permettent de combiner plusieurs consommateurs, mais il existe toujours des problèmes avec un grand nombre de consommateurs pouvant entraîner des blocages ou des connexions, de sorte que généralement plus de threads sont ajoutés pour éviter ce problème.
Cela étant dit, la communication à distance d'Akka est plutôt nouvelle et n'offre probablement toujours pas toutes les garanties de messages fiables et la qualité de service que les files d'attente de messages traditionnelles offrent (mais cela change tous les jours). Il est également généralement pair à pair, mais je pense qu'il prend en charge le serveur à pair, ce que font généralement la plupart des systèmes MQ (c'est-à-dire un point de défaillance unique), mais il existe des systèmes MQ peer-to-peer (RabbitMQ est serveur- à pair).
Enfin, RabbitMQ et Akka forment une bonne paire. Vous pouvez utiliser Akka comme wrapper pour RabbitMQ d'autant plus que RabbitMQ ne vous aide pas à gérer la consommation des messages et à acheminer les messages localement (dans une seule JVM).
Quand choisir Akka
- Avoir beaucoup de consommateurs (pensez à des millions).
- Besoin d'une faible latence
- Ouvert au modèle d'accès concurrentiel Actor
Exemple de système: un système de chat interactif en temps réel
Quand choisir MQ
- Nécessité d'intégrer de nombreux systèmes différents (c'est-à-dire non JVM)
- La fiabilité des messages est plus importante que la latence
- Voudrait plus d'outils et d'interface utilisateur d'administration
- En raison des points précédents, mieux pour les tâches de longue durée
- Souhaiterait utiliser un modèle de concurrence différent de celui des acteurs
Exemple de système: un système de traitement par lots transactionnel planifié
EDIT sur la base des commentaires concernés
J'ai fait l'hypothèse que l'OP était concerné par le traitement distribué que Akka et Message Queues peuvent gérer. C'est que je suppose qu'il parlait d' Akka distribué . L'utilisation d'Akka pour la concurrence locale est une comparaison pomme à orange avec la plupart des files d'attente de messages . Je dis surtout parce que vous pouvez appliquer le modèle de file d'attente de messages localement en tant que modèle de concurrence (c'est-à-dire sujet, files d'attente, échanges) que font à la fois la bibliothèque Reactor et simple-react .
Choisir le bon modèle / bibliothèque d'accès concurrentiel est très important pour les applications à faible latence. Une solution de traitement distribué telle qu'une file d'attente de messages n'est généralement pas idéale car le routage est presque toujours effectué sur le fil qui est évidemment plus lent que dans l'application et donc Akka serait un choix supérieur. Cependant, je pense que certaines technologies MQ propriétaires permettent un routage local. De plus, comme je l'ai mentionné plus tôt, la plupart des clients MQ sont assez stupides à propos du threading et ne reposent pas sur des E / S non bloquantes et ont un thread par connexion / file d'attente / canal ... ironiquement, io non bloquant n'est pas toujours à faible latence mais est généralement plus de ressources efficace.
Comme vous pouvez le voir, le sujet de la programmation distribuée et de la programmation concurrente est plutôt vaste et changeant tous les jours, donc mon intention initiale n'était pas de confondre mais plutôt de me concentrer sur un domaine particulier du traitement des messages distribués, ce que je pensais que l'OP était concerné. En termes de concurrence d'accès, on peut vouloir concentrer ses recherches sur la programmation «réactive» (RFP / flux) qui est un modèle «plus récent» mais similaire au modèle d'acteur et au modèle de file d'attente de messages dont tous ces modèles peuvent être généralement combinés car ils sont basés sur les événements.