Coerenza finale in ThingWorx a disponibilità elevata
Quando si esegue ThingWorx in modalità cluster, le modifiche al modello vengono uniformate nel cluster. Le modifiche al server A richiedono una quantità di tempo minima per essere sincronizzate con i server B, C e così via. Un osservatore delle modifiche viene eseguito a una frequenza configurabile (con un valore di default di 100 ms) per osservare le modifiche dell'entità. Scaricherà e ricaricherà le entità che cambiano sul server, supponendo che il database sia l'origine di riferimento. Questa coerenza finale si applica solo alle modifiche al modello e alla configurazione, mentre lo stato risulta immediatamente coerente.
• HTTP - HTTP utilizza sessioni memorizzate in modo che un singolo utente sia associato a un singolo computer. Questo garantisce che un utente visualizzi immediatamente tutte le modifiche. Le modifiche apportate da altri utenti su altri server alla fine saranno coerenti.
• WebSocket - Quando una modifica del modello viene effettuata tramite un WebSocket, la versione del modello corrente viene memorizzata nella sessione di WebSocket. Le richieste WebSocket sono sempre round-robin per facilitare la distribuzione del carico. La richiesta successiva effettuata nella sessione di WebSocket verrà sospesa finché il server a cui è connessa non corrisponderà almeno alla versione memorizzata nella sessione. Se il server non è in grado di sincronizzarsi dopo circa un secondo, si verificherà il timeout.
Negli scenari riportati di seguito è descritto un impatto ridotto per gli utenti.
• Scenario 1: HTTP
Dispositivo > HAProxy > Piattaforma1..N
In questo scenario, si effettua la connessione alla piattaforma 1 e si apportano modifiche al modello.Se quindi si connette un utente diverso alla piattaforma 2 e si verificano le modifiche apportate, alla fine queste verranno visualizzate.Il cluster risulterà infine coerente relativamente alle modifiche del modello grazie a un processo di sincronizzazione.Se questo è il caso di utilizzo corrente, è necessario creare un nuovo tentativo per attendere che le modifiche siano disponibili.
• Scenario 2: WebSocket
Dispositivo > HAProxy > Server CX1..N = > Piattaforma1..N
In questo scenario, il dispositivo è punto a punto con un server connessioni.Le richieste della piattaforma effettueranno il round robin.Se il dispositivo apporta una modifica al modello e quindi effettua un'altra richiesta che passa a un altro server, le prime modifiche vengono apportate prima dell'elaborazione.La richiesta viene posticipata fino a quando la versione del modello non viene sincronizzata almeno con la versione in cui è stata apportata la modifica.Se non riesce a eseguire la sincronizzazione in un determinato periodo di tempo, si verificherà il timeout della richiesta. Di conseguenza, questo dispositivo potrà comunicare con qualsiasi server e ottenere la risposta appropriata.
Se si connette un secondo dispositivo per esaminare le modifiche apportate dal primo dispositivo, la coerenza finale verrà applicata anche al secondo dispositivo. L'attesa delle modifiche da parte del sistema è garantita solo in una singola connessione.
• Scenario 3: la richiesta HTTP di modifica del modello attiva una notifica a un dispositivo connesso
Dispositivo > HAProxy > Server CX1..N = > Piattaforma1..N
Un utente apporta una modifica al modello e il dispositivo riceve una notifica della modifica in modo che possa eseguire di nuovo il pull delle definizioni.Il dispositivo aveva la possibilità di eseguire il pull dei dati da un server che non visualizza ancora la modifica. A questo punto, la versione del modello viene inserita nella sessione di WebSocket, in modo che, se invia una richiesta a un server con una versione di modello inferiore, attenderà che questo si sincronizzi almeno alla versione del modello prima di tornare.Se non riesce a eseguire la sincronizzazione in tempo, si verifica il timeout della richiesta.
Di conseguenza, è stato aggiunto un nuovo postCommitEventQueue. Qualsiasi evento aggiunto, ad esempio le modifiche delle proprietà, verrà attivato dopo il commit della transazione completa e quando la nuova versione del modello sarà nota. Quando il dispositivo viene notificato, la versione del modello viene inserita nella sessione di WebSocket per garantire che le richieste future del dispositivo attendano che il server sia coerente con le modifiche originali.