MSMQ ReceiveByCorrelationID

Question

Nous avons un système de noyau qui communique avec ses clients et d'autres systèmes internes asynchrone par le biais de MSMQ. C'est un bon ajustement puisque les clients sont des téléphones mobiles qui envoient des sms et d'autres systèmes ont des adaptateurs MQ. De plus, ces processus de communication sont asynchrones par défaut.

Maintenant, nous avons besoin de prendre en charge d'autres systèmes qui nécessitent un style de communication synchrone par défaut. Un exemple typique de ceci serait un appareil de poche, qui supporte la communication de requête/réponse de style rpc sur HTTP. Il y a eu une proposition de solutions pour supporter cela en ajoutant un "proxy"/endpoint HTTP qui pousse les messages reçus de ces clients dans la file d'attente entrante avec un correlationId puis regarde dans la file d'attente sortante un message avec le même correlationId. Espérons que le traitement du message est terminé et que le message avec l'ID de corrélation attendu sera présent dans la file d'attente sortante. Cela se produirait sur le même fil que le message envoyé au système principal pour imiter la réponse à la demande.

Cependant, nous voyons que la réception de messages par correlationId (MessageQueue.ReceiveByCorrelationId) est un tueur de performance. Il ne faut pas beaucoup de threads clients pour vraiment ralentir le système.

Je suppose que le problème est que la conception proposée avec imitation sync demande-réponse utilisant l'approche receive by correlationid est le problème ici. Dans l'architecture actuelle, la file d'attente sortante réside sur un hôte distant, en train de lire ceci pour voir si c'est le problème ou non.

Quelqu'un at-il d'autres approches pour résoudre ce? Je suppose que la logique serait de placer les messages de la file d'attente sortante vers une base de données ou quelque chose à partir d'un seul processus de réception, puis de rechercher les messages qui ont la corrélation correspondante

Answer 1

L'exécution d'une réception distante utilise RPC et n'est pas particulièrement rapide. ça devrait être bon. Lorsque vous ajoutez l'utilisation des curseurs (dans ce cas pour la recherche dans la file d'attente pour le message avec le désiré CorrelationId) alors la performance sera certainement pas l'échelle trop bien, que vous trouvez - plus de clients signifie généralement plus de messages et un résultat lent comme le curseur doit se déplacer plus loin. Vous voulez vraiment faire ce genre de recherche sur une file d'attente locale.

Que diriez-vous d'obtenir l'obtention de la multidiffusion des messages dans la file d'attente sortante? Ensuite, tous les serveurs qui recevraient normalement à distance les messages de la file d'attente sortante peuvent à la place recevoir une copie qui irait dans une file d'attente locale pour la correspondance d'ID.

Vive
John Breakwell