Come gestisco le chiamate di terze parti a esecuzione prolungata dal backup della coda dei messaggi?

Question

Come gestisco le chiamate di terze parti a esecuzione prolungata dal backup della coda dei messaggi?

#1 da (2 voti)

2

Ecco il mio scenario esatto.

Devo inoltrare richieste a un servizio di terze parti
- Il servizio impiega circa 15 secondi per rispondere
- Non ha nemmeno webhook o meccanismi di richiamata
- Queste richieste non vengono fatte costantemente durante il giorno, ma a pezzi
Le richieste al servizio di terze parti sono fatte da un consumatore che sta prelevando da una coda
utilizzando impl & default default di transito di massa RabbitMQ
Tutti i messaggi generati dal prodotto sono attualmente messi in una coda. La stessa coda con le chiamate al servizio di terze parti
Ci sono attualmente 3 consumatori, con 4 thread di lavoro ciascuno per un totale di 12 thread di lavoro. Questo è il numero massimo corrente di messaggi simultanei che possono essere gestiti contemporaneamente
Durante il giorno la coda dei messaggi riceverà ~ 100 di questi messaggi che eseguiranno il backup della coda. Tutti i 12 thread di lavoro elaboreranno le chiamate ~ 15s e la coda inizierà il backup. Ciò si traduce in perdita estrema di funzionalità. E-mail ritardate, ecc. Normalmente continua a far crescere la coda per ~ 30 minuti finché non raggiunge
In questo caso, i consumatori utilizzano la CPU allo 0% perché sono tutti in attesa di thread.

La domanda che ho è come impostare la coda dei messaggi e gli utenti in modo che non eseguano il backup. Sto cercando di evitare la perdita di funzionalità del sito per quei blocchi di 30 minuti. Tutto va bene.

Recap:

1 coda
~ attività di 15 secondi in esecuzione a 0% cpu
12 thread di lavoro dei consumatori
La coda esegue il backup e impiega circa 30 minuti per raggiungere
utilizzando impl & default default di transito di massa RabbitMQ

performance message-queue

posta BradLaney 24.07.2015 - 21:26

fonte

1 risposta

Leggi altre domande sui tag performance message-queue

Autentica nei servizi? O in un endpoint che espone i servizi? Integrazione delle funzioni in un'implementazione dell'algoritmo di Shunting-Yard

score 2 · Answer 1

Ci sono un paio di modi in cui puoi gestire le attività di blocco a lungo termine:

Aumentare il numero di lavoratori. Fintanto che l'utilizzo della CPU rimane basso, i lavoratori addizionali ti permetteranno di spedire più rapidamente queste chiamate di servizio a lungo termine. Più lavoratori diventano problematici solo al punto che alcune risorse sono in conflitto (CPU, memoria, rete, disco, ecc.). In un commento si menziona che "i thread di lavoro sono limitati", ma in un'applicazione con attività di blocco a esecuzione molto lunga non è raro lanciare 100 se non 1000 di thread di lavoro al problema.
Se il problema è che le attività a esecuzione prolungata stanno affliggendo altri lavori inviati alla stessa coda, è possibile dare la priorità ai messaggi. In questo modo i lavoratori preleveranno sempre il prossimo compito con priorità più alta. Tuttavia, se la profondità della tua coda continua a crescere perché non puoi elaborare i messaggi abbastanza velocemente avrai bisogno di più lavoratori.
Un altro approccio per ridurre la fame sarebbe quello di inviare i messaggi a code diverse che hanno i propri lavoratori. Ciò offrirà la più bassa latenza per le tue attività non bloccanti e renderà più facile bilanciare l'utilizzo delle risorse quando si aggiusta il numero di lavoratori.