Stream de Redis

SocketIO4J utiliza el cliente Redisson para conectarse a un servidor Redis. También pueden ser compatibles backends alternativos compatibles con Redis como Valkey y DragonflyDB.

El RedisStreamEventStore proporciona un almacén de eventos distribuido y en streaming para socketio4j usando Redis Streams (XADD / XREAD). Permite la escalabilidad horizontal sincronizando eventos entre múltiples instancias de servidor para que el estado interno, la pertenencia a salas y otras operaciones distribuidas permanezcan consistentes entre los nodos.

El Pub/Sub fiable de Redis usa internamente Streams para durabilidad, pero no expone offsets; Redis Streams expone offsets directamente, permitiendo reproducción controlada y recuperación del estado de conexión (función planificada para desarrollo).

Características clave

• Streaming distribuido — utiliza Redis Streams para entregar eventos a todos los nodos activos

• Continuidad de reproducción de eventos — almacena eventos recientes en el historial del stream, permitiendo reproducción controlada

• Seguimiento de offsets por tipo de evento — cada tipo de evento mantiene su propio último StreamMessageId

• Despacho en streaming — eventos procesados de forma asíncrona sin bloquear los bucles de eventos de Netty

• Prevención de duplicados — eventos producidos por el mismo nodo se filtran con nodeId

Cómo funciona

• Cada publicación realiza XADD a un stream de Redis (único o por tipo dependiendo del modo)

• Cada tipo de evento mantiene su propio offset de lectura usando StreamMessageId

• El sondeo se realiza en hilos ejecutores programados dedicados por tipo de evento

• Para cada lectura (XREAD), solo se procesan mensajes con offsets más nuevos que el último id procesado

• Los eventos se entregan a los escuchadores solo si provienen de otro nodo

• En errores o timeouts del stream, los reintentos se programan automáticamente

Modos

Modo	Comportamiento	Cuándo usar
MULTI_CHANNEL	Stream de Redis separado por tipo de evento	Por defecto; aísla el tráfico de eventos y reduce la contención
SINGLE_CHANNEL	Todos los eventos alimentados en ALL_SINGLE_CHANNEL	Cuando se requiere un orden global de todos los tipos de evento a través de los nodos

Ventajas

👍 Funciona bien para despliegues multinodo 👍 Los mensajes pueden sobrevivir a tiempo de inactividad temporal de suscriptores dependiendo de la longitud del stream 👍 Proporciona entrega basada en offset 👍 Soporta reproducción controlada de nuevos eventos después de reinicios (la función de recuperación del estado de conexión está en desarrollo, por ahora obtendrás el offset del mensaje) 👍 Usa primitivas nativas de Redis Streams sin brokers externos

Limitaciones

ℹ️ Los consumidores procesan mensajes de forma independiente — el ordenamiento es por stream, no global ℹ️ Posible entrega duplicada en reinicios o carreras en los límites de offset ℹ️ Requiere soporte de Redis Streams (no compatible con el modo Pub/Sub legado de Redis)

Garantía de entrega: Semántica de al menos una vez — los escuchadores de eventos deben ser idempotentes para manejar posibles mensajes duplicados.