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