Valuta i reqre http e i websocket per le trasmissioni basate sulla geolocalizzazione

0

Il mio caso di utilizzo è che ho un'app di trasmissione in tempo reale in cui gli utenti ricevono elementi di feed basati su una geolocalizzazione, ovvero un utente riceverà post trasmessi da un raggio definito dall'utente in cui risiede attualmente.

Come implementazione di back-end voglio usare cqrs. La procedura è la seguente:

  • I trasmettitori caricano i post etichettati con un geopoint (da dove viene inviato il messaggio).
  • Il produttore inserisce questi post in una coda di Kafka sull'argomento "post"
  • Il lato di lettura (consumatore) legge i messaggi in arrivo e li archivia in un database che supporta gli indici geografici.

Gli utenti riceveranno aggiornamenti quando nuovi post all'interno del raggio definito dall'utente sono stati trasmessi da altri utenti (di pubblicazione). Non è proprio necessario che questi messaggi trasmessi vengano inoltrati ai clienti; un'etichetta con un numero che indica quanti nuovi messaggi sono stati trasmessi sarebbe stata sufficiente. L'utente può fare clic / toccare il numero nell'interfaccia utente e i nuovi post verranno recuperati con una normale chiamata http.

Per trasmettere post (o il numero di nuovi post) tramite socket web, dovrei valutare per ogni utente connesso se ha un geo-raggio definito che contiene la posizione corrente (geo-point) in cui sono stati trasmessi nuovi post. Nelle grandi città, questo potrebbe teoricamente essere un numero molto elevato di utenti.

Francamente, mi sento molto a disagio con la soluzione dell'uso di socket Web per questo caso d'uso, sia in termini di prestazioni che di scalabilità.
Quando si esegue il ridimensionamento verso altre città, questo sembra ingestibile del tutto senza un'architettura avanzata che in qualche modo separa i post per area geografica (che voglio evitare, almeno inizialmente).

Potresti darmi qualche idea su quale sarebbe un'architettura consigliabile per ottenere il risultato atteso?
Lo considereresti un caso di uso improprio per i socket Web e, in quanto tale, quale potrebbe essere un'alternativa praticabile / scalabile?

Molte grazie per il consiglio. Non mi aspettavo che questo semplice concetto di app fosse così complesso come risulta essere.

    
posta Trace 27.05.2018 - 14:51
fonte

1 risposta

1

architecture that somehow partitions posts per geo area (which I want to avoid,

Sfortunatamente questo è esattamente quello che dovresti fare.

Prima di tutto, elimina kafka. Non è una coda di messaggi.

In secondo luogo, quando un utente post vuole taggare quel post con una o più chiavi di aggregazione di area; dire codice postale o griglia quadrata o città piuttosto (o oltre) la posizione geografica.

Ora puoi avere una coda per tag di posizione in cui pubblichi il post e gli altri utenti possono iscriversi al tag di localizzazione più vicino.

Se l'area è troppo grande, il cliente può ritagliare i post aggiuntivi

Se il cliente è vicino al limite di un'area, può richiedere più di un'area. (oppure puoi utilizzare aree sovrapposte)

In termini di websocket e polling. Sì Le web socket non si adattano bene se le lasci aperte. Ma neanche lo spamming del client viene aggiornato. Probabilmente è possibile utilizzare una combinazione di web socket, mobile push messaging e passaggio al polling se il client appare inattivo. Ma sfortunatamente il TCP / IP non è realmente costruito per i media di trasmissione.

    
risposta data 27.05.2018 - 15:39
fonte

Leggi altre domande sui tag