Je pense au système qui informera de multiples consommateurs sur les événements qui évolèrent une population d'objets. Chaque abonné doit pouvoir être capable de souscrire à des événements sur zéro ou plus des objets, de multiples abonnés devraient pouvoir recevoir des informations sur les événements qui se produisent sur un seul objet.
Je pense que certains systèmes de file d'attente du message seront appropriés dans ce cas, mais je ne sais pas comment gérer le fait que j'aurai des millions de objets - en utilisant un sujet séparé pour tous les objets ne sonne pas bien [ Ou est-ce juste bien?].
Pouvez-vous suggérer une approche que je devrais devoir prendre et peut-être même un système de file d'attente de messages open source qui serait raisonnable?
Peu de détails supplémentaires:
Merci d'avance pour vos commentaires et désolé pour une question quelque peu vague!
5 Réponses :
S'il doit être open source, j'irais pour Activemq et un serveur d'applications pour fournir le Fonctionnalité JMS pour des sujets et il a support AJAX afin que vous puissiez y accéder de votre client
Donc, vous utiliseriez l'infrastructure JMS pour publier les sujets des objets et vous peut créer Topis comme vous en avez besoin
En outre, en utilisant un serveur d'applications Java, vous pourrez peut-être absorber des avantages à partir de la clustering, de l'équilibrage de la charge et d'autres fonctions de haute disponibilité (évidemment sur la base du produit sélectionné)
espère que cela aide !!!
ActiveMQ peut-on gérer des millions de sujets?
Je suppose que, cependant, ce n'est pas à peu près des sujets à propos de son quincaillerie (de la CPU et de beaucoup de RAM), ainsi que le système d'exploitation sous -iliant (quantité de connexions à tout moment donné, sockets / threads et les limitations de la pile TCP)
Pour être honnête, je cherchais des réponses des personnes ayant une expérience de taille similaire plutôt que des hypothèses que "cela devrait fonctionner". Mais merci quand même.
ActiveMQ est une implémentation de messagerie assez solide. Il peut ne pas être en mesure de gérer des millions de messages par seconde. Mais il y a des moyens de l'accorder pour cracher le feu. Activemq.apache.org/performance.html
rompre les sujets pour porter des événements spécifiques pour E.G. "Objet mis à jour le sujet" "Objet supprimé" ... Donc, les clients n'ont donc besoin que de s'abonner au "N ° finis:" de sujets basés sur les événements qu'ils sont intéressés.
Injectez des en-têtes dans vos messages lorsque vous les publiez et mettez l'intelligence dans les clients pour utiliser ces en-têtes comme sélecteurs de messages. Par exemple, le client connaît la liste des objets qu'il est intéressé - et disons que vous identifiez l'objet par un "ID" - l'ID peut être l'en-tête et le client utilisera "l'en-tête d'identification" pour déterminer s'il s'intéresse s'il est intéressé par le message.
Selon que vous souhaitiez, vous pouvez également envisager d'assurer une livraison garantie pour vous assurer que le client recevra le message même s'il passe hors ligne et revient plus tard.
Les options que je recommanderais en haut de la tête sont activemq, Rabbbitmq et Redis Pub Sub (Havent a vraiment travaillé sur Redis Pub-Sub, veuillez utiliser votre diligence raisonnable)
Enfin, voici quelques points de repère de performance pour rabbitmq et Redis
Il suffit de voir que vous n'avez que peu de messages d'être poussé / sec, ce n'est pas une grosse affaire pour ActiveMQ, j'ai utilisé AMQ sur un système qui traite 240 messages par seconde et cela fonctionne simplement bien. J'utilise un bassin de fil de travail de travailleurs pour traiter de manière asynchrone les messages cependant. Regardez un cadre comme Akka si vous êtes dans la terre Java, si vous ne collez pas avec Nodejs et le système Eco Cool autour de lui.
Je peux très recommander rabbitmq . Je l'ai utilisé dans quelques projets avant et de mon expérience, je pense qu'il est très fiable et offre une large gamme de configurations. Fondamentalement, la Rabbitmq est un Open-Source (licence publique de Mozilla (MPL)) Courtier de messages qui implémentent la Protocole de file d'attente de messagerie avancée (AMQP) standard.
comme documenté sur le site Web de lapbitmq:
rabbbitmq peut potentiellement exécuter sur n'importe quelle plate-forme que Erlang prend en charge, des systèmes embarqués aux clusters multicœurs et aux serveurs à base de cloud.
... ce qui signifie qu'un système d'exploitation comme Linux est pris en charge.
Il y a une bibliothèque pour nœud.js ici: https://github.com/squaremo/rabbit. JS
Il est livré avec une API basée sur HTTP pour la gestion et la surveillance du serveur rabbbitmq - y compris un outil de ligne de commande et une interface utilisateur basée sur le navigateur également - voir: http://www.rabbitmq.com/management.html .
Dans les projets avec qui j'ai travaillé, j'ai communiqué avec Rabbitmq en utilisant C # et deux wrappers différents,
easynetq et Burrow.net . Les deux sont d'excellents emballages pour rabbbitmq, mais j'ai fini par être la plupart des fan de Burrow.net, car il est plus facile et plus évident de travailler avec (ne fait pas beaucoup de magie sous le capot) et offre une bonne flexibilité pour injecter des enregistreurs, des sérialisants, c. Je n'ai jamais travaillé avec la quantité de quantité d'objets que vous allez travailler - j'ai travaillé avec des milliers (pas des millions). Cependant, peu importe le nombre d'objets que j'ai joué, Rabbitmq a toujours travaillé vraiment stable et n'a jamais été la source des erreurs dans le système.
Donc, pour résumer - rabbitmq est simple à utiliser et à configurer, prend en charge AMQP, peut être géré via http et ce que j'aime le plus - c'est solide de roche.
Bien que cela ne soit pas sûr de votre environnement de travail, mais voici mes bits. Pouvez-vous identifier chaque objet avec une pièce d'identité unique dans votre système. Si tel est le cas, vous pouvez avoir un sujet par type d'événement. par ex. Vous souhaitez suivre l'événement de suppression d'objet, l'événement de mise à jour d'objet et ainsi de suite. Donc, vous pouvez avoir une rubrique pour chaque type d'événement. Ces sujets seraient publiés avec IDS d'objet chaque fois que l'événement correspondant est arrivé à l'objet. Cela limitera le nombre de sujets dont vous avez besoin. La deuxième partie de votre problème est que différents abonnés veulent vous abonner à différents objets. Tous les abonnés ne sont donc intéressés à connaître des événements de tous les objets. Cette déclaration de problème a été soulevée au mécanisme de sélecteur de message (filtrage) fourni par le cadre de messagerie. Donc, fondamentalement, vous devez rechercher sur quelle base un abonné intéressé par un objet particulier. Avoir cette base en tant que mécanisme de filtrage de message. Cela pourrait être n'importe quoi: type d'objet, état d'objet, etc. Donc, finalement, votre système consiste en un sujet pour chaque type d'événement avec des messages d'événement de publication de quelqu'un: {Type d'objet: Objet-ID} Informations. Les abonnés pourraient souscrire à n'importe quel sujet et avec des critères de filtrage.
Si une solution ci-dessus satisfait, vous pouvez utiliser n'importe quelle solution de messagerie: ActiveMQ, WMQ, RabbitMQ.
Je peux identifier les objets ID détail. Je n'ai pas besoin de suivre ce qui s'est passé; Informations sur lesquelles quelque chose est arrivé est suffisant, il va dire au client de récupérer les détails de l'objet. Les abonnés s'abonneront à [relativement] très peu d'objets.
Étant donné que vos messages sont très petits peut vouloir envisager MQTT, conçu pour les petits appareils, bien que cela fonctionne également sur des appareils puissants. La prise en compte de la clé est la basculement bas - essentiellement un en-tête de 2 octets pour un petit message. Vous ne pouvez probablement pas utiliser de serveur MQTT simple ou open source, en raison de votre volume. Vous avez probablement besoin d'un appareil dédié de poids lourd comme un message pour gérer votre volume.
Certains autres détails de votre application vous aideraient certainement. De plus, vous ne mentionnez pas du tout la sécurité. Je suppose que vous devez avoir des besoins dans cette zone.
Merci pour votre réponse. En réalité, ce sera tout le trafic interne entre les processus / machines de confiance - donc il n'y a donc pas besoin de fonctionnalités de sécurité.
C'est un problème fondamentalement difficile à résoudre de manière évolutive, comme en témoigne, par exemple - par les problèmes de Twitter a eu. Vous pouvez utiliser un modèle de sujet standard-abonnés et utiliser un truc pour limiter le nombre de sujets: par exemple, un identifiant de sujet peut être un identifiant de messagerie 1000. Les auditeurs des sujets filtreraient uniquement les messages qu'ils sont intéressés. À propos. (Juste une idée)
@Aapo Kyrola - Merci pour l'indice. Pouvez-vous s'il vous plaît envoyer votre commentaire comme réponse? Vous pouvez également suggérer un serveur de file d'attente de messages particuliers?
Avez-vous regardé aws.amazon.com/sqs ? Et à tous les outils qu'ils pourraient fournir (notifications, etc.)
@ Resh32 - Merci pour l'indice, mais je recherche une solution pouvant être utilisée en interne.
Jetez un coup d'œil aux acteurs Idiom (comme dans Erlang ou Scala) et utilisez des structures de données immuables, cela peut vous protéger beaucoup d'effort de programmation)
J'ai récemment lu un article intéressant sur la façon dont les gens de Twitter utilisent Scala: Artima.com/ Scalazine / Articles / Twitter_on_scala.html
Je veux poser quelques questions pour plus de clarification. Tous les objets vivront-ils à la mémoire d'une seule machine? Est-ce que 10000 abonnés et 1000 abonnements par abonné est une limite supérieure réaliste?
Les «objets» sont en fait quelque chose d'autre. Ce ne sont pas des objets dans la terminologie OO. Excusez-moi de ne pas avoir été clair. Vous pouvez assumer que ce sont des personnes ou des clients sur lesquels je stocke des informations ailleurs. J'ai juste besoin d'un mécanisme avec lequel je pourrai rapidement avertir les consommateurs souscrits des changements en cours. Il suffit de leur faire savoir «quelque chose changé» - le message lui-même n'a pas à porter une charge utile supplémentaire.