Ne, není tam žádný whitepaper a je to jako 200 řádků kódu, takže toho není tolik, co by se dalo spolknout.
V SignalR každá zpráva prochází věcí zvanou sběrnice zpráv. Když chcete škálovat napříč uzly (nebo procesy nebo doménami aplikací), implementace této sběrnice musí být schopna komunikovat s každou instancí vaší aplikace. K tomu můžete použít RedisMessageBus. Redis má podmechanismus hospod a také schopnost ukládat páry klíč-hodnota a ten první používáme pouze pro SignalR.
OffTopic:To je VELMI důležité! SignalR NENÍ spolehlivé zasílání zpráv, je to abstrakce spojení. Můžeme ukládat zprávy pro longpolling, ale **nemůžete* se spolehnout na to, že zprávy tam budou navždy. Pokud máte důležité zprávy, které potřebujete uchovat, uchovávejte je.
Každý webový server se připojuje k jedné (nebo více v nové implementaci) událostem redis, aby mezi nimi posílal zprávy. Když přijde zpráva pro jednoho nebo více klientů, je odeslána na backplane (redis) a dorazí na všechny webové servery. Každý webový server obdrží zprávu z redis a uloží ji do místní mezipaměti. Tato místní mezipaměť je místo, kde jsou obsluhováni klienti SignalR (prohlížeče atd.).
Jednou z důležitých součástí návrhu měřítka jsou kurzory. Kurzor představuje, kde se konkrétní klient nachází v nekonečném proudu zpráv. Když se klienti znovu připojí po přerušení připojení nebo se po obdržení zprávy vrátí připojení s dlouhým dotazem, požádá sběrnici, aby mi dala vše od nějaké hodnoty kurzoru. Kurzory jsou definovány implementací sběrnice zpráv a v nejnovějších zdrojích jsme to normalizovali (v době psaní tohoto článku ještě nebyly zveřejněny, ale nebudu zde zacházet do podrobností). Kurzor v aktuální implementaci redis je pouze číslo, které je inkrementováno, nic příliš složitého.
Doufejme, že to dává určitou představu o tom, jak to funguje.