액티브/액티브 스티키 세션을 통한 SignalR 및로드 밸런싱

Question

우리는 SignalR을 사용하여 클라이언트 UI를 업데이트하는 응용 프로그램을 보유하고 있습니다. 현재 우리가 유지 관리하는 IIS에 응용 프로그램이 호스팅되며 클라이언트는 우리에게 직접 연결됩니다.

그러나 우리는이 응용 프로그램을 자체적으로 내부에 보관할 엔터프라이즈 전체 프레임 워크에 통합하는 과정에서 우리는 계속 응용 프로그램을 호스팅 할 것입니다. 그러나 우리 페이지에 방문하는 모든 사람들은 우리가 말한 "지역별 설치 2 개의 게이트웨이 서버의 전략을 끈끈한 세션을 통해 활성/활성으로로드 균형 조정"

내 질문에 우리는 SignalR이 전송 프로토콜로 긴 폴링을 선택하고 어떤 식 으로든 연결을 결정할 때 문제가 발생합니다. 떨어 졌어?

미안하지만로드 밸런싱에 대한 지식이 없습니다.

도움이 많이되었습니다.

Answer 1

"끈적 끈적한"세션을 실제로 사용한다고 가정하면 다음 요청은 끈적 거리기 때문에 같은 기본 서버로 돌아 가야하기 때문에 연결이 끊어지는 것은 중요하지 않습니다. 결국, 끈끈한 세션은 모두 HTTP의 표준 요청/응답 모델을 여러 요청 동안 동일한 서버로 되돌려 놓는 것에 관한 것입니다. 따라서 긴 폴링은 연장 된/스트리밍 응답이있는 표준 요청 일뿐이므로 표준 끈적 세션 구현과 잘 통합되어야합니다.

고려해야 할 사항은 실패 또는 유지 관리로 인해 서버 A가 손실되면 어떻게됩니까? 확장 된 메시지 버스 솔루션 (Redis, Azure SB)을 사용하고 있지 않다면 서버 A에서 서버 B로 전환 할 때 잠재적으로 메시지를 잃어 버리거나 놓칠 수 있습니다.