Конечная согласованность в ThingWorx HA
При выполнении ThingWorx в кластерном режиме изменения модели в конечном итоге становятся согласованными во всем кластере. Изменениям на сервере A требуется небольшое количество времени для синхронизации с серверами B, C и т. д. Наблюдатель изменений запускается с конфигурируемой частотой (значение по умолчанию: 100 мс) и наблюдает за изменениями сущностей. Он выгружает и перезагружает сущности, которые изменяются на этом сервере, при условии, что база данных является источником истины. Эта конечная согласованность применяется только к изменениям модели и конфигурации, в то время как состояние становится согласованным немедленно.
• HTTP - HTTP использует закрепленные сессии, чтобы отдельный пользователь был связан с одним компьютером. Это гарантирует, что пользователь сразу видит все изменения. Изменения, внесенные другими пользователями на других серверах, рано или поздно станут согласованными.
• WebSocket - когда изменение модели осуществляется через WebSocket, текущая версия модели сохраняется в сессии WebSocket. Запросы WebSocket всегда выполняются с циклическим перебором, чтобы обеспечивать распределение нагрузки. Следующий запрос, сделанный в этой сессии WebSocket, будет приостановлен до тех пор, пока сервер, к которому он подключен, не будет иметь по крайней мере версию, сохраненную в сессии. Если сервер не сможет синхронизироваться в течение секунды или около того, на нем будет иметь место тайм-аут.
Снижение влияния на пользователей описано в следующих сценариях:
• Сценарий 1. HTTP
Устройство > HAProxy > Платформа 1...N
В этом сценарии пользователь подключается к платформе 1 и вносит изменения в модель.Если затем подключить другого пользователя к платформе 2 и проверить наличие изменений, они будут рано или поздно показаны.Кластер в итоге становится согласованным с изменениями модели с помощью процесса синхронизации.Если это ваш вариант использования, необходимо встроить повторение попытки, чтобы ожидать, когда изменения станут доступными.
• Сценарий 2. WebSocket
Устройство > HAProxy > CXServer1...N = > Платформа1...N
В этом сценарии устройство имеет прямое соединение с сервером соединений.Запросы платформы будут выполняться с циклически перебором.Если устройство вносит изменения в модель, а затем выполняет еще один запрос, поступающий на другой сервер, то первые изменения находятся там перед обработкой.Запрос задерживается до тех пор, пока версия модели не будет синхронизирована по крайней мере с версией, в которой было сделано изменение.Если она не может синхронизироваться за определенный период времени, имеет место тайм-аут запроса. Таким образом, это устройство может обращаться к любому серверу и будет получать правильный ответ.
При соединении второго устройства для просмотра изменений, сделанных первым устройством, итоговая согласованность применяется также и ко второму устройству. Система гарантированно ожидает только изменения в одном соединении.
• Сценарий 3. Запрос HTTP на изменение модели инициирует уведомление подключенному устройству.
Устройство > HAProxy > CXServer1...N = > Платформа1...N
Пользователь вносит изменения в модель, и устройство получает уведомление об изменении, чтобы оно могло заново получать определения.Устройство имело возможность получать данные с сервера, который еще не видел изменения. Теперь версия модели будет вноситься в сессию WebSocket, поэтому, если запрашивается сервер с более ранней версией модели, она будет ожидать синхронизации по крайней мере до возвращения версии модели.Если невозможно выполнить синхронизацию вовремя, имеет место тайм-аут запроса.
Поэтому добавляется новая очередь postCommitEventQueue. Любые добавленные события, такие как изменения свойств, будут инициироваться после полной фиксации транзакции и известной версии новой модели. При уведомлении устройства версия модели вносится в сессию WebSocket, чтобы гарантировать, что будущие запросы с этого устройства будут ожидать согласования сервера с исходными изменениями.