Как работает SignalR.Redis под капотом?

Помимо чтения кода в github, существует ли какая-либо документация на бумажном носителе о том, как работает пакет SignalR.Redis? В частности, мне интересно, какие ключи он добавляет к Redis, стратегии обновления/удаления и т.д. При просмотре внутри Redis все, что я когда-либо видел, это один ключ, указанный в следующем вызове (т.е. "SignalR.Redis.Sample" ):

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

Этот ключ, похоже, является счетчиком в Redis. Я предполагаю, что другие ключи создаются и быстро удаляются для облегчения сообщений между каждым сервером приложений, подключенным к Redis.

Ответ 1

Нет там никакой бумаги, и это похоже на 200 строк кода, поэтому не так много усвоить.

В SignalR каждое сообщение проходит через объект, называемый шиной сообщений. Когда вы хотите масштабировать узлы (или процессы или домены приложений), реализация этой шины должна быть способна разговаривать с каждым экземпляром вашего приложения. Для этого вы можете использовать RedisMessageBus. Redis имеет механизм pub sub, а также способность хранить пары значений ключа, и мы используем только первый для SignalR.

OffTopic: Это ОЧЕНЬ важно! SignalR не является надежным обменом сообщениями, это абстракция соединения. Мы можем буферизовать сообщения для longpolling, но вы ** не можете * полагаться на сообщения, находящиеся там навсегда. Если у вас есть важные сообщения, которые нужно сохранить, то они сохраняются.

Каждый веб-сервер подключается к одному (или более в новой реализации) событиям redis для отправки сообщений между ними. Когда приходит сообщение для одного или нескольких клиентов, оно отправляется на объединительную плату (redis) и поступает на все веб-серверы. Каждый веб-сервер получает сообщение от redis и сохраняет его в локальном кеше. В этом локальном кеше используются клиенты SignalR (браузеры и т.д.).

Одной из важных составляющих дизайна шкалы являются курсоры. Курсор представляет, где конкретный клиент находится в бесконечном потоке сообщений. Когда клиенты повторно подключаются после сброса соединения или соединение с длительным нажатием возвращается после получения сообщения, оно спрашивает, что шина получает все, начиная с некоторого значения курсора. Курсоры определяются реализацией шины сообщений, и мы нормализуем это в последних источниках (еще не выпущенных во время написания, но я не буду вдаваться в подробности здесь). Курсор в текущей реализации redis - это просто число, которое увеличивается, ничего сложного.

Надеюсь, это даст некоторое представление о том, как это работает.