ThingWorx HA 中的最終一致性
在叢集模式下執行 ThingWorx 時，模型變更最終會在整個叢集中保持一致。伺服器 A 上的變更會花費少量時間來同步至伺服器 B、C 等。變更監測器會以可供配置的頻率 (預設為 100 ms) 執行，並監測實體變更。在假設資料庫是事實來源的情況下，它會卸載並重新載入在該伺服器上變更的實體。這種最終一致性僅適用於模型與組態變更，而狀態會保持即時一致性。
• HTTP - HTTP 會使用黏性工作階段，讓個別使用者始終連線至單一電腦。如此可確保使用者能夠立即看到所有變更。其他伺服器上其他使用者的變更最終會保持一致。
• WebSocket - 當透過 WebSocket 進行模型變更時，目前的模型版本會儲存在 WebSocket 工作階段中。WebSocket 請求一律會循環配置資源，以協助進行負載分配。在該 WebSocket 工作階段上進行的下一個請求將會暫停，直到它所連線的伺服器至少為工作階段中儲存的版本為止。如果伺服器無法在一秒左右的時間內同步，則會逾時。
下列情境說明對使用者的影響已經減少的情況：
• 情境 1：HTTP
裝置 > HAProxy > Platform1..N
在此情境中，您將連線至平台 1 並進行模型變更。如果您接下來將不同的使用者連線至平台 2 並檢查變更，它們最終會顯示出來。對於使用同步流程的模型變更而言，叢集最終會保持一致。如果這是您的使用案例，您應該進行重試以等待變更可用。
• 情境 2：WebSocket
裝置 > HAProxy > CXServer1..N => Platform1..N
在此情境中，裝置與 Connection Server 之間以點對點的方式通訊。平台請求將會循環配置資源。如果裝置進行模型變更，然後提出轉至其他伺服器的請求，則在處理之前會先進行前幾個變更。請求會延遲，直到模型版本至少同步至進行變更的版本為止。如果在一段時間內無法同步，請求將會逾時。因此，此裝置可以與任何伺服器通訊，並會取得適當的回應。
如果您連線第二個裝置讓其查看第一個裝置所做的變更，則最終一致性也會套用至第二個裝置。系統只會保證等待跨單一連線的變更。
• 情境 3：用來變更模型的 HTTP 請求觸發對已連線裝置的通知
裝置 > HAProxy > CXServer1..N => Platform1..N
使用者會進行模型變更，並通知裝置發生變更，使其可以重新提取定義。裝置可能會從尚未看到變更的伺服器中提取資料。現在，模型版本會插入到 WebSocket 工作階段中，因此如果它在具有較低模型版本的伺服器上請求，則會等待其至少同步至該模型版本，然後再傳回。如果它無法及時同步，則會使請求逾時。
因此，新增了一個新的 postCommitEventQueue。任何新增的事件 (例如內容變更) 都會在完整交易提交且已知新模型版本之後觸發。當通知裝置時，會將模型版本插入到 WebSocket 工作階段中，以確保該裝置的未來請求將等待伺服器與原始變更保持一致。