Pub/Sub de Hazelcast

El HazelcastPubSubEventStore proporciona un almacén de eventos distribuido para socketio4j usando Hazelcast ITopic. Permite la escalabilidad horizontal retransmitiendo eventos entre los nodos del clúster para que las uniones y salidas de salas, cambios de estado, reconocimientos y otros eventos internos se sincronicen entre múltiples instancias del servidor.

Características clave

• Transmisión de eventos distribuida — todos los nodos reciben todos los eventos publicados

• Despacho asíncrono no bloqueante — Hazelcast gestiona la entrega fuera de los bucles de eventos de Netty

• Soporte de tema por evento — permite la separación multicanal de tipos de eventos

• Integración sencilla — utiliza funciones centrales de Hazelcast sin configuración de buffer circular

• Prevención de duplicados — los eventos del mismo nodo se omiten usando filtrado por nodeId filtrado

Cómo funciona

• Los eventos se publican en instancias de Hazelcast ITopic (una o varias dependiendo del modo)

• Cada servidor suscrito registra escuchas de mensajes de Hazelcast para la entrega de eventos

• Los escuchas locales reciben solo eventos originados externamente (filtrado por nodeId desajuste)

• Las inscripciones de escuchas se rastrean por tipo de evento para permitir una cancelación de suscripción y apagado controlados

Modos

Modo	Comportamiento	Cuándo usar
MULTI_CHANNEL	Cada tipo de evento se asigna a su propio topic de Hazelcast	Predeterminado; aísla el tráfico de eventos
SINGLE_CHANNEL	Todos los eventos dirigidos a ALL_SINGLE_CHANNEL	Cuando se desea orden entre tipos

Ventajas

👍 Funciona en despliegues multinodo 👍 No se requieren brokers adicionales si Hazelcast ya se usa para el clustering 👍 Fácil de configurar e integrar 👍 Manejo limpio de cancelación de suscripción y apagado 👍 Ideal para aplicaciones que ya usan Hazelcast para estado distribuido

Limitaciones

ℹ️ No hay persistencia de mensajes más allá del almacenamiento en búfer del topic de Hazelcast: los mensajes pueden perderse al reiniciar ℹ️ El ordenamiento es por topic, no global entre todos los tipos de eventos ℹ️ Sin reproducción histórica: los escuchas reciben solo mensajes después de la suscripción ℹ️ Posible entrega duplicada durante eventos de conmutación por error

Garantía de entrega: Semántica de al menos una vez: los escuchas de eventos deben ser idempotentes para manejar con seguridad mensajes duplicados.