Nie, nie ma oficjalnej księgi i to jest jak 200 linijek kodu, więc nie za dużo do przełknięcia.
W sygnalizatorze każda wiadomość przechodzi przez coś, co nazywa się magistralą komunikatów. Jeśli chcesz skalować w poziomie między węzłami (lub procesami lub domenami aplikacji), implementacja tej magistrali musi być w stanie komunikować się z każdym wystąpieniem aplikacji. Aby to zrobić, możesz użyć RedisMessageBus. Redis ma mechanizm podrzędny pubu, a także możliwość przechowywania par klucz-wartość i używamy tylko tego pierwszego dla SignalR.
OffTopic:To BARDZO ważne! SignalR NIE jest niezawodnym komunikatem, jest to abstrakcja połączenia. Możemy buforować wiadomości do długiego odpytywania, ale **nie możesz* polegać na wiadomościach, które są tam na zawsze. Jeśli masz ważne wiadomości, które musisz zachować, zachowaj je.
Każdy serwer sieciowy łączy się z jednym (lub więcej w nowej implementacji) zdarzeniami redis, aby wysyłać wiadomości między nimi. Gdy wiadomość przychodzi do jednego lub więcej klientów, jest wysyłana do płyty montażowej (redis) i dociera do wszystkich serwerów sieci Web. Każdy serwer WWW pobiera wiadomość z redis i przechowuje ją w lokalnej pamięci podręcznej. Ta lokalna pamięć podręczna to miejsce, w którym obsługiwani są klienci SignalR (przeglądarki itp.).
Jedną z ważnych części projektu skalowania w poziomie są kursory. Kursor reprezentuje miejsce, w którym dany klient znajduje się w nieskończonym strumieniu wiadomości. Gdy klienci ponownie łączą się po zerwaniu połączenia lub połączenie typu longpolling wraca po otrzymaniu wiadomości, prosi autobus, aby przekazał mi wszystko, od pewnej wartości kursora. Kursory są definiowane przez implementację szyny komunikatów i znormalizowaliśmy to w najnowszych źródłach (jeszcze nie opublikowanych w momencie pisania tego tekstu, ale nie będę tu wchodzić w szczegóły). Kursor w bieżącej implementacji redis to tylko liczba, która jest zwiększana, nic zbyt skomplikowanego.
Mam nadzieję, że daje to pewne pojęcie o tym, jak to działa.
