Coherencia final en la alta disponibilidad de ThingWorx
Al ejecutar ThingWorx en modo de clúster, en última instancia, los cambios del modelo se hacen coherente en todo el clúster. Los cambios en el servidor A tardan una pequeña cantidad de tiempo en sincronizarse con los servidores B, C, etc. Un monitor de cambios se ejecuta a una frecuencia configurable (con un valor por defecto de 100 ms) e inspecciona los cambios de entidad. Se descargarán y volverán a cargar las entidades que cambian en ese servidor, suponiendo que la base de datos es la fuente de veracidad. Esta coherencia final solo se aplica a los cambios de modelo y configuración, mientras que el estado es coherente inmediatamente.
• HTTP: HTTP utiliza sesiones que se pueden recordar, de modo que un usuario individual esté vinculado a un único ordenador. De este modo, se garantiza que un usuario ve todos los cambios inmediatamente. Los cambios de otros usuarios en otros servidores serán coherentes.
• WebSocket: cuando se realiza un cambio de modelo a través de un WebSocket, la versión actual del modelo se almacena en la sesión de WebSocket. Las solicitudes de WebSocket siempre son de tipo Round Robin para ayudar con la distribución de la carga. La siguiente solicitud realizada en esa sesión de WebSocket se pausará hasta que el servidor al que está conectado sea como mínimo la versión almacenada en la sesión. Si el servidor no se puede sincronizar en un segundo aproximadamente, se agotará el tiempo de espera.
En los siguientes escenarios se describe un impacto reducido para los usuarios:
• Escenario 1: HTTP
Dispositivo > HAProxy > Platforma1...N
En este escenario, se conecta a la plataforma 1 y se realizan cambios en el modelo. Si, a continuación, se conecta otro usuario a la plataforma 2 y se verifican los cambios, estos se terminarán mostrando. En última instancia, el clúster es coherente con los cambios de modelo mediante un proceso de sincronización. Si se trata del caso de uso del usuario, se debe crear un reintento para esperar a que los cambios estén disponibles.
• Escenario 2: WebSocket
Dispositivo > HAProxy > CXServer1...N = > Plataforma1...N
En este escenario, el dispositivo es de punto a punto con una instancia de Connection Server. Las solicitudes de la plataforma serán de tipo Round Robin. Si el dispositivo realiza un cambio en el modelo y, a continuación, realiza otra solicitud que va a otro servidor, los primeros cambios se realizan allí antes del procesamiento. La solicitud se retrasa hasta que la versión del modelo se sincronice al menos con la versión en la que se ha realizado el cambio. Si no se puede sincronizar en un período de tiempo, se agotará el tiempo de espera de la solicitud. Por lo tanto, este dispositivo puede comunicarse con cualquier servidor y obtendrá la respuesta adecuada.
Si se conecta un segundo dispositivo para que vea los cambios realizados por el primer dispositivo, la coherencia final se aplica también al segundo dispositivo. Solo se garantiza que el sistema esperará cambios en una única conexión.
• Escenario 3: la solicitud HTTP para cambiar el modelo activa una notificación a un dispositivo conectado
Dispositivo > HAProxy > CXServer1...N = > Plataforma1...N
Un usuario realiza un cambio de modelo y se notifica al dispositivo del cambio para que pueda volver a extraer las definiciones. El dispositivo tenía la posibilidad de extraer los datos de un servidor que todavía no ve el cambio. Ahora, la versión del modelo se inyecta en la sesión de WebSocket, de modo que si realiza una solicitud en un servidor con una versión de modelo inferior, esperará a que se sincronice hasta al menos esa versión del modelo antes de devolver resultados. Si no se puede sincronizar en el tiempo, se agota el tiempo de espera de la solicitud.
Por lo tanto, se ha añadido un nuevo valor de postCommitEventQueue. Los eventos añadidos, tales como cambios de propiedad, se activarán después de que se haya confirmado la transacción completa y se conozca la nueva versión del modelo. Cuando se notifica al dispositivo, la versión del modelo se inyecta en la sesión de WebSocket para garantizar que las solicitudes futuras de ese dispositivo esperarán a que el servidor sea coherente con los cambios originales.