Buffer circular de Hazelcast

El HazelcastPubSubRingBufferEventStore proporciona un almacén de eventos distribuido para socketio4j usando Hazelcast ReliableTopic / RingBuffer. Permite la escalabilidad horizontal al transmitir eventos entre los nodos del clúster para que los cambios de estado, uniones, salidas, acuses de recibo y otros eventos internos se sincronicen entre varios servidores.

Características clave

• Distribuido y replicado — los eventos se entregan a cada nodo activo del clúster a través de Hazelcast

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

• Fiabilidad respaldada por RingBuffer — los mensajes recientes sobreviven a reinicios de nodos dependiendo de la configuración de Hazelcast

• Semántica de difusión por streaming — cada nodo recibe todos los eventos (no balanceado por carga)

• Prevención de duplicados — los eventos que se originan en el mismo nodo se filtran usando filtrado por nodeId

Cómo funciona

• Cada publicación escribe el evento en un Hazelcast ReliableTopic (único o por tipo según el modo)

• Los tipos de eventos suscritos adjuntan listeners de mensajes al ring buffer subyacente

• Los mensajes se entregan a los listeners locales solo si se originaron en un nodo diferente

• Las registraciones de listeners se rastrean por tipo de evento para permitir una baja y un apagado limpios

Modos

Modo	Comportamiento	Cuándo usar
MULTI_CHANNEL	Cada tipo de evento obtiene su propio ReliableTopic	Predeterminado; reduce la contención y evita interferencias entre eventos
SINGLE_CHANNEL	Todos los eventos dirigidos a ALL_SINGLE_CHANNEL	Cuando se requiere un orden estricto entre todos los tipos de eventos

Ventajas

👍 Funciona en despliegues multinodo 👍 Sincroniza servidores socketio4j sin brokers externos 👍 Usa primitivas de Hazelcast para el clustering, no se requiere infraestructura Kafka/Redis 👍 Fácil de configurar cuando Hazelcast ya forma parte del sistema

Limitaciones

ℹ️ La capacidad del RingBuffer determina cuánto tiempo persisten los mensajes — el desbordamiento elimina los datos más antiguos ℹ️ No hay entrega transaccional ni deduplicación para semántica exactamente-una-vez ℹ️ El orden de entrega es por partición / por tema, no global entre temas ℹ️ La salud del clúster o las migraciones de particiones pueden causar entregas duplicadas temporales

Garantía de entrega: Semántica al menos una vez — los listeners de eventos deben ser idempotentes para manejar duplicados de forma segura.