Не, няма бяла книга и е като 200 реда код, така че не е толкова много за преглъщане.
В SignalR всяко съобщение преминава през нещо, наречено шина за съобщения. Когато искате да мащабирате между възли (или процеси или домейни на приложения), внедряването на тази шина трябва да може да разговаря с всеки екземпляр на вашето приложение. За да направите това, можете да използвате RedisMessageBus. Redis има pub sub механизъм, както и способността му да съхранява двойки ключови стойности и ние използваме само първия за SignalR.
OffTopic:Това е МНОГО важно! SignalR НЕ е надеждно съобщение, това е абстракция на връзката. Можем да буферираме съобщения за longpolling, но вие **не можете* да разчитате на съобщенията да са там завинаги. Ако имате важни съобщения, които трябва да продължите, тогава ги запазете.
Всеки уеб сървър се свързва с едно (или повече в новата реализация) събития на redis, за да изпраща съобщения между тях. Когато дойде съобщение за един или повече клиенти, то се изпраща на задната платка (redis) и пристига на всички уеб сървъри. Всеки уеб сървър получава съобщението от redis и го съхранява в локален кеш. Този локален кеш е мястото, където се обслужват клиенти на SignalR (браузъри и т.н.).
Една важна част от дизайна за мащабиране са курсорите. Курсорът представлява къде се намира конкретен клиент в безкраен поток от съобщения. Когато клиентите се свържат отново след прекратяване на връзка или връзка с дълга анкета се връща след получаване на съобщение, тя пита шината да ми получи всичко, след като стойността на курсора. Курсорите се дефинират от реализацията на шината за съобщения и ние сме нормализирали това в най-новите източници (все още не са пуснати в момента на писане, но няма да навлизам в подробности тук). Курсорът в текущата реализация на redis е просто число, което се увеличава, нищо твърде сложно.
Надяваме се, че това дава някаква представа за това как работи.
