Evitare il polling con i componenti

Dalla tua domanda e dai commenti ad altre risposte già date, mi sembra che tu stia lavorando su due cose: 1) eliminare l'intermediario, 2) convertire il tuo meccanismo di sondaggio in un meccanismo di spinta. Direi che possono essere visualizzati separatamente. Iniziamo con la modifica da poll a push.

In generale, direi di sì, spingere è superiore al polling. Se comprendo correttamente la tua infrastruttura, hai un intermediario che esegue sondaggi in entrambe le direzioni alla ricerca di elementi da sincronizzare tra i sistemi coinvolti. Immagino che ci sia già una sorta di coda in atto. Se il tuo intermediario ha interrogato alcuni eventi di A e B è inattivo, manterrà quegli eventi finché B non sarà di nuovo in stato di ri-trasmissione. Non sono sicuro se ho capito bene, ma assumendo questo, passare a meccanismi di spinta sarebbe piuttosto semplice e il vantaggio chiaro: invece delle informazioni di recupero intermedio (che possono o non possono esserci), A (e B, ovviamente) potrebbero basta spingere i loro eventi nel mediatore. Utilizzerà le sue code esistenti e invierà push a B immediatamente o quando lo riterrà opportuno. Ora, se questo è meglio per la tua situazione dipende da un sacco di cose, principalmente la quantità di eventi previsti e il massimo ritardo consentito tra le sincronizzazioni. Attualmente, qualsiasi numero di eventi verrà sincronizzato con un ritardo di max. 1 minuto. Con la spinta, il ritardo può diminuire pesantemente ma d'altra parte, il carico può aumentare se molti eventi (che precedentemente sono stati gestiti in un gruppo) ora provocano molte spinte singolari. Tutto questo può e deve essere gestito dall'intermediario.

Se ora cerchi di eliminare l'intermediario, tutta quella coda deve risiedere all'interno dei sistemi A e B. Se ciò è fattibile dipende molto da cosa fanno attualmente A e B. Potrebbe essere oltrepassato le loro responsabilità. Inoltre, il sovraccarico di sincronizzazione attualmente molto costante potrebbe variare come descritto in precedenza. L'intermediario può anche essere buono per la riduzione del carico. I suoi meccanismi per inoltrare eventi in arrivo potrebbero essere impostati per trasmetterli in lotti. Quello che poi guadagni è: i sistemi A e B che possono avere eventi, spingerli fuori e dimenticarsene immediatamente. È bello e semplice per loro. L'intermediario potrebbe quindi, in base a varie impostazioni come il massimo ritardo, il numero massimo di eventi, ecc., Sincronizzare tali eventi nel rispettivo altro sistema.

Sono sicuro che vedi quello che sto ottenendo e potrebbe benissimo non essere quello che stai cercando. Ma forse aiuta se ci pensi in questo modo. Fammi sapere se posso chiarire le cose.

Se l'intermediario sta attualmente tracciando i dati in base al tempo della precedente esecuzione riuscita, quindi, per eliminare l'intermediario, ogni singolo sistema potrebbe fare lo stesso in un'architettura push. Sì, ogni sistema dovrebbe tenere traccia di questo, ma è solo un singolo timestamp, non una coda piena di messaggi.

It would seem to me that either system would need to maintain its own outgoing queue in order to resume once the issue with the other system is corrected.

Sì, l'accodamento è una buona soluzione per uno scenario del genere. Questo è il motivo per cui sono fatte le code: la messa in coda dei messaggi per i suoi consumatori. Ma non capisco, perché un sistema deve mantenere its own outgoing queue .

Una semplice impostazione sarebbe, che tu abbia due servizi A e B , entrambi in Incoming Messages queue. Queste code si comportano come caselle di posta . A invia messaggi a Posta in arrivo di B e viceversa. Le code fanno, quello che potrebbero fare meglio: mettere in coda quei messaggi.

Le condizioni in cui i messaggi arrivano al consument di tale coda sono a) all'avvio, il servizio si registra come consumatore e ottiene le informazioni, che ci sono messaggi nella "casella di posta", quindi il servizio li fa apparire uno alla volta fino a quando la "casella di posta" è vuota e b) ogni volta che arriva un nuovo messaggio, il servizio riceve una notifica e apre messaggi non letti finché la casella di posta è vuota.

Dissocia i tuoi sistemi con due code di messaggi. Invii messaggi in un fire-and-forget -manner. La domanda se il destinatario è vivo non disturba il mittente. Una coda farebbe ciò che fa il tuo attuale middleware , ma in un modo più semplice.

Il punto di errore si sposta dal destinatario diretto, ad es. servizio A , all'infrastruttura di accodamento, che deve essere resiliente / ridondante = tollerante agli errori .

Each invokation keeps track of the timestamp of the last successful run--we have one timestamp for communication in either direction. In this way, if any part of the system fails, we can resume right where we left off when the issues are corrected.

Le code nello scenario precedente stavano agendo come pile e avrebbero conservato l'ordine.

E dal momento che si tratta di un sistema distribuito, devi gestire CAP ; parlato semplicemente: il problema, che hai due servizi di sincronizzazione, che potrebbero essere interrogati simultaneamente.