Lorsqu'un rôle de Web place un message sur une file d'attente de stockage, comment peut-on sonder une réponse spécifique et corrélée? J'aimerais que le rôle de travailleur en arrière de placer un message sur une file d'attente de réponse, l'intention étant que l'appelant choisisse la réponse et partir de là.
Notre intention est de tirer parti de la file d'attente afin de décharger un traitement lourd sur les rôles de travailleurs en arrière afin de garantir des performances élevées sur les rôles Web. Cependant, nous ne souhaitons pas répondre aux demandes HTTP jusqu'à ce que les travailleurs en arrière soient terminés et ont répondu.
6 Réponses :
Il n'y a rien d'intrinsèque sur les files d'attente de Windows Azure qui font ce que vous demandez. Cependant, vous pouvez construire cela vous-même assez facilement facilement. Inclure un identifiant de message (GUID) dans votre file d'attente et lorsque le traitement est terminé, demandez au travailleur de pousser un nouveau message avec cet identifiant de message dans une file d'attente de canal de réponse. Votre application Web peut interroger cette file d'attente pour déterminer lorsque le traitement est terminé pour une commande donnée.
Nous avons fait quelque chose de similaire et cherche à utiliser quelque chose comme SignalR pour vous aider à répondre au client lorsque des commandes sont terminées.
C'est ce que je pensais. Nous incluons déjà une stratégie GUID d'ID de corrélation, mais cela semble être beaucoup d'interrogation sur cette file d'attente de réponse où le rôle Web tire des réponses non pertinentes. Quand j'appelle GetMessage () Existe-t-il un moyen de le libérer rapidement dans l'événement probable que ce n'est pas la réponse que j'attendais? Ou, alternativement, je pourrais peut-être donner à chaque instance de rôle Web une file d'attente dédiée. Même dans ce cas, ces files d'attente ne sont pas FIFO, alors j'aurais toujours besoin de vérifier cet identifiant de corrélation. Les pensées?
La capture avec ceci est si vous avez plus d'une instance de la bande Web (ou même des demandes de diff trait sur le même rôle Web), il est possible que le message destiné à l'instance 1 soit ramassé par exemple 2, qui vérifiera L'ID de corrélation, réalisez que cela n'attend pas cela et doit le remettre sur la file d'attente. J'ai essayé cela et ça ne va pas très bien. L'idée de table est bien meilleure.
Merci d'avoir ajouté ce commentaire. J'étais inquiet de cette chose, envisageant que l'IIS puisse traiter de nombreuses demandes simultanément sur la même boîte.
La file d'attente de réponse devrait être 1: 1 avec vos extrémités avant de Web dans ce cas. Vous auriez pu faire tourner chaque webrole et créer sa propre file d'attente. L'option Table est intéressante, mais si vous ne savez pas quand une demande viendra, vous finissez par interroger beaucoup. Popping Un message signifie quelque chose que vous avez fait a une réponse.
@dunnry 1 : Même avec 1: 1 mappage, un rôle Web n'a pas pu avoir plusieurs demandes exécutées en parallèle, qu'elle remis à la fin de la file d'attente? Si tel est le cas, il doit toujours vérifier l'ID de corrélation, car même s'il a une file d'attente dédiée, il ne peut pas garantir que le message qu'il tire de la file d'attente provient d'une demande spécifique autrement.
Je pense que tu serais bien. Si Webrole Popps Message, c'est parce qu'il est venu du client qui lui était connecté cette demande initiale instanciée. Utiliser SignalR ici pour répondre à ce canal serait suffisant.
Laisser le rôle de travailleur continuer à interroger et à traiter le message. Dès que le message est traité, ajoutez une entrée dans le stockage de table avec le corelationID (RowKey) requis et le résultat de traitement, avant de supprimer le message traité de la file d'attente.
Alors des barroles ont juste besoin de chercher la table avec le corrélationid (RowKey) souhaité et partitionkey
Idée très cool. J'aime cet ajustement, car seul le rôle Web qui a lancé la demande doit voir la réponse. J'aurai besoin d'une sorte de collecteur de déchets pour les entrées de stockage de table orphelines qui ne sont jamais sautées en cas d'échecs de rôle Web.
Je ne pense pas que ce soit une bonne idée. Ensuite, vous construisez essentiellement un nouveau système de file d'attente (en utilisant le stockage de table) au lieu d'utiliser les fonctionnalités de la file d'attente / thème de dédicace à Azure. De plus, vous devriez interroger le stockage de la table pour la réponse = très inefficace et non évolutif.
Les files d'attente sur le bus Azure Service Bus ont beaucoup plus de capacités et de paradigmes, y compris des capacités PUB / SUB pouvant aborder les problèmes liés à l'entretien de la file d'attente dans plusieurs instances.
Une approche avec pub / sous, doit avoir une file d'attente pour les demandes et une pour les réponses. Chaque instance de demande s'abonnerait également à la file d'attente de réponse avec un filtre sur l'en-tête de manière à ne recevoir que les réponses ciblées. Le message de la demande contiendrait bien sûr la valeur à la placée dans l'en-tête de réponse pour piloter le filtre.
Bienvenue sur Stackoverflow. J'apprécie votre réponse et je vais vérifier l'option de bus de service. J'ai remarqué que vos autres réponses étaient liées à l'azur. J'espère lire beaucoup comme eux!
Merci pour l'accueil chaleureux. J'espère faire plus de contributions. Oui, mon expérience actuelle de tous les azur liés.
Regardez à l'aide d'utiliser Signalr entre le rôle de travailleur et le client du navigateur. Donc, votre rôle Web met un message sur la file d'attente et renvoie un résultat au navigateur (quelque chose de simple comme «en attente ...») et l'accrocher au rôle de travailleur avec Signalr. De cette façon, votre rôle Web effectue d'autres choses et ne doit pas attendre un résultat d'un traitement asynchrone, seul le navigateur doit.
Pour la solution basée sur le bus de service, des échantillons sont disponibles pour la mise en œuvre du modèle de demande / de réponse avec files d'attente et Sujets (Pub-Sub)
Merci. A-t-il une installation pour vous assurer que, si la réponse est destinée à l'abonné, la réponse est en réalité corrélée à la demande initiale?
De la même manière qu'une simple file d'attente vous permet de concurrencer des messages, une file d'attente de bus de service activée à la session vous permet de concourir pour des sessions. Ici, vous pouvez spécifier une sessionID, puis verrouiller cette session. Tous les messages envoyés à cette session ne seront livrés que pour vous. Ainsi, si chaque abonné a son identifiant unique qu'elles utilisent comme SessionID, puis envoyez-la dans les messages tels que ReplyTosessionid, le seul code nécessaire pour garantir la réponse est corrélé est que pour le message de réponse que nous avons défini: ReplyMessage.sessionid = DemandeMessage. ReplyTosessionid. Ce modèle est montré dans les échantillons.
Merci pour votre réponse. Je t'ai voté. J'ai choisi la réponse de @henrikmh en raison du dernier paragraphe sur l'utilisation du dictionnaire
Je suis en fait au milieu de la décision similaire. Dans mon cas, j'ai un service WCF en cours d'exécution dans un rôle Web qui devrait charger des calculs sur les rôles des travailleurs. Lorsque le résultat a été calculé, le rôle Web renvoie la réponse au client.
Mes connaissances de base de la structure de données me disent que je devrais éviter d'utiliser quelque chose conçu comme une file d'attente d'une manière non-file. Cela signifie qu'une file d'attente doit toujours être entretenue d'une manière de FIFO. Donc, fondamentalement, si vous utilisez des files d'attente pour les demandes et la réponse, les threads attendus pour renvoyer les données au client devront attendre jusqu'à ce que le message de calcul est au "haut" de la file d'attente de réponse, qui n'est pas optimale. Si vous stockez les réponses à l'aide de tables Azure, le sondage des threads pour les messages créant des frais généraux inutiles
Ce que je crois, c'est une solution possible à ce problème utilise une file d'attente pour les demandes. Cela permet d'utiliser le modèle de consommation de conclusion et ainsi équilibrage de la charge. Sur les messages envoyés dans cette file d'attente, vous définissez le Propriété corrélationid sur le message. Pour répondre, le pub / sous-pièce ("Thèmes") Une partie du bus de service Azure est utilisée pour un filtre de corrélation . Lorsque votre back-end a traité la demande, elle a publié un résultat à une "ResponsectionsSubject" avec le corrélationID donné dans la demande d'origine. Maintenant, cette réponse CA soit récupérée par votre client en appelant CreateSubscride (désolé, je ne peux pas publier plus de deux liens apparemment, Google IT) en utilisant ce filtre de corrélation, et il doit être notifié lorsque la réponse est publiée. Notez que la partie CreateSubscride doit simplement être effectuée une fois dans la méthode OnStart. Ensuite, vous pouvez faire un ASYNC BeginRecieve sur cette souscription et le rôle sera informé dans le rappel donné lorsqu'une réponse à une description de sa demande est disponible. Le corrélationid vous dira quelle demande la réponse est pour. Donc, votre dernier défi consiste à remettre cette réponse au fil tenant la connexion client.
Ceci pourrait être atteint en créant un dictionnaire avec le corrélationID (probablement GUID) en tant que clé et réponses que la valeur. Lorsque votre rôle Web reçoit une demande, il crée le GUID, définissez-le comme corrélationid, ajoutez-le du hashset, tirez le message à la file d'attente, puis appelle le moniteur.Wait () sur l'objet GUID. Demandez ensuite à la méthode de la réception appelée par la succursale Ajoutez la réponse au dictionnaire, puis appelle moniteur.Notify () sur ce même objet GUID. Cela réveille votre fil de demande d'origine et vous pouvez désormais renvoyer la réponse à votre client (ou quelque chose. Fondamentalement, vous voulez simplement que votre fil dort et ne consommez pas de ressources en attente)