2017-02-21 12 views
0

가정 -사용자 상태 응용 프로그램

  1. 부하 분산
  2. 로드 밸런서 역할을하는 리버스 프록시 뒤에 앉아 4 개 서버가 있습니다 순수로드 밸런싱과에 요청을 보냅니다 현재 부하에 따라 4 대의 서버 중 임의의 서버
  3. 역방향 프록시는로드 균형 조정 만하므로이 응용 프로그램에 액세스하려면 사용자가 인증되어야하며 일부 사용자는 모든 사용자의 상태를 유지해야합니다.
  4. 응용 프로그램은 4 이상으로 확장해야합니다. 4000 대의 서버로 구성됩니다.


질문 -로드 밸런서, 각 서버, 별도의 서버 - 모든 사용자의 상태를 유지하는 대규모 다중 서버 시스템에서

  1. ?
  2. 부하 분산 장치가 모든 서버에 요청을 보낼 수 있도록 모든 사용자의 상태가 모든 서버에 저장되어 있습니까? 이것은 100m 사용자에게 어떻게 확장됩니까?

답변

0
  1. 무 상태 다중 서버 시스템에서 , 별도의 서버 (인증 서버) 또는 별도의 서버 클러스터 (인증 API는) 모든 사용자의 상태를 보유하고 읽기. 대형 응용 프로그램을위한 단일 인증 서버 인 경우 RAM의 범위가 GBs 100 개가 넘을 것으로 예상 할 수 있습니다.

  2. 아니요, 모든 사용자의 상태는 일반적으로 모든 응용 프로그램 서버에 복제되지 않습니다. 자원 낭비가 큽니다. 인증 서버 (또는 서버 클러스터)는로드 밸런서 자체로 작동하거나 모든 요청을 별도의로드 밸런서에 전달할 수 있습니다. 은 무응답 애플리케이션에 해당합니다. 상태 기반 응용 프로그램에서


는 개별 서버는 지속적인 세션을 통해 사용자의 상태를 유지.

가능하면 응용 프로그램을 무 상태로 유지하십시오. 상태 비 저장 응용 프로그램은 더 나은 성능을 가지며 상태 저장 응용 프로그램보다 수평 확장이 쉽습니다!

0

고정 세션을 사용할 수 있습니다. 로드 밸런서를 사용하여 사용자의 세션을 특정 인스턴스에 바인드 할 수 있습니다. 이렇게하면 세션 중 사용자의 모든 요청이 동일한 인스턴스로 전송됩니다. Sticky and NON-Sticky sessions을 읽으십시오.

또한 상태를 유지하기 위해 인스턴스가 어떤 이유로 인해 강제 종료되었다고 가정하면 인증 토큰 및 기타 정보를 별도의 redis 캐시에 저장할 수 있으므로 쿼리 속도가 훨씬 빠릅니다. Session Management in microservices