No, no hay un libro blanco y son como 200 líneas de código, así que no hay mucho que tragar.
En SignalR, cada mensaje pasa por algo llamado bus de mensajes. Cuando desee escalar horizontalmente entre nodos (o procesos o dominios de aplicaciones), la implementación de este bus debe poder comunicarse con cada instancia de su aplicación. Para hacer esto, puede usar RedisMessageBus. Redis tiene un mecanismo pub sub, así como su capacidad para almacenar pares de valores clave y solo usamos el primero para SignalR.
OffTopic:¡Esto es MUY importante! SignalR NO es un mensaje confiable, es una abstracción de conexión. Es posible que almacenemos los mensajes para el sondeo prolongado, pero **no puede* confiar en que los mensajes estarán allí para siempre. Si tiene mensajes importantes que necesita conservar, entonces consérvelos.
Cada servidor web se conecta a uno (o más en la nueva implementación) eventos redis para enviar mensajes entre ellos. Cuando llega un mensaje para uno o más clientes, se envía al backplane (redis) y llega a todos los servidores web. Cada servidor web recibe el mensaje de redis y lo almacena en un caché local. Este caché local es donde se sirven los clientes de SignalR (navegadores, etc.).
Una parte importante del diseño de escalado horizontal son los cursores. Un cursor representa dónde se encuentra un cliente en particular en un flujo infinito de mensajes. Cuando los clientes se vuelven a conectar después de perder una conexión o una conexión de sondeo largo regresa después de recibir un mensaje, le pide al bus que me proporcione todo desde algún valor del cursor. Los cursores están definidos por la implementación del bus de mensajes y lo hemos normalizado en las fuentes más recientes (aún no publicado en el momento de escribir este artículo, pero no entraré en detalles aquí). El cursor en la implementación actual de redis es solo un número que se incrementa, nada demasiado complicado.
Esperemos que eso dé una idea de cómo funciona.
