로드 밸런싱의 기본 아이디어는 간단합니다. 서버 클러스터에서 로드를 최대한 평균화하는 것입니다. 이 아이디어를 바탕으로 우리의 일반적인 접근 방식은 서버 프런트 엔드에 로드 밸런서를 설정하는 것입니다. 로드 밸런서의 역할은 요청된 연결을 가장 유휴 상태인 사용 가능한 서버로 라우팅하는 것입니다.
그림 1은 대규모 웹사이트 로드 밸런싱 설정을 보여줍니다. 하나는 HTTP 트래픽을 담당하고 다른 하나는 MySQL 액세스를 담당합니다.
로드 밸런싱에는 다섯 가지 공통 목적이 있습니다.
직접 연결 및 미들웨어 도입 .
관련 튜토리얼: 1 직접 연결어떤 사람들은 로드 밸런싱이 다음으로 구성되어 있다고 생각합니다. 애플리케이션과 MySQL 서버를 직접 연결하지만 실제로 이것이 유일한 로드 밸런싱 방법은 아닙니다. 다음으로 일반적인 애플리케이션 직접 연결 방법 및 관련 주의 사항에 대해 설명합니다. 1.1 복제된 읽기-쓰기 분리이 방법에서는 가장 큰 문제 중 하나가 발생하기 쉽습니다:더티 데이터. 일반적인 예는 사용자가 블로그 게시물에 댓글을 달고 페이지를 다시 로드했지만 새 댓글이 표시되지 않는 경우입니다.
물론 더티 데이터 문제 때문에 읽기-쓰기 분리를 버릴 수는 없습니다. 실제로 많은 애플리케이션의 경우 더티 데이터에 대한 허용치가 상대적으로 높을 수 있으며, 이 방법은 이번에 과감하게 도입될 수 있습니다. 그러면 더티 데이터에 대한 내성이 낮은 애플리케이션의 경우 읽기와 쓰기를 어떻게 분리해야 할까요? 다음에는 읽기와 쓰기 분리를 더욱 차별화해보겠습니다. 언제든지 자신에게 맞는 전략을 찾을 수 있을 거라 믿습니다.1) 쿼리 분리 기반
애플리케이션에 더티 데이터를 허용할 수 없는 소수의 데이터만 있는 경우 모든 항목을 결합할 수 있습니다. 더티 데이터를 허용할 수 없는 읽기 모든 쓰기는 마스터에 할당됩니다. 다른 읽기 쿼리는 슬레이브에 할당됩니다. 이 전략은 구현하기 쉽지만 더티 데이터를 허용하는 쿼리가 거의 없으면 대기 데이터베이스를 효과적으로 사용하지 못할 가능성이 높습니다.2) 더티 데이터 기반 분리
이것은 쿼리 기반 분리 전략이 약간 개선된 것입니다. 대기 데이터가 최신인지 확인하기 위해 애플리케이션에서 복제 대기 시간을 확인하는 등 일부 추가 작업이 필요합니다. 많은 보고 애플리케이션이 이 전략을 사용할 수 있습니다. 즉, 밤에 로드된 데이터를 대기 데이터베이스 인터페이스에 복사하기만 하면 되며 기본 데이터베이스를 완전히 따라잡았는지 여부는 신경 쓰지 않습니다.3) 세션 분리 기반
이 전략은 더티 데이터 분리 전략보다 더 깊습니다. 사용자가 데이터를 수정했는지 여부를 확인합니다. 사용자는 다른 사용자의 최신 데이터를 볼 필요가 없으며 자신의 업데이트만 볼 수 있습니다. 특히, 사용자가 업데이트를 했는지 여부를 나타내기 위해 세션 레이어에 플래그 비트를 설정할 수 있습니다. 일단 사용자가 업데이트를 하면 사용자의 쿼리는 일정 기간 동안 기본 데이터베이스로 전달됩니다. 시간의. 이 전략은 단순성과 효율성 사이의 적절한 절충안으로 더욱 권장되는 전략입니다. 물론 아이디어가 충분하다면 세션 기반 분리 전략과 복제 지연 모니터링 전략을 결합할 수도 있습니다. 사용자가 10초 전에 데이터를 업데이트했고, 대기 데이터베이스의 지연이 모두 5초 이내인 경우, 대기 데이터베이스에서 데이터를 대담하게 읽을 수 있습니다. 전체 세션에 대해 동일한 대기 데이터베이스를 선택해야 한다는 점에 유의해야 합니다. 그렇지 않으면 여러 대기 데이터베이스의 지연이 일관되지 않으면 사용자에게 문제가 발생할 수 있습니다.4) 글로벌 버전/세션 분리 기준
메인 데이터베이스 로그 좌표를 기록하고 복사된 좌표를 비교하여 대기 데이터베이스를 확인합니다. 대기 데이터베이스 데이터 업데이트 여부. 애플리케이션이 쓰기 작업을 지시하면 트랜잭션을 커밋한 후 SHOW MASTER STATUS 작업을 수행한 다음 마스터 로그 좌표를 수정된 개체 또는 세션의 버전 번호로 캐시에 저장합니다. 애플리케이션이 대기 데이터베이스에 연결되면 SHOW SLAVE STATUS를 실행하고 대기 데이터베이스의 좌표를 캐시의 버전 번호와 비교합니다. 대기 데이터베이스가 기본 데이터베이스 기록 지점보다 최신인 경우 대기 데이터베이스가 해당 데이터를 업데이트했으며 안심하고 사용할 수 있음을 의미합니다.실제로 많은 읽기-쓰기 분할 전략에서는 읽기 쿼리 할당을 결정하기 위해 복제 지연 시간 모니터링이 필요합니다. 그러나 SHOW SLAVE STATUS로 얻은 Seconds_behind_master 컬럼의 값은 지연을 정확하게 나타내지 않는다는 점에 유의해야 합니다. Percona Toolkit의 pt-heartbeat 도구를 사용하여 대기 시간을 더 잘 모니터링할 수 있습니다.
일부 간단한 애플리케이션의 경우 다양한 목적으로 DNS를 생성할 수 있습니다. 가장 간단한 방법은 읽기 전용 서버(read.mysql-db.com)에 대한 DNS 이름 하나와 쓰기 작업을 담당하는 서버(write.mysql-db.com)에 대한 다른 DNS 이름을 갖는 것입니다. 대기 데이터베이스가 기본 데이터베이스를 따라갈 수 있는 경우 읽기 전용 DNS 이름이 대기 데이터베이스를 가리키고, 그렇지 않으면 기본 데이터베이스를 가리킵니다.
이 전략은 구현하기가 매우 쉽지만 DNS를 완전히 제어할 수 없다는 큰 문제가 있습니다.
이 전략은 더 위험합니다. /etc/hosts 파일을 수정하여 DNS를 완전히 제어할 수 없는 문제를 피할 수 있더라도 여전히 이상적인 전략입니다.
서버 간에 가상 주소를 전송하여 로드 밸런싱을 달성하세요. DNS를 수정하는 것과 비슷한 느낌인가요? 그러나 실제로는 완전히 다른 것입니다. IP 주소를 전송하면 DNS 이름이 변경되지 않은 상태로 유지됩니다. ARP 명령을 통해 IP 주소 변경이 로컬 네트워크에 신속하고 자동으로 통보되도록 할 수 있습니다(ARP에 대해서는 여기 참조).
보다 편리한 기술은 각 물리적 서버에 고정 IP 주소를 할당하는 것입니다. 이 IP 주소는 서버에 고정되어 변경되지 않습니다. 그런 다음 각 논리적 "서비스"(컨테이너로 이해될 수 있음)에 대해 가상 IP 주소를 사용할 수 있습니다.
이렇게 하면 애플리케이션을 재구성하지 않고도 서버 간에 IP를 쉽게 전송할 수 있고 구현도 더 쉬워집니다.
위 전략에서는 애플리케이션이 MySQL 서버에 연결되어 있다고 가정하지만 많은 로드 밸런싱에서는 네트워크 통신을 위한 프록시로 미들웨어를 도입합니다. 한쪽에서는 모든 통신을 수락하고 이러한 요청을 다른 쪽의 지정된 서버에 배포한 다음 실행 결과를 요청하는 시스템으로 다시 보냅니다. 그림 2는 이 아키텍처를 보여줍니다. 
로드 밸런싱 하드웨어와 소프트웨어는 많지만 MySQL 서버용으로 특별히 설계된 것은 거의 없습니다. 웹 서버는 일반적으로 로드 밸런싱에 대한 필요성이 더 크므로 많은 범용 로드 밸런싱 장치는 HTTP를 지원하고 다른 용도로 사용할 수 있는 몇 가지 기본 기능만 갖습니다.
MySQL 연결은 일반적인 TCP/IP 연결이므로 MySQL에서 다목적 로드 밸런서를 사용할 수 있습니다. 그러나 MySQL 관련 기능이 부족하기 때문에 몇 가지 제한 사항이 있습니다.
다음 연결을 수락하는 서버를 결정하는 데 사용되는 많은 알고리즘이 있습니다. 각 제조업체마다 고유한 알고리즘이 있으며 다음과 같은 일반적인 방법이 있습니다:
위의 방법 중 가장 좋은 방법은 없으며 특정 작업 부하에 따라 가장 적합한 방법만 있습니다.
또한 즉시 처리를 위한 알고리즘만 설명합니다. 그러나 때로는 대기열 알고리즘을 사용하는 것이 더 효율적일 수도 있습니다. 예를 들어, 알고리즘은 주어진 데이터베이스 서버 동시성을 유지하여 한 번에 N개 이하의 활성 트랜잭션을 허용할 수 있습니다. 활성 트랜잭션이 너무 많으면 새 요청을 대기열에 넣고 사용 가능한 서버 목록이 이를 처리하도록 합니다.
가장 일반적인 복제 구조는 하나의 마스터 데이터베이스와 여러 백업 데이터베이스입니다. 이 아키텍처는 확장성이 좋지 않지만 몇 가지 방법을 통해 로드 밸런싱과 결합하여 더 나은 결과를 얻을 수 있습니다.
애플리케이션 초기에 알리바바 같은 아키텍처를 만들 생각은 할 수도 없고 해서도 안 됩니다. 가장 좋은 방법은 현재 애플리케이션에 분명히 필요한 것을 구현하고 빠른 성장을 위해 미리 계획을 세우는 것입니다 .
또한 성능에 대한 정확한 목표가 있는 것처럼 10K 또는 100K 동시성을 충족하는 것과 마찬가지로 확장성을 위해 숫자 목표를 갖는 것이 합리적입니다. 이를 통해 관련 이론을 통해 애플리케이션에 직렬화 또는 상호 운용성과 같은 오버헤드 문제가 발생하는 것을 방지할 수 있습니다.
MySQL 확장 전략 측면에서 일반적인 애플리케이션이 매우 큰 크기로 성장하면 일반적으로 먼저 단일 서버에서 대기 데이터베이스가 있는 확장 아키텍처로 이동한 다음 데이터 샤딩 또는 기능별 파티션. 여기서 우리는 "가능한 한 빨리 샤딩, 최대한 많이 샤딩"과 같은 조언을 옹호하지 않는다는 점에 유의해야 합니다. 실제로 샤딩은 복잡하고 비용이 많이 들며, 가장 중요한 것은 많은 애플리케이션에 샤딩이 전혀 필요하지 않을 수 있다는 것입니다. 샤딩에 많은 돈을 쓰기보다는 새로운 하드웨어와 새로운 MySQL 버전의 변화를 살펴보는 것이 더 좋습니다. 아마도 이러한 새로운 변화가 당신을 놀라게 할 것입니다.
은 확장성을 나타내는 정량적 지표입니다.
마지막으로, 이 글이 여러분에게 도움이 되기를 바랍니다.
위 내용은 MySQL은 로드 밸런싱을 간단한 용어로 설명합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
