À faible latence, un message à grande échelle mise en file

Question

Je vais par un peu d'une nouvelle penser à des jeux multijoueurs à grande échelle à l'ère des applications Facebook et cloud computing.

Si je devais construire quelque chose sur des protocoles ouverts existants, et je veux servir 1.000.000 joueurs simultanés, juste pour la portée du problème.

Supposons que chaque joueur a une file d'attente de messages entrants (pour le chat et ainsi de suite), et en moyenne une file d'attente de messages entrants plus (guildes, zones, instances, vente aux enchères, ...) nous avons donc 2.000.000 files d'attente. Un joueur écoutera 1-10 files d'attente à la fois. Chaque file d'attente aura peut-être en moyenne 1 message par seconde, mais certaines files d'attente aura taux beaucoup plus élevé et plus grand nombre d'auditeurs (par exemple, une file d'attente « de l'emplacement de l'entité » pour une instance de niveau). Supposons pas plus de 100 millisecondes de latence de mise en attente du système, ce qui est correct pour les jeux légèrement orienté vers l'action (mais pas des jeux comme Quake ou Unreal Tournament).

A partir d'autres systèmes, je sais que servir 10.000 utilisateurs sur un seul 1U ou boîte de lame est une attente raisonnable (en supposant qu'il n'y a rien d'autre cher se passe, comme la simulation de la physique ou tout le reste).

Alors, avec un système de cluster de la barre transversale, où les clients se connectent à des passerelles de connexion, ce qui se connectent aux serveurs de file d'attente de messages, nous obtiendrions 10.000 utilisateurs par passerelle avec 100 machines de passerelle et 20.000 files d'attente de messages par serveur de file d'attente avec 100 file d'attente Machines. Encore une fois, juste pour portée générale. Le nombre de connexions sur chaque machine MQ serait minuscule: environ 100, pour parler à chacune des portes d'entrée. Le nombre de connexions sur les portes d'entrée serait plus beaucoup d'hôtels: 10100 pour les clients + connexions à tous les serveurs de file d'attente. (En plus de cela, ajoutez des connexions pour les serveurs de simulation du monde de jeu ou tout le reste, mais je suis en train de garder cela à part pour l'instant)

Si je ne voulais pas construire ce à partir de zéro, je dois utiliser une messagerie et / ou infrastructure faire la queue qui existe. Les deux protocoles ouverts que je peux trouver sont AMQP et XMPP. L'utilisation prévue de XMPP est un peu plus comme ce que ce système de jeu aurait besoin, mais les frais généraux est tout à fait remarquable (XML, ainsi que les données de présence verbeux, ainsi que d'autres canaux qui doivent être construit au-dessus). Le modèle de données réelles de AMQP est plus proche de ce que je décris ci-dessus, mais tous les utilisateurs semblent être grandes, les sociétés de type d'entreprise et les charges de travail semblent être flux de travail connexes, non mise à jour du jeu en temps réel lié.

Quelqu'un at-il une expérience de jour avec ces technologies, ou mises en œuvre de celle-ci, que vous pouvez partager?

Answer 1

@MSalters

'file d'attente de message' Re:

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

Si vous voulez la livraison éventuelle garantie et d'autres caractéristiques de persistance et de récupération, alors vous pouvez avoir que trop - c'est une option. C'est le point entier de RabbitMQ et AMQP -. Vous pouvez avoir beaucoup de comportements avec un seul système de distribution des messages

Le modèle que vous décrivez est le comportement par défaut, ce qui est transitoire, « feu et oublier », et le routage des messages à l'endroit où les destinataires sont. Les gens utilisent RabbitMQ pour faire la découverte de multidiffusion sur EC2 pour cette raison. Vous pouvez obtenir des comportements de type UDP sur PubSub TCP unicast. Neat, hein?

Re UDP:

Je ne sais pas si UDP serait utile ici. Si vous désactivez Nagling puis RabbitMQ seul message de latence aller-retour (courtier client-client) a été mesurée à 250-300 microsecondes. Voir ici pour une comparaison avec une latence de Windows (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 à beaucoup de jeux multi-joueurs qui ont besoin de temps de latence aller-retour inférieure à 300 microsecondes. Vous pouvez obtenir ci-dessous 300US avec TCP. TCP fenêtrage est plus cher que UDP brut, mais si vous utilisez UDP pour aller plus vite, et ajouter une perte de recouvrement personnalisé ou seqno / ack / gestionnaire de resend puis qui peut vous ralentir à nouveau. Tout dépend de votre cas d'utilisation. Si vous avez vraiment vraiment vraiment besoin d'utiliser UDP et acquittements paresseux et ainsi de suite, alors vous pourriez dépouiller tcp RabbitMQ et probablement retirer cela.

J'espère que cela aide à clarifier pourquoi je recommande RabbitMQ pour le cas d'utilisation de Jon.

Answer 2

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

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

Mon système actuel sera probablement utiliser ZeroMQ, mais d'une manière assez limitée, dans le cluster. Les connexions des clients sont traitées avec une carte SIM personnalisée. démon que je construit à l'aide libev et est entièrement monothread (et montre une très bonne mise à l'échelle - il devrait être capable de gérer 50.000 connexions sur une boîte sans aucun problème -. notre sim taux tique est assez faible cependant, et il y a pas de physique).

XML (et donc XMPP) est très bien ne conviennent pas à cela, comme vous le Peg XML de traitement CPU longue avant de devenir lié sur E / S, ce qui est pas ce que vous voulez. Nous utilisons Google Buffers Protocole, en ce moment, et ceux qui semblent bien adaptés à nos besoins particuliers. Nous utilisons également TCP pour les connexions clientes. J'ai eu l'expérience en utilisant UDP et TCP pour cela dans le passé, et comme l'a fait par d'autres, UDP a un certain avantage, mais il est un peu plus difficile de travailler avec.

Si tout va bien quand nous sommes un peu plus de lancer, je serai en mesure de partager plus de détails.

Answer 3

Jon, cela ressemble à un cas d'utilisation idéal pour AMQP et RabbitMQ.

Je ne sais pas pourquoi vous dites que les utilisateurs AMQP sont toutes les grandes sociétés de type d'entreprise. Plus de la moitié de nos clients sont dans l'espace « web » allant énorme aux entreprises minuscules. Beaucoup de jeux, systèmes de paris, les systèmes de chat, des systèmes de type twittery et infras cloud computing ont été construits sur RabbitMQ. Il y a même des applications de téléphonie mobile. Ne sont qu'un flux de travaux de nombreux cas d'utilisation.

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

http://www.rabbitmq.com/how.html (assurez-vous cliquer sur la liste des cas d'utilisation sur del.icio.us aussi!)

S'il vous plaît ne prenez un coup d'oeil. Nous sommes ici pour aider. Ne hésitez pas à nous envoyer un courriel à info@rabbitmq.com ou me frapper sur twitter (@monadic).

Answer 4

FWIW, pour les cas où les résultats intermédiaires ne sont pas importants (comme les informations de positionnement) Qpid a une « file d'attente dernière valeur » qui peut fournir que la valeur la plus récente à un abonné.

Answer 5

Mon expérience était une alternative non-ouverte, BizTalk. La leçon la plus douloureuse que nous avons appris est que ces systèmes complexes ne sont pas rapides. Et comme vous avez compris des exigences matérielles, qui se traduit directement par des coûts importants.

Pour cette raison, ne vont même pas près de XML pour les interfaces de base. Votre cluster de serveurs sera de 2 millions de messages analyse pas par seconde. Cela pourrait facilement être 2-20 Go / s de XML! Cependant, la plupart des messages seront pour quelques files d'attente, alors que la plupart des files d'attente sont en fait à faible trafic.

Par conséquent, la conception de votre architecture afin qu'il soit facile de démarrer avec des serveurs de file d'attente COTS puis déplacer chaque file d'attente (type) à un serveur de file d'attente personnalisée lorsqu'un goulot d'étranglement est identifié.

En outre, pour des raisons similaires, ne présumez pas qu'une architecture de file d'attente de messages est le meilleur pour tous les besoins comminication a votre demande. Prenez votre exemple « emplacement de l'entité dans une instance ». Ceci est un cas classique où vous ne pas livraison garantie de veulent un message. La raison pour laquelle vous avez besoin de partager ces informations parce que cela change tout le temps. Donc, si un message est perdu, vous ne voulez pas passer du temps récupérer. Vous souhaitez n'envoyer l'ancien locatiom de l'entité concernée. , Vous voulez plutôt que d'envoyer l'emplacement courant de cette entité. Technologie-sage, cela signifie que vous voulez UDP, TCP et non un mécanisme de perte de recouvrement personnalisé.