Práctica de actualización de latidos de desconexión de Spring-boot-starter-websocket

La empresa necesita utilizar una conexión larga de Websocket para la transmisión de datos. Dado que la empresa utiliza la versión Zuul1.0, tiene un soporte débil para el protocolo ws. Intentaremos utilizar spring-boot-starter-websocket más adelante. Hay muchos artículos sobre cómo integrarse, por lo que no entraré en detalles.

La función que implementamos actualmente es poder enviar puntos enterrados a través de la interfaz de llamada de WebSocket. Además, también necesitamos monitorear los eventos dejados por los usuarios para los puntos enterrados para determinar el tiempo de acceso de terminación. El escenario de prueba actual es:

Los primeros 4 puntos activan cualquier operación, el servidor escuchará el evento de salida DISCONNECT. Pero cuando el quinto punto se desconecta directamente, el servidor no puede detectarlo. El problema en este momento es que después de que el cliente se desconecta, el servidor se considera en línea. Si la red no se vuelve a conectar para iniciar sesión, el usuario siempre estará en línea, enterrado. Los puntos siempre se contarán.

En cuanto a por qué ws cree que está en línea después de desconectarse, tal vez se abrió la tubería y no se envió la hora de desconexión debido a la desconexión.

El método más simple que se me ocurre en este momento es la actualización de latidos.

He ordenado mis ideas y sé aproximadamente qué hacer.

Luego miré el código fuente de spring-boot-starter-websocket y descubrí que en realidad proporciona esta funcionalidad.

Hablemos de cómo hacer esto:

Anulamos el método configureMessageBroker en la clase de configuración que implementa DelegatingWebSocketMessageBrokerConfiguration.

La clave es que setTaskScheduler y setHeartbeatValue son responsables de programar y configurar intervalos.

O rellénalas todas o no completa ninguna.

Después de configurar estos parámetros, cuando se inicie el servicio, se activará un hilo HeartbeatTask dedicado a mantener los latidos.

Podemos ver cómo funciona su proceso.

Clase principal del programador de tareas: org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler volverá a llamar al método de inicio después de la inicialización; sin embargo, activará startInternal dependiendo de si TaskScheduler está configurado (correspondiente a la configuración). class setTaskScheduler) para comenzar a programar la tarea, una vez iniciada, elegirá el tiempo de programación según el servidor de matriz de latidos que le haya asignado.

org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler

Detecta latidos, rechaza recibirlos si excede el intervalo y escribe los latidos al cliente con regularidad.

Otro tema que necesita atención es el intervalo de lectura:

Suponiendo que la condición de la red del usuario no es buena y se pierde un latido, entonces, de acuerdo con esta lógica, el último latido del usuario debe Se terminará el tiempo. Establecerá un tiempo de espera de lectura de 3, lo que equivale a 3 oportunidades*.

Este problema ha sido manejado internamente por SessionInfo al crear una sesión:

org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler.SessionInfo#SessionInfoSessionInfo#SessionInfo

Entonces, en este punto es posible que necesites configurar según el período de tiempo que sea aceptable para tu negocio, y no lo olvides también.

También es crucial mantener el intervalo de envío de latidos del cliente lo más consistente posible con el lado del servidor; de lo contrario, puede haber un tiempo de inactividad inexplicable. Si es posible, también es una buena idea agregar registros en estos lugares.

Bueno, espero que esto te ayude si tienes problemas de desconexión.

Si tienes alguna duda, déjame un mensaje y te responderé lo antes posible.