Cohérence éventuelle dans ThingWorx haute disponibilité
Lors de l'exécution de ThingWorx en mode cluster, les modifications apportées aux modèles sont appliquées de manière cohérente à l'ensemble du cluster. La synchronisation sur les serveurs B, C, etc., des modifications apportées sur le serveur A peut prendre un peu de temps. Un observateur de modifications s'exécute selon une fréquence définie (avec une valeur par défaut de 100 ms) et surveille les modifications d'entité. Il déchargera et rechargera les entités modifiées sur ce serveur, tout en supposant que la base de données constitue la source de vérité. Cette cohérence éventuelle ne s'applique qu'aux modifications de modèle et de configuration. La cohérence est immédiate dans le cas des états.
• HTTP : HTTP utilise des sessions permanentes afin qu'un utilisateur individuel soit lié à une seule machine. Cela garantit qu'un utilisateur voit toutes les modifications immédiatement. La cohérence des modifications apportées par d'autres utilisateurs sur d'autres serveurs sera assurée par la suite.
• WebSocket : lorsqu'une modification de modèle est effectuée via un WebSocket, la version actuelle du modèle est stockée dans la session WebSocket. Les requêtes WebSocket sont toujours alternées pour faciliter la distribution de la charge. La requête suivante effectuée sur cette session WebSocket s'interrompt jusqu'à ce que le serveur auquel elle est connectée corresponde au moins à la version enregistrée dans la session. Si le serveur ne parvient pas à se synchroniser en environ une seconde, elle expirera.
Les scénarios suivants décrivent un impact réduit pour les utilisateurs :
• Scénario 1 : HTTP
Appareil > HAProxy > Plateforme 1 à N
Dans ce scénario, vous vous connectez à la plateforme 1 et vous apportez des modifications au modèle. Si vous connectez ensuite un autre utilisateur à la plateforme 2 et que vous vérifiez les modifications, elles finiront par s'afficher. La cohérence éventuelle des modifications de modèle sur le cluster est assurée via un processus de synchronisation. Si cette situation s'applique à vous, vous devez prévoir une nouvelle tentative en attendant que les modifications soient disponibles.
• Scénario 2 : WebSocket
Appareil > HAProxy > Serveur de connexion 1 à N => Plateforme 1 à N
Dans ce scénario, l'appareil utilise une connexion point à point avec un serveur de connexion. Les requêtes de la plateforme sont alternées. Si l'appareil effectue une modification de modèle, puis fait une nouvelle requête vers un autre serveur, les premières modifications sont effectuées avant le traitement. La requête est retardée jusqu'à ce que la version du modèle soit synchronisée avec au moins celle sur laquelle la modification a été apportée. Si la synchronisation est impossible dans un délai donné, la requête expire. Par conséquent, cet appareil peut communiquer avec n'importe quel serveur et obtenir la réponse appropriée.
Si vous connectez un deuxième appareil pour qu'il examine les modifications apportées par le premier appareil, la cohérence éventuelle s'applique également à ce deuxième appareil. Le système attend ainsi des modifications pour une seule connexion.
• Scénario 3 : une requête HTTP de modification de modèle déclenche une notification sur un appareil connecté
Appareil > HAProxy > Serveur de connexion 1 à N => Plateforme 1 à N
Un utilisateur effectue une modification de modèle et une notification est transmise à l'appareil afin qu'il puisse en tirer de nouvelles définitions. L'appareil avait la possibilité d'extraire les données d'un serveur qui ne voit pas encore la modification. La version du modèle est alors injectée dans la session WebSocket, de sorte que si l'appareil envoie une requête auprès d'un serveur disposant d'une version antérieure du modèle, il devra attendre la synchronisation de ce dernier avec au moins cette version. Si la synchronisation est impossible dans un délai donné, la requête expire.
Par conséquent, un nouveau postCommitEventQueue a été ajouté. Tous les événements ajoutés, tels que les modifications de propriété, sont déclenchés après un commit de la transaction complète et dès lors que la nouvelle version du modèle est connue. Lorsque l'appareil est averti, la version du modèle est injectée dans la session WebSocket pour s'assurer que les prochaines requêtes de cet appareil ne soient effectuées qu'après la synchronisation des modifications sur le serveur.