A, Nginx의 장점 :
1, HTTP를 위해 할 수있는 일곱 계층 네트워크의 작품은 지금까지 널리 인기, 같은 더 강력하고 HAProxy보다 유연한 도메인 이름, 디렉토리 구조, 형식적인 규칙과 같은 일부 전환 전략을 적용 할 수 있습니다.
2, 네트워크의 안정성에 Nginx에 의존는 핑 기능을로드 할 이론적으로 수, 매우 작습니다.
3, Nginx의 설치 및 구성 기본적인 에러 로그를 출력 할 수있는 테스트 비교적 용이 비교적 간단하다.
4, 높은 부하 압력을 취할 수 안정 하드웨어 동시성의 양은 일반적으로 수만 배나을 지원하지 않는 경우의 차이점은,로드 크기는 LVS보다 작다.
5 Nginx에이 상태 코드에 따라 이러한 웹 서버 처리로서 서버 장애, 내부의 포트를 통해 검출 될 수는 제한을 반환하고, 다른 노드에 요청을 제출하기 위해 에러를 반환한다.
6,뿐만 아니라 최적의 부하 분산 / 역방향 프록시 소프트웨어는 또한 강력한 웹 응용 프로그램 서버입니다. LNMP는 최근 몇 년 동안, 웹 아키텍처에서 매우 인기가, 안정성도 높은 트래픽 환경에서 매우 좋다.
7, 리버스 프록시 중간로서 사용될 수있다.
8 정적 페이지와 사진은 서버로 사용할 수 있습니다.
9, Nginx에 지역 사회 활동가, 타사 모듈은 인터넷 풍부에 관련 정보가 매우 크다.
Nginx에 기존의 HTTP 요청과 해당 플로우 차트와 :
Nginx의 단점 :
1 만 전자 메일 프로토콜, HTTP, HTTPS를 지원, 더 작은 범위에 적응합니다.
2, 백엔드 서버의 상태 체크를 감지 할 수있는 URL을 지원하지 않습니다, 테스트를 통해 전용 포트를 지원합니다. 예를 들어, 사용자가 파일을 업로드하고, 업로드 과정에서 바로 처리 노드 장애를 업로드, Nginx에 다른 서버의 재 처리에 업로드 잘라 것, 그것이 큰 파일을 업로드 할 경우 LVS 직접 잘라 또는 중요한 문서는, 따라서 사용자는 만족하지 않을 수 있습니다.
두, LVS의 장점 :
1 항 하중, 사용을 위해 분배 네트워크의 4 층에 작동에만 트래픽이 기능은 또한 비교 밸런싱 소프트웨어 부하의 강력한 성능, 메모리 및 CPU 자원 소비를 결정하지 저.
2, 구성하는 많은 아무것도 정말이 없기 때문에 단점도 장점이다 상대적으로 낮은 구성, 그것은 크게 인간의 오류 가능성을 줄이고, 접촉 많이하지 않습니다.
3 때문에 강력한 항 하중 자체의 안정적인 자체 LVS + Keepalived 같은 완전한 이중 중복하지만 여전히 가장 많이 사용되는 실시 LVS / DR + Keepalived 프로젝트이다.
4, 트래픽이, LVS는 요청을 배포 없지만, 자체 밖으로 흐르지 않고,이 이퀄라이저 IO의 성능이 영향의 큰 흐름을 수용하지 않도록하는 것입니다.
그렇게에 HTTP, 데이터베이스, 온라인 채팅 룸을 포함한 거의 모든 응용 프로그램에 대한 부하 분산을 수행 할 수 있도록 응용 프로그램 5. 넓은 범위, 4 개 개의 레이어에 있기 때문에 LVS 작업.
네트워크 흐름도 LVS DR (직접 라우팅) 모드 :
LVS의 단점 :
1, 소프트웨어 자체는 정적 및 동적 분리를 할 수 없어, 정규 표현식 처리를 지원하지 않습니다 지금은이 지역에 많은 사이트가 강한 수요가,이 Nginx에 / HAProxy + Keepalived의 장점은 거짓말이다.
웹 애플리케이션이 비교적 큰 다음, LVS / DR + Keepalived 더 복잡 구현하는 경우 (2), 컴퓨터가 윈도우 서버의 특정 구현 및 구성뿐만 아니라 유지 보수 프로세스가 더 복잡한 경우 단어 뒤에 상대적으로 말하기, Nginx에 / HAProxy + Keepalived 훨씬 쉽습니다.
세, HAProxy 장점 :
1 HAProxy 지원 가상 호스트는 4,7- 층 작동 (멀티 - 네트워크 세그먼트를 지원) 할
지정된 URL을 획득함으로써 검출 지원 백엔드 서버 상태 2, 장점 HAProxy Nginx와 같은 지원 세션 유지, 쿠키를 안내 등 일부 단점을 보완 할 수있다.
3, LVS 자체 단지 부하 밸런싱 소프트웨어와 마찬가지로 HAProxy는, 간단한 HAProxy은 효율 비의 Nginx에서 속도면에서 더 분산 부하를 가질 것이다 동시 처리에 Nginx에 우수하다.
4, HAProxy TCP 프로토콜 전달을로드 밸런싱을 지원,로드 밸런싱이 MySQL을 읽을 수 백 엔드에 MySQL의 노드를 감지하고로드 밸런싱, 당신은 부하 MySQL의 마스터 - 슬레이브의 균형을 할 LVS + Keepalived를 사용할 수 있습니다.
8 개 종류가있다 5, HAProxy로드 밸런싱 전략은 매우, HAProxy 부하 분산 알고리즘은 이제 특정
①의 라운드 로빈
이있는 매끄러운 공정한 알고리즘 서버 처리 시간이 동일한 분포의 경우에는 간단한 폴 차례로 이용되는 가중치에 따라 각 서버를 나타낸다. 인스턴스가 느린 서버 가중치를 시작하기위한 알고리즘은 동적이며, 즉시 다시 조정합니다. 최대 지원 4095 백엔드 호스트;
② leastconn
연결의 최소 수의 서버가 접속 우선 순위를 수신한다. leastconn는 등 LDAP, SQL, TSE, 짧은 세션 프로토콜에 적합하지 않은 한 세션 및 서비스에 대한 권장. 알고리즘은 동적 예 : http. 인스턴스가 느린 서버 가중치를 시작하기위한, 즉시 다시 조정합니다.
③ 정전기 RR
가중치에 따라 각 서버 회전, 유사한 라운드 로빈에서 사용하지만 정적 실행 의미 유효하지 않은 권한이 있습니다 수정합니다. 또한, 해당 서버의 수는 제한되지 않는다. 알고리즘 일반적으로하지 않습니다;
④ 소스
할당 결과에 따라 가능한 서버의 해시 값으로 나눈 무거운 중량의 총 개수와 요청 소스 IP 어드레스 해시. 언제 까지나 정상적인 서버, 클라이언트와 같은 IP 주소는 항상 같은 서버에 액세스합니다. 해시 결과가 가능한 서버의 수에 따라 변화하는 경우, 클라이언트가 다른 서버에 지향 될 것이다 알고리즘은 일반적으로 쿠키 TCP 모드를 삽입하기 위해 사용되지 않는다. 기본 알고리즘은 정적이기 때문에, 서버 가중치를 수정할 수있는 권한이 유효하지 런타임이지만, 알고리즘에 따라 "해시 형"으로 변경됩니다, 또한 가장 효과적인 유착을 제공하기 위해 WAN 세션 쿠키 클라이언트의 사용을 거부 할 수 있습니다 조정을합니다.
⑤ 사이트
해시 값을 서버로 나눈 무거운 중량의 총 개수는 결과에 따라 할당 가능하여 또한, 상기 요청 URI 좌단에 따른 (물음표) 전에 해시를 나타낸다. 한 서버가 정상으로, 같은 주소 URI는 항상 같은 서버에 액세스 할 수 있습니다. 일반적으로 캐시의 히트 율을 최대화하기 위해 프록시 캐싱 및 안티 바이러스 에이전트에 사용됩니다. 기본 알고리즘은 정적이기 때문에 런타임 가중치가 무효 서버를 수정할 수 있지만 알고리즘에 따라 "해시 형"으로 변경됩니다,이 알고리즘은 일반적으로 백엔드 캐시 서버에 사용되며,이 알고리즘은 HTTP 백 엔드에 사용할 수 있습니다 조정을합니다.
⑥ url_param
쿼리 문자열 HTTP 찾기 GET 요청 <PARAM> URL 지정된 매개 변수, 실질적으로 특정 부하 분산 노드의 요구 사항에 특별한 URL을 사용하여 고정 할 수 있으며, 알고리즘은 일반적으로 동일한 사용자에게 동일한 정보를 전송하는 데 사용됩니다 백 엔드 서버, 기본 알고리즘은 정적이기 때문에 런타임 서버 무게가 유효 수정하지만, 알고리즘의 "해시 형"의 변화에 따라 조정됩니다.
⑦ HDR (이름)
헤드가 없거나 전혀 헤더 값이 라운드 로빈 교체되지 않은 경우; 알고리즘 각 HTTP 요청 HTTP 헤더 <이름>, HTTP 헤더 <이름>은 HTTP 요청의 각각에서 본, 특정 노드에 대한 것이다를 검사 기본값은 정적이기 때문에 런타임 가중치가 무효 서버를 수정할 수 있지만 알고리즘의 "해시 형"의 변화에 따라 조정됩니다.
⑧ RDP-쿠키 (이름)
각 수신 쿼리 요청 및 TCP 해시 RDP 쿠키 <이름>의 경우, 영구적으로 저하 모드에 대한 메커니즘, 사용자는 동일하거나 항상 동일한 세션 ID에서 동일한 서버로 전송 할 수 있습니다. 대신 라운드 로빈 알고리즘을 사용하는 어떤 쿠키가없는 경우,이 알고리즘은 기본적으로 정적이기 때문에 무게가 무효 서버 런타임을 수정하지만, 알고리즘의 "해시 형"의 변화에 따라 조정됩니다.
haproxy 작업 모델 다이어그램 :
HAPorxy 단점 :
1. POP / SMTP 프로토콜을 지원하지 않습니다
2. SPDY 프로토콜을 지원하지 않습니다
3. HTTP 캐시 기능을 지원하지 않습니다. 이제 오픈 소스 프로젝트의 파운드의 많은, 더 많거나 적은 HTTP 캐시 기능을 가지고있다.
4. 구성 과부하 기능은 또한 부드러운 재시작을 가지고 있지만, 프로세스를 다시 시작해야하지만, Nginx에없이 부드럽고 친화적 인 reaload.
멀티 프로세스 모드 지원이 충분하지 않습니다
HTTPS : //blog.csdn.net/qlj324513/article/details/81541282이 문서는에 재현