여러 로드 밸런싱 기술 공유

로드 밸런싱 기술은 중대형 웹 사이트의 성능을 향상시키는 데 큰 이점이 있습니다. 최근 저는 로드 밸런싱 기술에 대해 소개하는 "대형 웹 사이트 기술의 아키텍처"를 공부하고 있습니다. 이 기사에서는 주로 여러 로드 밸런싱 기술을 공유합니다. . 모두에게 도움이 되기를 바랍니다.

[프로토콜 레이어] http 리디렉션 프로토콜은 로드 밸런싱을 구현합니다

원리: 사용자의 http 요청을 기반으로 실제 웹 서버 주소를 계산하고, http 리디렉션 응답에 웹 서버 주소를 적어서 반환합니다. 브라우저에 연결하면 브라우저가 다시 액세스합니다.

그림에 표시된 대로:

장점: 상대적으로 간단함

단점: 브라우저는 한 번의 방문을 완료하기 위해 서버에 대한 요청이 전혀 필요하지 않습니다. 성능 저하.

http 리디렉션 서버 자체의 처리 능력이 병목 현상을 일으킬 수 있습니다.

http302 응답 리디렉션을 사용하면 검색 엔진이 이를 SEO 부정 행위로 판단하여 검색 순위가 낮아질 수 있습니다.

[프로토콜 레이어] DNS 도메인 이름 확인 로드 밸런싱

원칙: DNS 서버의 IP에 해당하는 여러 도메인 이름 레코드를 구성합니다. 예를 들어, 도메인 이름 www.baidu.com은 웹 서버 IP 주소 집합에 해당합니다. 도메인 이름 확인 중에 도메인 이름 요청은 DNS 서버의 알고리즘을 통해 적절한 실제 서버에 할당됩니다.

그림과 같이:

장점: 로드 밸런싱 작업을 DNS로 처리하면 웹 사이트 관리 및 로드 밸런싱 서버 유지 관리의 수고가 줄어듭니다. 동료 DNS 또한 도메인 이름을 사용자의 지리적 위치에 가장 가까운 서버 주소로 확인하는 지리적 위치 기반 도메인 이름 확인을 지원하여 액세스 속도를 높이고 성능을 향상시킵니다.

단점: 현재 DNS 확인은 다단계 확인입니다. DNS의 각 수준은 레코드 A를 캐시할 수 있습니다. Moyi 서버가 오프라인 상태가 되어도 서버에 해당하는 DNS 레코드 A가 여전히 존재할 수 있으므로 서버에 사용자 액세스가 실패했습니다.

DNS 로드 밸런싱에 대한 통제권은 도메인 이름 서비스 제공업체에 있으며, 웹사이트에서는 많은 개선과 관리를 하지 못할 수도 있습니다.

서버의 처리 능력에 따른 부하 분산이 불가능합니다. DNS 로드 밸런싱은 단순한 폴링 알고리즘을 사용하는데, 이는 서버 간의 차이를 구별할 수 없고, 서버의 현재 실행 상태를 반영할 수 없기 때문에 로드 밸런싱 효과가 그리 좋지 않습니다.

추가 네트워크 문제가 발생할 수 있습니다. 이 DNS 서버가 적시에 다른 DNS 서버와 상호 작용할 수 있도록 하려면 DNS 데이터가 적시에 업데이트되고 주소가 무작위로 할당될 수 있도록 하기 위해 DNS 새로 고침 시간은 일반적으로 작은 값으로 설정됩니다. 너무 작으면 DNS 트래픽이 크게 증가하고 추가 네트워크 트래픽 문제가 발생합니다.

[프로토콜 계층] 역방향 프록시 부하 분산

원리: 역방향 프록시는 웹 서버 측에 있습니다. 역방향 프록시 서버는 부하 분산 기능을 제공하고 동시에 웹 서버 그룹을 관리합니다. 로드 밸런싱 알고리즘에 따라 요청된 브라우저 액세스는 다른 웹 서버로 전달되어 처리되며, 처리 결과는 역방향 서버를 통해 브라우저로 반환됩니다.

사진에 표시된 대로:

예: 브라우저가 요청한 주소는 역방향 프록시 서버의 주소 114.100.80.10입니다. 역방향 프록시 서버는 요청을 수신하고 로드 밸런싱 알고리즘 후에 실제 물리적 주소 10.0.03을 얻습니다. 요청 결과는 실제 서버리스 서버로 전송되며, 실제 서버에서 처리된 후 역방향 프록시 서버를 통해 요청한 사용자에게 반환됩니다.

장점: http 프로토콜 수준에서 배포가 간단합니다.

단점: 역방향 프록시 서버를 사용한 후에는 웹 서버 주소가 외부 세계에 직접 노출될 수 없으므로 웹 서버가 외부 IP 주소를 사용할 필요가 없으며, 통신 브릿지로서 역방향 프록시 서비스가 필요합니다. 듀얼 네트워크 카드와 두 개의 외부 및 내부 IP 주소 세트로 구성됩니다.

[네트워크 계층] IP 부하 분산

원리: 부하 분산은 대상 주소를 수정하여 네트워크 계층에서 수행됩니다.

그림에 표시된 대로:

알고리즘에 따라 운영 체제 커널 프로세스를 얻습니다. 사용자가 요청한 대상 주소를 실제 서버 주소로 수정합니다. 데이터 처리가 완료된 후 로드 밸런싱 서버로 응답을 받은 후 자신의 주소를 수정합니다. 원래 사용자 액세스 주소에 대해 이야기해 보겠습니다. 역방향 서버 로드 밸런싱과 유사합니다.

장점: 요청에 응답할 때 역방향 서버 로드 밸런싱보다 빠릅니다.

단점: 대용량 데이터(대용량 동영상, 파일) 요청시 속도가 느립니다.

[링크 계층] 데이터링크 계층 로드 밸런싱

원칙: 로드 밸런싱을 위해 데이터링크 계층에서 Mac 주소를 수정합니다.

그림과 같습니다.

로드 밸런싱 서버의 IP는 해당 서버가 관리하는 웹 서비스 그룹의 가상 IP와 일치합니다.

로드; 밸런싱 데이터는 배포 과정에서 수정되지 않습니다. 주소의 IP 주소에 액세스하지만 Mac 주소를 수정합니다.

이 두 지점을 통해 데이터 패킷의 원래 주소와 대상 주소를 수정하지 않고도 정상적인 액세스가 가능합니다. .

장점: 주소 변환에 로드 밸런싱 서버가 필요하지 않습니다. ㅋㅋ                                                          데이터 응답은 로드 밸런싱 서버를 통과할 필요가 없습니다.

단점: 로드 밸런싱 서버의 네트워크 카드 대역폭이 상대적으로 높습니다.

현재는 특히 균등거리 로드 밸런싱이 많이 사용되는 방식이 대표적인 제품이 LVS(Linux Virtual Server)입니다.

관련 권장 사항:

Nginx가 로드 밸런싱을 달성하는 여러 가지 방법

위 내용은 여러 로드 밸런싱 기술 공유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!