quel motif de conception à utiliser pour les demandes d'API multiples étranglées?

Question

J'écris un site Web qui utilise plusieurs services Web avec des restrictions de gaz. C'est à dire. Amazon est 1 demande par seconde, un autre est de 5000/jour un autre est x/minute.

Lorsqu'un utilisateur fait quelque chose, j'ai besoin de déclencher une ou plusieurs demandes aux services ci-dessus et de renvoyer les résultats (au navigateur) lorsqu'ils sont disponibles.

La solution doit être flexible afin que je puisse facilement ajouter/supprimer des services.

J'ai pensé à un système de fichier FIFO, mais certaines demandes ultérieures peuvent en fait être éligibles pour le traitement avant les précédentes.

Je demande un modèle de conception, mais toutes les suggestions de technologies appropriées sont les bienvenues, en particulier .NET.

Merci!

Answer 1

Merci pour votre commentaire. Fondamentalement, je ne veux pas rejeter les demandes, je veux les mettre en file d'attente et afficher de nouveau à l'utilisateur quand ils ont été traités. Un peu comme un système de commande.

0:00:01 demande Amazon est disponible en -> prochain emplacement disponible est en 2 secondes (0:00:03)

0:00:02 demande x entre en jeu -> prochain créneau disponible pour ce service est de 5 secondes (0:00:07)

0:00:03 demande Amazon est disponible en -> fente disponible suivant est en 2 secondes (0:00:05)

je besoin d'un système de file d'attente qui sera tirer les 2 demandes d'amazon en premier. Je suppose que ma question est de savoir s'il faut créer des files d'attente distinctes pour chaque service et toute technologie commune (par exemple Service Broker) qui convient bien à la limitation, sinon je vais créer mon propre système de limitation/mise en file d'attente. était à la recherche de modèles de conception communs (c.-à-d. producteur/consommateur ou quelque chose) puisque ce n'est pas la FIFO en raison de l'exemple ci-dessus. Jusqu'à présent, il semble qu'une file d'attente FIFO pour chaque service, avec sa propre limitation, ressemble à la manière d'aller de l'avant.

Answer 2

Je ne suis pas sûr d'avoir complètement compris où vous voyez le problème. De

Certaines demandes ultérieures peuvent en fait être éligibles pour le traitement avant les précédentes.

Je suppose que vous êtes préoccupé par les demandes de mise en mémoire tampon qui ne peuvent pas être satisfaites maintenant mais qui peuvent être traitées rapidement.

Vous avez reçu une demande telle que

{ Amazon, X } 

et en raison de (par exemple) la limitation X ne peut pas satisify cette demande en ce moment.

Ma première question serait: les demandes sont-elles indépendantes, c'est-à-dire que je peux traiter la demande Amazon immédiatement et mettre en file d'attente la demande X? Si c'est le cas, une file d'attente FIFO simple pour chaque service fera sûrement l'affaire. Vous devrez probablement avoir une taille de file d'attente maximale (étant donné que le délai d'expiration des requêtes HTTP est dépassé, vous ne pouvez pas attendre des heures).

Si vous envisagez de différer l'émission de la requête Amazon jusqu'à ce que vous puissiez émettre la requête X, les choses se compliquent. Je pense que vous avez en effet un problème de planification de réunion. Vous devez trouver un emplacement lorsque Amazon et X sont libres. Donc, vous pourriez avoir une sorte de liste de files d'attente, chaque file d'attente est pour que les demandes soient satisfaites dans cette unité de temps pour un service.

Amazon(3 per sec) 
     09:05:31 - request A, B, C 
     09:05:32 - request D, E, F 
     09:05:33 - request G - - <=== slots available 
     ---       <=== times and slots available 

X (2 per min) 
     09:05  - request M, N 
     09:06  - request O  <=== slot available 

Voici notre {Amazon, X} a une fente disponible à 09:06

Amazon(3 per sec) 
     09:05:31 - request A, B, C 
     09:05:32 - request D, E, F 
     09:05:33 - request G - - <=== slots available 
     ---       <=== times and slots available 
     09:06:01 - request P 

X (2 per min) 
     09:05  - request M, N 
     09:06  - request O, P 

Personnellement, je commence par quelque chose de beaucoup plus simple: Si la demande ne peut être satisified en ce moment parce que tout une limite de service est atteinte, il suffit de rejeter la demande.