Come funziona SignalR.Redis sotto il cofano?

Question

Oltre a leggere il codice in github, c'è qualche tipo di documentazione cartacea su come funziona il pacchetto SignalR.Redis? Nello specifico mi chiedo quali chiavi aggiunga a Redis, strategia di aggiornamento/cancellazione, ecc. Quando guardo dentro Redis tutto ciò che vedo è l'unica chiave specificata nella seguente chiamata (es. "SignalR.Redis.Sample"):

GlobalHost.DependencyResolver.UseRedis(server, Int32.Parse(port), password, "SignalR.Redis.Sample"); 

Questa chiave sembra essere un contatore in Redis. Suppongo che altre chiavi vengano create e rapidamente eliminate per facilitare i messaggi tra ogni server di app connesso a Redis.

Answer 1

No, non esiste un white paper ed è come 200 linee di codice, quindi non tanto da inghiottire.

In SignalR ogni messaggio passa attraverso una cosa chiamata bus di messaggi. Quando si desidera ridimensionare i nodi (o processi o domini delle app), l'implementazione di questo bus deve essere in grado di comunicare con ciascuna istanza dell'applicazione. Per fare ciò è possibile utilizzare RedisMessageBus. Redis ha un meccanismo pub sub così come la sua capacità di memorizzare coppie di valori chiave e usiamo solo il primo per SignalR.

OffTopic: Questo è MOLTO importante! SignalR non è un messaggio affidabile, è un'astrazione di connessione. Potremmo bufferizzare i messaggi per longpolling ma non puoi * fare affidamento sui messaggi che ci sono per sempre. Se hai messaggi importanti devi persistere, quindi persisterli.

Ogni server Web si collega a uno (o più nella nuova implementazione) eventi redis per inviare messaggi tra di loro. Quando arriva un messaggio per uno o più client, viene inviato al backplane (redis) e arriva su tutti i server web. Ogni server Web riceve il messaggio da redis e lo memorizza in una cache locale. Questa cache locale è dove vengono serviti i client SignalR (browser ecc.).

Una parte importante del design della scala è cursori. Un cursore rappresenta dove un particolare client si trova in un flusso infinito di messaggi. Quando i client si riconnettono dopo aver rilasciato una connessione o una connessione longpolling ritorna dopo aver ricevuto un messaggio, chiede al bus di recuperare tutto dal valore del cursore. I cursori sono definiti dall'implementazione del bus dei messaggi e lo abbiamo normalizzato nelle fonti più recenti (non ancora rilasciato al momento della scrittura, ma non entrerò nei dettagli qui). Il cursore dell'attuale implementazione di redis è solo un numero incrementato, niente di troppo complicato.

Speriamo che questo dia un'idea di come funziona.