Конечная согласованность в ThingWorx HA
При выполнении ThingWorx в кластерном режиме изменения модели в конечном итоге становятся согласованными во всем кластере. Изменениям на сервере A требуется некоторое время для синхронизации с серверами B, C и т. д. Чтобы синхронизировать изменения, они регистрируются в поддерживаемом sync_log поставщике хранилища моделей ThingWorx. Каждый сервер в кластере выполняет сервис наблюдения изменений с настраиваемой частотой (значение по умолчанию: 100 мс) и наблюдает за изменениями сущностей в sync_log. Наблюдатель за изменениями выгружает и перезагружает сущности, которые изменяются на этом сервере, при условии, что база данных является источником истины. Эта конечная согласованность применяется только к изменениям модели и конфигурации, в то время как состояние становится согласованным немедленно.
• 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, чтобы гарантировать, что будущие запросы с этого устройства будут ожидать согласования сервера с исходными изменениями.
Очистка sync_log
По мере внесения изменений в модель вещи sync_log будет постоянно расти, пока старые записи не будут очищаться. После внесения изменений в модель можно очистить связанные записи в sync_log, что позволяет уменьшить размер и повысить производительность и стабильность кластера sync_log.
Очистка Sync_log настраивается в подсистеме кластеризации на вкладке Конфигурация. Чтобы включить автоматическую очистку, сконфигурируйте расписание очистки и сконфигурируйте размер пакета.
|
Настройка
|
По умолчанию
|
Описание
|
|
Enable
|
True (включено)
|
Эта настройка включает или отключает автоматическую очистку.
|
|
Schedule
|
0 30 0 * * ?
|
Таким образом задается расписание очистки sync_log.
|
|
Batch size for purge
|
10000
|
Показывает число записей, которые должны быть удалены из sync_log, начиная с самой старой.
|