la risposta della prima domanda è, come hai detto, che si interromperà o otterrà dei messaggi di errore dal server. dipende da come progetta il tuo programma.
Suppongo che alcuni dei nodi nel cluster stiano funzionando come server API in quanto è una configurazione ragionevole. Se non si dispone di un server API nel cluster, credo che sia necessario configurarlo da qualche altra parte. altrimenti, non penso che tu sia in grado di condurre le tue richieste.
una volta che hai macchine in grado di funzionare per il tuo lavoro di pipeline, penso che ci siano due modi per completare il tuo compito.
il primo:
crea un altro server db indipendente (chiamiamo il server db che stai usando A e questo server isolato B) che memorizza le informazioni delle richieste e scrivi una funzione (chiamiamola funzione C) che continua a interrogare B nel tuo server api (chiamiamo questa azione come 'polling'). naturalmente, è possibile impostare l'intervallo di query in C per migliorare le prestazioni. la durata dell'intervallo dovrebbe dipendere dalla tua situazione.
Una volta che il nodo API riceve la richiesta da B, interrogherà A per ottenere informazioni relative e svolgere l'attività relativa. Se l'attività è completata come aspettativa, C chiederà a B di eliminare la richiesta. D'altra parte, se A non è disponibile, C non farà nulla. Pertanto, questa richiesta non verrà eliminata da B e C riceverà nuovamente la stessa richiesta quando interroga B la prossima volta.
il secondo:
configurare un server di messaggi in coda. tutte le richieste dal lato client verranno inviate a questo server mq.
il compito di questo server mq è continuare a chiedere al server api di funzionare. se api funziona senza problemi, allora il server mq dovrebbe inserire la richiesta. altrimenti, il server mq dovrebbe mantenere la richiesta e chiedere al server api di funzionare di nuovo dopo un intervallo.
RabbitMQ con STOMP può essere una buona scelta.
è ovvio che la prima via è inefficiente. devi scrivere, leggere ed eliminare ogni richiesta. tutte queste azioni richiedono molto tempo e possono essere il collo di bottiglia se il tuo servizio deve gestire un sacco di richieste. Tuttavia, se non si desidera utilizzare un nuovo framework, questa potrebbe essere un'opzione adatta. In realtà, attualmente sto lavorando a un sistema di cloud computing, e questo è il modo in cui usiamo.
il secondo modo è molto più efficiente, ma devi installare un nuovo framework, che potrebbe essere un problema di mantenimento in futuro.