Modèles et technologies pour un système capable de traiter 40 000 messages par seconde

Question

Nous devons construire un système capable de traiter 40 000 messages par seconde. Aucun message ne peut être perdu en cas de défaillance logicielle ou matérielle.

Chaque taille de message est d'environ 2-4Kb.

Le traitement d'un message consiste à valider le message, à faire quelques calculs arithmétiques simples, à enregistrer le résultat dans la base de données et (parfois) à envoyer des notifications à d'autres systèmes.

La technologie logicielle préférée est .Net.

Quels modèles de logiciel et de matériel sont les plus appropriés pour une telle tâche?

De combien de matériel aurez-vous besoin?

Answer 1

1. Mise en file d'attente des messages. Votre flux de processus semble être une cible de choix.
2. Clustering/équilibrage de charge.
3. Rationaliser votre code

La première chose que je ferais est la file d'attente les notifications. Ensuite, je mettrais en file d'attente toutes les écritures de base de données qui n'ont pas besoin de retourner une valeur. Ensuite, je regarderais à l'échelle.

Autres considérations: * Évitez les grosses structures qui nécessitent beaucoup plus de travail que les scènes dont vous avez probablement besoin. * Utilisez le cache et les variables statiques dans la mesure du possible.

40 000 messages par seconde sont réalisables, mais lorsque vous ajoutez des E/S au mixage, cela peut être imprévisible même sur un matériel ultra-rapide avec une tonne de mémoire. Essayez de faire autant de traitement hors bande que vous le pouvez. Si cela échoue, vérifiez si vous pouvez exécuter plusieurs threads (sur une machine multi-core ou multi-proc) et si vous avez besoin de plusieurs serveurs dans un cluster.

Edit:

Je ne peux pas insister assez sur les avantages des tests de charge dans un scénario comme celui-ci. Faites un prototype et un test de charge simples. Affinez le prototype jusqu'à obtenir les résultats souhaités. Puis architecte une solution finale basée sur le prototype. Tant que vous n'avez pas testé le niveau de performance souhaité, vous devinez la solution.

Answer 2

La première chose que je ferais est d'essayer de savoir exactement ce que vos exigences signifient. "Aucun message ne peut être perdu en cas de panne logicielle ou matérielle" est impossible. Supposons que vous écrivez le message à 5000 disques différents dans 5000 endroits différents. Si tous les disques échouent simultanément, vous perdrez des données, inévitablement.

De même si avez un bug quelque part, cela pourrait perdre des données. L'idée d'être capable de concevoir une solution qui fonctionnera toujours face à un bug n'importe où dans le système est impossible. Une fois que vous aurez déterminé le niveau de redondance et de fiabilité dont vous avez réellement besoin, il sera plus facile de vous aider. Il sera également plus facile pour vous d'avoir confiance que vous avez atteint ce niveau de fiabilité.

Answer 3

4k * 40,000/s = 160Mo/s est assez de bande passante.

Vous avez probablement besoin d'avoir cette bande passante dans les deux sens, puisque l'exigence de non-message-perdu signifie que toutes les parties communicantes envoient et reçoivent les deux directions. Divisez ce nombre par le débit moyen de votre carte réseau, ou la vitesse d'écriture de votre disque dur, pour découvrir qu'il s'agit d'un système hautement parallèle et redondant.

Vous devez également comparer vos opérations db et les calculs de chaque message, multipliez par 40.000 (ou, 3.5 milliards pour un seul jour), pour obtenir une estimation du matériel requis. Je suppose que l'exigence .Net sera le moindre de vos problèmes.

Answer 4

Si vous utilisez une pile Microsoft, vous devrez probablement utiliser MSMQ (Microsoft Message Queuing). Il a beaucoup d'options que vous pouvez configurer pour la fiabilité ou la performance. Jetez un oeil à la MSMQ FAQ.

Le goulot de la bouteille n'est pas en cours de traitement, mais des E/S disque. Avoir beaucoup de RAM et faire autant que possible en mémoire.

MSMQ gère sa file d'attente en mémoire mais si le matériel échoue, tout le contenu de la mémoire est perdu. Si vous marquez vos messages comme récupérables, ils sont écrits sur le disque, mais vous pouvez facilement rencontrer des goulots d'étranglement.

Answer 5

Mon conseil est d'embaucher quelqu'un qui a déjà construit un système similaire. Laissez-les choisir l'architecture et les outils de développement. Traiter des taux de transactions aussi élevés nécessitera des connaissances spécialisées en matériel et en logiciels, et le moyen le moins coûteux d'acquérir de telles connaissances est de payer pour cela.

Answer 6

Si vous utilisez MSMQ et marquez les messages comme récupérables, veillez à supprimer les messages de la file d'attente de manière fiable. Faites en sorte que ce processus soit aussi sûr que possible, car si quelque chose ne va pas, les messages peuvent s'accumuler si rapidement que le lecteur se remplira en une fraction de seconde et provoquera une panne du système. Ensuite, tous les messages entrants seront perdus. Demande-moi comment je sais. (Je ne l'ai pas créé, je devais simplement le supporter, pas amusant.)

Je n'ai jamais compris comment dire à MSMQ de conserver les messages sur un lecteur autre que C :, mais ce serait une nécessité. Au moins, le système pourra vous dire qu'il y a un problème.

Comme mentionné ci-dessus, le disque et la base de données seront le goulot d'étranglement. Je pense que MSMQ peut gérer ce volume, surtout si vous évitez les déclencheurs et autres.

La MQ d'IBM est probablement mieux adaptée à cette tâche.