ThingWorx 고가용성 > ThingWorx HA의 최종 일관성
ThingWorx HA의 최종 일관성
클러스터 모드에서 ThingWorx를 실행하면 모델 변경 사항이 최종적으로 클러스터 전체에 일관되게 적용됩니다. 서버 A의 변경 사항을 서버 B, C 등에 동기화하는 데 약간의 시간이 걸립니다. 변경 감시자는 구성 가능한 빈도(기본값: 100밀리초)로 실행되며 엔티티 변경 사항을 감시합니다. 변경 감시자는 데이터베이스가 신뢰할 수 있는 소스라고 가정한 상태에서 해당 서버에서 변경된 엔티티를 언로드하고 다시 로드합니다. 이러한 최종 일관성은 모델 및 구성 변경 사항에만 적용되는 반면 상태는 즉시 일관됩니다.
HTTP - HTTP는 고정 세션을 사용하므로 개별 사용자가 단일 시스템에 연결됩니다. 따라서 사용자가 모든 변경 사항을 즉시 봅니다. 다른 서버에서 다른 사용자가 수행한 변경 사항은 최종적으로 일관됩니다.
WebSocket - 모델 변경이 WebSocket을 통해 수행되는 경우 현재 모델 버전이 WebSocket 세션에 저장됩니다. WebSocket 요청은 부하 분산을 위해 항상 라운드 로빈 방식으로 수행됩니다. 해당 WebSocket 세션에서 수행된 다음 요청은 세션이 연결된 서버가 세션에 저장된 버전 이상이 될 때까지 일시 중지됩니다. 서버가 1~2초 내에 동기화할 수 없으면 제한 시간이 초과됩니다.
다음 시나리오에서는 사용자에 대한 영향이 줄어든 상황에 대해 설명합니다.
시나리오 1: HTTP
장치 > HAProxy > 플랫폼 1..N
이 시나리오에서는 플랫폼 1에 연결하여 모델을 변경합니다.그런 다음 다른 사용자를 플랫폼 2에 연결하고 변경 사항을 확인하면 변경 사항이 최종적으로 표시됩니다.클러스터는 동기화 프로세스를 통해 모델 변경 사항이 적용되어 최종적으로 일관됩니다.이 사용 사례에 해당하는 경우 변경 사항을 사용할 수 있게 될 때까지 다시 시도하는 메커니즘을 포함해야 합니다.
시나리오 2: WebSocket
장치 > HAProxy > CXServer1..N = > 플랫폼 1..N
이 시나리오에서는 장치와 Connection Server가 지점 간 방식으로 연결됩니다.플랫폼 요청은 라운드 로빈 방식으로 수행됩니다.장치에서 모델을 변경한 후 다른 서버로 향하는 다른 요청을 수행할 경우, 요청을 처리하기 전에 첫 번째 변경 사항이 다른 서버에 반영됩니다.변경이 수행된 버전 이상으로 모델 버전이 동기화될 때까지 요청이 지연됩니다.일정 기간 동안 버전을 동기화할 수 없는 경우 요청 제한 시간이 초과됩니다. 따라서 이 장치는 어떤 서버와도 통신하여 적절한 응답을 받을 수 있습니다.
두 번째 장치를 연결하고 첫 번째 장치에서 수행한 변경 사항을 확인하도록 하면 최종적으로 두 번째 장치에 일관성이 적용됩니다. 시스템은 단일 연결을 통한 변경 사항만 기다립니다.
시나리오 3: 모델을 변경하기 위한 HTTP 요청이 연결된 장치로 알림을 트리거합니다.
장치 > HAProxy > CXServer1..N = > 플랫폼 1..N
사용자가 모델을 변경하고 정의를 다시 끌어올 수 있도록 장치가 변경에 대한 알림을 받습니다.장치가 아직 변경 사항을 볼 수 없는 서버에서 데이터를 끌어왔을 수 있습니다. 이제 WebSocket 세션에 모델 버전이 삽입되므로 모델 버전이 더 낮은 서버에서 장치가 요청을 수행할 경우 서버는 결과를 반환하기 전에 해당 모델 버전 이상으로 동기화될 때까지 기다립니다.제때에 동기화할 수 없으면 요청 제한 시간이 초과됩니다.
따라서 새 postCommitEventQueue가 추가되었습니다. 속성 변경과 같은 추가된 이벤트는 전체 트랜잭션이 커밋되고 새 모델 버전이 알려진 후에 발생합니다. 장치에서 알림을 받으면 서버가 원래 변경 사항으로 일관된 상태가 될 때까지 해당 장치로부터의 향후 요청을 기다리도록 하기 위해 WebSocket 세션에 모델 버전이 삽입됩니다.
도움이 되셨나요?