multipla Sincronizzazione Database - SignalR con la messaggistica backplane

Question

Il problema

La mia applicazione funziona come segue:

• multipla (< 20) clienti di dispositivi (Android) sono in esecuzione in un unico luogo.
• Esistono migliaia di posizioni (esistono quindi decine o centinaia di migliaia di client di dispositivo).
• Esiste anche un client di portale Web che funziona in sincronia con i dati di ciascuna posizione e i relativi client di dispositivo.
• I nuovi dati generati su un dispositivo vengono inviati al server (cloud) tramite un'API REST (Web.net ASP.net).

Finora questa applicazione è un'applicazione piuttosto standard con un client di dispositivo mobile e un client di portale web.

Tuttavia, a causa dei requisiti su ciascun client del dispositivo fuori dal mio controllo (i client del dispositivo devono funzionare in modalità offline, ridurre la latenza di rete, ecc.), Ciascun client del dispositivo non utilizza il database del server come fonte immediata di disco. Ogni client del dispositivo ha il proprio database locale (SQLite) che rimane sincronizzato con tutti i dati per la sua posizione. Per esempio: quando faccio una modifica dei dati sul client del dispositivo A, che il cambiamento ha bisogno di essere propagate ai client del dispositivo B e al portale cliente C.

• Il web client portale legge direttamente dal database del server in quanto lo fa non ha bisogno di funzionalità offline.

Come si può vedere, il problema qui è che ora abbiamo bisogno di un modo per tenere tutti i database client dispositivo in sincronia con l'altro in tempo reale. Si prevede che i brevi ritardi dei dati sincronizzati tra due client di dispositivo siano considerati accettabili.

Soluzione proposta

La mia soluzione proposta è la seguente:

• Quando un nuovo dispositivo client è in linea inizialmente, riceve un dump dei dati per quello che ha perso dopo l'ultima volta è stato on-line il server tramite API REST.
• Ogni nuovo elemento di dati pubblicato/aggiornato/eliminato dai dispositivi client tramite l'API REST viene propagato al database del server. Il database del server contiene tutti i dati per tutte le posizioni e dovrebbe essere considerato come fonte permanente di record.
• Il portale Web funziona direttamente con il database del server poiché non ha requisiti di tipo offline.
• Una connessione da ciascun dispositivo client viene stabilita per un servizio di flusso di sincronizzazione dei dati tramite SignalR.
• Un servizio di lavoro "inserisce" il database del server per le nuove operazioni di creazione/aggiornamento/eliminazione. Quando viene rilevata un'operazione CUD, un messaggio viene inviato a una coda/sottoscrizione di Azure Service Bus (tramite argomento fan-out) per ogni istanza del servizio di sincronizzazione dei dati. Ciò consente il ridimensionamento orizzontale del servizio di sincronizzazione dei dati SignalR (con un backplane del bus di servizio di Azure) poiché esistono migliaia di connessioni client del dispositivo.
• Il servizio di sincronizzazione dei dati legge dalla coda messaggi/sottoscrizione e invia un messaggio di sincronizzazione (contenente tutti i dati necessari per la sincronizzazione) a tutti i dispositivi client collegati (per la posizione correlata ai dati) tramite SignalR.

Il seguente diagramma illustra questa soluzione:

• blocchi grandi raffigurano server (quadrati grigi sono HTTP server web che può essere scalata orizzontalmente)
• frecce rappresentano la direzione dei dati scorrendo attraverso l'applicazione.

Domande

1. È SignalR la giusta tecnologia per questo problema/soluzione? Inizialmente, la mia soluzione prevedeva che ogni dispositivo client stabilisse la propria coda/sottoscrizione del servizio di manutenzione di Azure che raccoglieva messaggi dal worker del database-tailing (sync river). Il problema con questa soluzione è che spingere molti messaggi sprecati ai client di dispositivi offline che potrebbero non tornare online per molto tempo, se mai. Riportando indietro i dati delta quando un dispositivo client arriva online inizialmente e trasmettendo dati via SignalR, posso risolvere il problema.
2. Non ho usato SignalR estensivamente in un ambiente di produzione prima, quindi sono un po 'nuovo con esso. Quali problemi/sfide posso aspettarmi di provare con questa soluzione?
3. Il seguente numero article afferma che "Ci sono alcuni scenari in cui un backplane può diventare un collo di bottiglia. Ecco alcuni tipici scenari SignalR: Tempo reale ad alta frequenza (ad esempio, giochi in tempo reale): un backplane non è raccomandato per questo scenario. ". Questa soluzione rientrerebbe in questa categoria? Quali problemi potrebbe presentare il backplane della messaggistica di Azure Service Bus? In quale altro modo avrei potuto ridimensionare questa soluzione se non in questo modo?

Le vostre opinioni e raccomandazioni generali per queste soluzioni sono anche benvenute e apprezzate.

Answer 1

Hai un requisito per la comunicazione in tempo reale ai dispositivi quando sono online. Uno dei modi più promettenti per farlo è l'utilizzo di socket web.

• Utilizzando presa web per sé non è pratico e quindi ci sono popolari librerie per esso, come SignalR, socket.io. Queste librerie assorbono molte difficoltà affrontate nella produzione e anche nello sviluppo. Queste librerie supportano anche il ridimensionamento.
• Poiché lo stack è basato su rete. SignalR è la scelta qui.
• SignalR funzionerà bene nella maggior parte dei casi. Qui non è necessario preoccuparsi di backplane come un collo di bottiglia dato in giochi in tempo reale .

Ma mantenere una soluzione in tempo reale autonoma come SignalR ha un costo. Il tasso di successo della comunicazione non sarà altamente affidabile in stock SignalR e dovrai implementare vari meccanismi di monitoraggio e processi di failover. Anche la geo-distribuzione non è supportata. Quindi la prossima scelta per un sistema affidabile in tempo reale che risolva tutti i problemi di menzione è un servizio in hosting come pub.