Mise en file d'attente de messages à grande échelle et à faible temps de latence

Question

Je vais à travers un peu de re-penser à grande échelle des jeux multijoueurs à l'ère de Facebook applications et le cloud computing.

Supposons que je de construire quelque chose sur le dessus de l'existant, des protocoles ouverts, et je veux le servir 1 000 000 de joueurs en simultané, juste à la portée du problème.

Supposons que chaque joueur a l'arrivée d'un message de la file d'attente (pour le chat et autres joyeusetés), et en moyenne plus de message entrant file d'attente (les guildes, les zones, instances, vente aux enchères, ...) afin de nous avons 2 000 000 de files d'attente. Un joueur sera à l'écoute de 1-10 files d'attente à la fois. Chaque file d'attente auront en moyenne peut-être 1 message par seconde, mais certaines files d'attente ont des taux beaucoup plus élevés et à la hausse du nombre d'auditeurs (disons, une "entité emplacement" file d'attente pour une instance de niveau). Supposons pas plus de 100 millisecondes, le système de files d'attente de latence, ce qui est OK pour légèrement orienté vers l'action, jeux (mais pas des jeux comme Quake ou Unreal Tournament).

D'autres systèmes, je sais que de servir les 10 000 utilisateurs sur un seul 1U ou la lame de la boîte est une attente raisonnable (en supposant qu'il ne reste plus cher en cours, comme la physique de la simulation ou de la chose).

Donc, avec un tube d'un système de cluster, où les clients se connectent à la connexion des passerelles, qui à son tour se connecter à un message de la file d'attente des serveurs, nous aimerions tirer 10 000 utilisateurs par passerelle avec 100 passerelle machines, et de 20 000 files d'attente de messages par la file d'attente du serveur avec 100 de la file d'attente des machines. Encore une fois, juste pour le général de portée. Le nombre de connexions sur chaque MQ machine serait minuscule: à propos de 100, de parler à chacun des passerelles. Le nombre de connexions sur les passerelles serait beaucoup plus élevé: 10,100 pour les clients + les connexions à tous la file d'attente des serveurs. (Sur le dessus de cela, ajouter un peu de connexions pour le monde du jeu de simulation de serveurs ou autres joyeusetés, mais j'essaie de la garder que de les séparer pour l'instant)

Si je n'avais pas envie de construire ce à partir de zéro, je dois utiliser certains de messagerie et/ou de files d'attente de l'infrastructure qui existe. Les deux protocoles ouverts je peux trouver sont AMQP et XMPP. L'utilisation prévue de XMPP est un peu à la manière de ce que ce système de jeu aurait besoin, mais la surcharge est tout à fait remarquable (XML, plus détaillé de la présence de données, ainsi que divers autres canaux qui doivent être construits sur le dessus). Les données réelles modèle de AMQP est plus proche de ce que je décris ci-dessus, mais tous les utilisateurs semblent être grande, entreprise type de sociétés, et la charge de travail semble être de flux de travail liés, pas de jeu en temps réel mise à jour.

Quelqu'un a une journée de l'expérience avec ces technologies, ou des implémentations de celle-ci, que vous pouvez partager?

Answer 1

@MSalters

Re 'message de la file d'attente':

RabbitMQ est le mode par défaut est exactement ce que vous décrivez: transitoire pubsub. Mais avec TCP au lieu de UDP.

Si vous voulez de la garantie éventuelle de livraison et d'autres de la persistance et de fonctionnalités de récupération, alors vous POUVEZ avoir que trop - c'est une option. C'est le point de l'ensemble de RabbitMQ et AMQP-vous pouvez avoir beaucoup de comportements avec juste un système de transmission de messages.

Le modèle que vous décrivez est le comportement par DÉFAUT, qui est transitoire, "fire and forget", et le routage des messages à l'endroit où les bénéficiaires sont. Les gens utilisent RabbitMQ pour faire de multidiffusion découverte sur EC2 justement pour cette raison. Vous pouvez obtenir de l'UDP type de comportements au fil de monodiffusion TCP pubsub. Pas mal, non?

Re UDP:

Je ne suis pas sûr si UDP serait utile ici. Si vous éteignez Nagling puis RabbitMQ message unique aller-retour de la latence (client-courtier-client) a été évaluée à 250 à 300 microsecondes. Voir ici pour une comparaison avec Windows latence (qui était un peu plus élevé) http://old.nabble.com/High%28er%29-latency-with-1.5.1--p21663105.html

Je ne peux pas penser à de nombreux jeux multijoueurs qui ont besoin d'aller-retour de la latence inférieure à 300 microsecondes. Vous pourriez obtenir en dessous de 300us avec le protocole TCP. TCP fenêtrage est plus cher que le raw UDP, mais si vous utilisez UDP pour aller plus vite, et ajouter un personnalisé de perte de récupération ou seqno/ack/renvoyer, puis de responsable qui peut vous ralentir. Tout dépend de votre cas d'utilisation. Si vous avez vraiment vraiment vraiment besoin d'utiliser UDP et les paresseux et les accusés de réception ainsi de suite, alors vous pourriez sortir la bande RabbitMQ TCP et probablement l'enlever.

J'espère que cela aide à clarifier pourquoi j'ai recommandé RabbitMQ pour Jon cas d'utilisation.

Cheers

alexis

Answer 2

Je suis la construction d'un tel système dès maintenant, en fait.

J'ai fait une bonne quantité de l'évaluation de plusieurs MQs, y compris RabbitMQ, Qpid, et ZeroMQ. Le temps de latence et le débit de l'un quelconque de ceux-ci sont plus que suffisant pour ce type d'application. Ce n'est pas une bonne chose, cependant, est la file d'attente le temps de création dans le milieu d'un demi-million de files d'attente ou plus. Qpid en particulier se dégrade assez sévèrement après quelques milliers de files d'attente. Pour contourner ce problème, vous aurez généralement à créer vos propres mécanismes de routage (plus petit nombre de total des files d'attente, et les consommateurs sur ces files d'attente sont des messages qu'ils n'ont pas intérêt).

Mon système actuel sera probablement utiliser ZeroMQ, mais de façon assez limitée, à l'intérieur du cluster. Les connexions des clients sont traitées avec un sim. démon que j'ai construit à l'aide de libev et est entièrement monothread (et se montrent très bonne mise à l'échelle -- il doit être capable de gérer de 50 000 connexions sur une boîte sans aucun problème, notre sim. tique taux est assez faible, cependant, et il n'y a pas de physique).

XML (et donc XMPP) est absolument pas adapté à cela, comme vous allez le peg le PROCESSEUR de traitement XML longtemps avant de devenir lié sur les I/O, ce qui n'est pas ce que vous voulez. Nous sommes à l'aide de Google Protocol Buffers, à l'heure actuelle, et celles-ci semblent bien adaptés à nos besoins. Nous sommes également à l'aide de TCP pour les connexions client. J'ai de l'expérience en utilisant UDP et TCP pour cela dans le passé, et comme souligné par d'autres, UDP ne avoir un certain avantage, mais c'est un peu plus difficile de travailler avec.

Espérons que lorsque nous sommes un peu à l'approche du lancement, je vais être capable de partager plus de détails.

Answer 3

Jon, cela sonne comme un idéal de cas d'utilisation pour AMQP et RabbitMQ.

Je ne suis pas sûr de savoir pourquoi vous dites que AMQP les utilisateurs sont tous d'une grande entreprise type de sociétés. Plus de la moitié de nos clients sont dans le " web " de l'espace allant de gigantesques ou minuscules entreprises. Beaucoup de jeux, les systèmes de pari, les systèmes de chat, twittery type de systèmes, et de cloud computing infras ont été construites à partir de RabbitMQ. Il y a même des applications pour les téléphones mobiles. Les flux de travail sont qu'un des nombreux cas d'utilisation.

Nous essayons de garder une trace de ce qui se passe ici:

http://www.rabbitmq.com/how.html (assurez-vous de cliquer à travers pour les listes de cas d'utilisation sur del.icio.nous aussi!)

S'il vous plaît ne prenez un coup d'oeil. Nous sommes là pour vous aider. Se sentir libre pour nous envoyer un courriel à info@rabbitmq.com ou frappe-moi sur twitter (@monadique).

Cheers

alexis

Answer 4

FWIW, dans les cas où les résultats intermédiaires ne sont pas importants (comme les informations de positionnement), Qpid dispose d'une "file d'attente de dernière valeur" pouvant uniquement transmettre la valeur la plus récente à un abonné.

Answer 5

Mon expérience, c'était un non-alternative ouverte, BizTalk. La plus douloureuse leçon que nous avons appris, c'est que ces systèmes complexes ne sont PAS rapides. Et comme vous avez pensé à partir de la configuration matérielle, qui se traduit directement en termes de coûts importants.

Pour cette raison, ne même pas aller près de XML pour les principales interfaces. Votre cluster de serveurs sera l'analyse de 2 millions de messages par seconde. Qui peuvent être facilement 2 à 20 gbit/s de XML! Cependant, la plupart des messages sera pour un peu de files d'attente, alors que la plupart des files d'attente sont en fait à faible trafic.

Par conséquent, la conception de votre architecture de sorte qu'il est plus facile de commencer avec des LITS de la file d'attente des serveurs et de passer ensuite à chaque file d'attente (type) un serveur de file d'attente lorsqu'un goulot d'étranglement est identifié.

Aussi, pour les mêmes raisons, ne supposez pas qu'un message de la file d'attente de l'architecture est le meilleur pour tous les comminication besoins de votre demande. Prenez votre "entité emplacement dans une instance" par exemple. C'est un cas classique où vous ne voulez de la garantie de livraison de message. La raison que vous avez besoin de partager cette information est parce qu'il change tout le temps. Ainsi, si un message est perdu, vous ne voulez pas passer le temps de le récupérer. Vous ne envoyer l'ancien locatiom de l'entité affectée. Au lieu de cela, vous voulez envoyer l' actuel emplacement de l'entité. La technologie sage, cela signifie que vous voulez UDP, pas TCP et une coutume de la perte d'un mécanisme de recouvrement.