it-swarm-fr.com

Quelles sont les solutions au problème de la file d'attente distribué?

J'essaie d'en apprendre davantage sur les différentes manières que le problème d'une file d'attente distribuée puisse être résolu. Je voudrais donc savoir quels produits, services, implémentations et documents de recherche qui sont déjà là.

Une mise en œuvre sera confrontée à de nombreux défis et sera forcée de faire des compromis:

  • A-t-il une commande forte ou lâche?
  • A-t-il un idempotent mis?
  • Peut-on avoir plus de files d'attente que ce qui peut tenir sur une seule machine?
  • Pouvons-nous avoir plus de données dans une file d'attente que ce qui peut tenir sur une seule machine?
  • Combien de machines peuvent se bloquer avant de perdre des données potentiellement?
  • Peut-il tolérer des divisions nettes?
  • Peut-il conclure automatiquement les données lorsqu'une fossée nette est corrigée?
  • Peut-il garantir la livraison lorsque les clients peuvent se bloquer?
  • Peut-il garantir que le même message n'est pas livré plus d'une fois?
  • Un nœud peut-il cracer à un moment donné, revenir, et ne pas envoyer de malbe?
  • Pouvez-vous ajouter des nœuds à ou supprimer des nœuds d'un cluster en cours d'exécution sans délai?
  • Pouvez-vous mettre à niveau les nœuds dans un cluster en cours d'exécution sans temps d'exécution?
  • Peut-il courir sans problèmes sur des serveurs hétérogènes?
  • Pouvez-vous "coller" les files d'attente à un groupe de serveurs? (Exemple: "Ces files d'attente ne sont autorisées que dans le centre de données européen")
  • Peut-on s'assurer de mettre des répliques de données dans au moins deux centres de données, le cas échéant?

Je n'ai aucune illusion que toute mise en œuvre pourra dire "oui" à tout cela. Je suis simplement intéressé à entendre parler des différentes implémentations; Comment ils travaillent, quels sont les compromis qu'ils ont fait et peut-être pourquoi ils ont décidé de leur ensemble de compromis.

En outre, s'il y a des défis que j'ai peut-être manqué dans la liste ci-dessus.

23
Chris Vest

Écrire un système de mise en file d'attente de base est assez simple, mais comme vous l'avez noté ci-dessus avec tous les défis, le fait de le faire est un autre sujet. J'ai utilisé des systèmes cultivés à domicile pour lesquels j'ai rédigé le code source, les systèmes 3ème partie et divers fournisseurs de JMS. JMS (service de messagerie Java) de loin est la solution la plus complète que j'ai rencontrée jusqu'à présent. Une grande partie de ce que vous demandez est disponible dans JMS. Mon fournisseur JMS préféré est ACTIFEMQ. Gratuit, performant, facile à installer, et plus important encore facile à intégrer dans mon application avec le printemps. Les fournisseurs JMS ne fournissent pas tout ce que vous avez demandé hors de la boîte, mais ils fournissent un ensemble d'outils pour gérer une grande partie de ce que vous avez interrogé si votre demande en a besoin. Je n'ai pas trouvé beaucoup d'applications besoin de tout ce que vous avez répertorié. La commande pourrait ne pas être importante (il est préférable que ce soit le cas échéant), des sujets durables pourraient ne pas être importants, une livraison garantie, etc. Vous devez simplement vous tenir au problème et utiliser ce qu'il exige.

http://activemq.apache.org/what-open-source-intgration-solution-works-best-with-activemq-.html

a-t-il une commande forte ou perdante? Oui. Il a les deux en fonction des besoins de vos programmes. Voici les détails: http://activemq.apache.org/total-ordering.html .

a-t-il un IDempotent mis? Non, mais cela est trivial à mettre en œuvre dans votre couche d'application si vous avez besoin de cela.

pouvons-nous avoir plus de files d'attente que ce qui peut tenir sur une seule machine? Oui. Vous pouvez avoir des serveurs en cluster, et si vous souhaitez configurer plusieurs machines avec différentes files d'attente, vous pouvez et tirer de l'un ou l'autre.

pouvons-nous avoir plus de données dans une file d'attente que ce qui peut tenir sur une seule machine? Oui, la plupart des fournisseurs JMS doivent utiliser une sorte de stockage DB/persistant vers Assurez-vous que les messages ne sont pas abandonnés ou perdus si le fournisseur JMS tombe en panne.

Combien de machines peuvent planter avant que nous perdions potentiellement des données? C'est un peu plus difficile à répondre car elle est liée à la synchronisation. Cependant, vous pouvez planter un fournisseur JMS et à condition que le disque ne soit pas corrompu, cela reviendra et commencera où elle a reçu la dernière commission. Cela signifie que les messages pourraient être livrés deux fois, mais si vous codez votre application pour gérer cela, ce n'est pas un problème. Tant que vous avez au moins un de chaque type (producteurs, consommateurs ou serveurs JMS), il sera terminé. Vous pouvez également avoir la charge/l'équilibre/le basculement de la redondance Si un disque se déplace sur vous.

peut-il oller des fissures nettes? Je pense que je comprends ce que vous entendez par "Net-Split", mais je ne suis pas tout à fait sûr. Je suppose que vous voulez dire si les serveurs JMS sont regroupés et que nous perdons la connexion avec l'un des serveurs sautera-t-il à un autre serveur et à la prise en charge où il s'est arrêté. Oui, mais encore une fois, ces types de situations peuvent conduire à des messages dupliqués en fonction de ce que le client a perdu la connexion.

peut-il rapprocher automatiquement les données lorsqu'une division net est corrigée? Si vous utilisez des sessions transactées, il ne refaite que tout message qui a eu un commit aux clients existants qui sont en place.

peut-il garantir la livraison lorsque les clients peuvent se bloquer? Oui c'est l'un des objectifs principaux de JMS. La livraison garantie signifie que si un message est en file d'attente, il est garanti d'être géré par un client.

peut garantir que le même message n'est pas livré plus d'une fois? Oui si les sessions transactées sont utilisées. Cela signifie qu'un client a accepté le message et appelé COMTT/ROLDBACK. Une fois que le commit est appelé, il ne refoule pas le message.

Un crash de nœud à un point donné, revenir, et ne pas envoyer de malbouffe? Dans le cas où vous avez des files d'attente en cluster durables. Oui, il ne coulera pas "Junk" si l'autre nœud du cluster a livré le message. Il peut toujours refaire tout ce qui n'a pas été reconnu.

Pouvez-vous ajouter des nœuds à des nœuds ou supprimer des nœuds d'un cluster en cours d'exécution sans temps d'arrêt? Oui.

Pouvez-vous mettre à niveau des nœuds dans un cluster en cours d'exécution sans temps d'exécution? C'est un peu plus délicieux pour moi de répondre, mais je crois que oui vous pouvez le faire.

peut-il fonctionner sans problèmes sur des serveurs hétérogènes? Qu'est-ce que cela signifie exactement? J'ai trouvé que la plupart des fournisseurs JMS sont très faciles à exécuter dans des environnements utilisant différents matériels, systèmes d'exploitation, etc. Bien que, si vous voulez dire des performances, c'est une autre chose. Tout système de traitement distribué peut être affecté négativement par un nœud lent. J'ai eu 2 8 serveurs Intel Core exécutant la file d'attente et les consommateurs. C'est 16 cœurs ensemble et j'ai obtenu une meilleure performance d'utiliser uniquement ces deux boîtes que lorsque j'ai ajouté une machine à noyau unique en tant que consommateur. Cette machine à noyau unique était tellement plus lente qu'il a ralenti la grille entière par un facteur de 2x. Cela n'avait rien à voir avec JMS en soi.

Pouvez-vous "coller" files d'attente à un groupe de serveurs? Réponse courte Oui. Je peux penser à une manière où vous pouvez exécuter un cluster qui n'est que dans le centre de données européen et configurez la file d'attente là-bas. Ensuite, dans votre configuration de printemps, configurez vos consommateurs pour consommer cette file d'attente ainsi que d'autres files d'attente sur d'autres clusters. Vous voudrez peut-être consulter les documents:

http://activemq.apache.org/clustering.html

peut s'assurer de mettre des répliques de données dans au moins deux centres de données, le cas échéant? Je le crois à nouveau, mais il est préférable de consulter les documents en regroupement.

Encore une fois JMS propose de nombreuses options que vous pouvez modifier lorsque votre besoin dicte. L'utilisation de sessions transactées et de files d'attente durables vient avec un coût de performance. J'ai vu allumer toutes les cloches et siffler les performances d'impact jusqu'à 10 fois. Lorsque j'ai utilisé JBossMQ si nous étions désactivés certaines de ces fonctionnalités, nous pourrions avoir environ 10 000 messages/s, mais nous les transformer en 1000 messages/s. Grosse chute.

13
chubbsondubs