Pattern di architettura per abbonamenti temporanei alle code di messaggi con client websocket

1

Utilizziamo Google Pub / Sub per i flussi di eventi che vogliamo vengano utilizzati da client Websocket transitori. Qual è un buon modello per creare abbonamenti e pulirli quando il client non è più connesso? Il caso d'uso principale è un portale di amministrazione in cui vogliamo aggiornare la visualizzazione in tempo reale in base agli eventi di modifica dei dati.

Pensieri iniziali:

  1. I client non si ripuliscono in modo affidabile dopo l'arresto all'arresto, quindi le sottoscrizioni dovrebbero essere ripulite esternamente in qualche modo quando i client scompaiono
  2. Ogni nodo server potrebbe creare una sottoscrizione di argomenti all'avvio e ritrasmettere i messaggi ai client interessati, ma la seconda parte sembra un po 'come costruire una nuova coda di messaggi
  3. Nel caso di (2), abbiamo ancora un problema di pulizia se i nodi si bloccano senza cancellare la loro sottoscrizione (anche se molto meno di creare una sottoscrizione per ogni client websocket)

Esiste un modello di architettura comune (o progetto esistente) che risolve questo problema?

    
posta Jer 15.06.2018 - 20:50
fonte

1 risposta

0

Se qualcuno incontra questo, la risposta più semplice che ho trovato è quella di utilizzare Redis Pub / Sub per i client websocket. Dal momento che Redis non ha sottoscrizioni persistenti o consegna garantita, ho un cliente iscritto al più affidabile Google Pub / Sub e l'iniezione di determinati argomenti in Redis Pub / Sub. I client websocket si iscrivono tramite Redis e riceveranno solo i messaggi inviati da quel momento in poi (nessun backlog) e non vi è alcun abbonamento per la pulizia dopo la disconnessione. Esattamente il comportamento che stavo cercando.

    
risposta data 28.06.2018 - 22:28
fonte

Leggi altre domande sui tag