Wrap REST API con un blocco per supportare richieste simultanee in un ambiente cluster

0

Abbiamo a che fare con un'API di terze parti che non gestisce la concorrenza e non abbiamo accesso diretto al database. La nostra applicazione client è distribuita in un ambiente cluster e ha più nodi di lavoro che inviano richieste di aggiornamento a questa API. Il nostro obiettivo è racchiudere questa API in un'altra API REST, in modo da poter aggiungere un livello di servizio in primo piano per controllare la concorrenza in modo che tutte le richieste vengano sincronizzate in modo pessimistico. Funzionerà sicuramente se implementiamo la nostra API wrapper in un ambiente non cluster. Questo approccio funzionerà ancora se distribuiamo la nostra API wrapper anche in un ambiente cluster? La mia preoccupazione è se il blocco pessimistico sarà condiviso su tutti i nodi worker?

    
posta Zhenyang Hua 10.07.2018 - 14:27
fonte

1 risposta

1

Vorrei sconsigliarlo. Il problema è che devi serializzare tutte le richieste, non arrestare la tua applicazione.

Un meccanismo migliore consiste nell'utilizzare una coda messaggi. Sia che tu stia eseguendo il tuo proprio, sia che (preferibilmente) usi un sistema esistente appositamente costruito, puoi avere i tuoi messaggi push API sulla Coda e il tuo wrapper manda i messaggi da inviare.

Il problema con il blocco dell'ultimo passo in un costrutto asincrono per progetto è che si corre il rischio reale di deadlock. Anche se riesci a evitare il deadlock, l'API del wrapper impiegherà molto tempo a risolvere il conflitto dei blocchi.

Se si separa la richiesta da quando viene elaborata utilizzando una coda, si evitano i problemi di deadlock o di conflitto di blocco che avranno un impatto sull'applicazione. Se ti affidi alla risposta, complicherà un po 'le cose in quanto devi aspettare che ti venga notificato che la risposta è stata ricevuta. Puoi usare la coda messaggi anche per quello scopo.

    
risposta data 10.07.2018 - 17:20
fonte

Leggi altre domande sui tag