과거에는 대규모 웹 애플리케이션을 실행한다는 것은 대규모 웹 서버를 실행한다는 의미였습니다. 귀하의 응용 프로그램이 많은 수의 사용자를 끌어들이기 때문에 서버에 더 많은 메모리와 프로세서를 추가해야 합니다. 오늘날 "대형 서버" 모델은 사라지고 다양한 로드 밸런싱 기술을 사용하는 다수의 소형 서버로 대체되었습니다.
과거 '대형 서버' 모델에 비해 '더 작은 서버'의 장점은 두 가지 측면에서 반영됩니다.
1. 서버가 다운되면 로드 밸런싱 시스템은 다운된 서버에 대한 요청을 중지하고 대신 정상적으로 실행 중인 다른 서버에 로드를 분산시킵니다.
2. 서버 확장이 더 쉬워졌습니다. 여러분이 해야 할 일은 로드 밸런싱 시스템에 새 서버를 추가하는 것뿐입니다. 애플리케이션을 중단할 필요가 없습니다.
그러니 이번 기회를 놓치지 마세요. 물론, 이를 위해서는 애플리케이션 개발이 좀 더 복잡해져야 한다는 단점이 있습니다. 이것이 바로 이 기사에서 다룰 내용입니다.
이 시점에서 "하지만 내가 로드 밸런싱을 사용하고 있는지 어떻게 알 수 있지?"라고 자문할 수도 있습니다. 이 질문에 대한 가장 솔직한 대답은 아마도 로드 밸런싱 시스템을 사용하고 있지 않으며 시스템에서 이를 고려할 필요가 없다는 것입니다. 대부분의 경우 애플리케이션이 충분히 커지면 로드 밸런싱을 명시적으로 제안하고 설정해야 합니다. 그러나 웹 호스팅 회사가 고객 애플리케이션에 대해 이러한 로드 밸런싱을 수행하거나 아래 설명된 대로 자체적으로 수행하는 경우가 가끔 있습니다.
웹사이트 대신 "웹 애플리케이션"을 계속 언급한다는 점에 유의하세요. 이는 단순한 정적 정보만 표시하는 웹사이트가 아니라 종종 서버측 프로그래밍 및 데이터베이스를 포함하는 복잡한 사이트와 "웹 애플리케이션"을 구별하기 위한 것입니다. 콘텐츠.
1. PHP 파일
첫 번째 질문은 소규모 서버가 많은 경우 어떻게 PHP 파일을 모든 서버에 업로드합니까? 참고 방법:
◆ 모든 파일을 각 서버에 개별적으로 업로드합니다. 이 방법의 문제점은 서버가 20개 있다고 가정하면 업로드 프로세스가 매우 쉬울 것이라는 점입니다. 오류가 발생하고, 업데이트할 때 서로 다른 서버에 서로 다른 버전의 파일이 생성될 가능성이 높습니다.
◆'rsync'(또는 유사한 소프트웨어)를 사용하세요. 이러한 도구는 로컬 디렉터리와 여러 원격 호스트 디렉터리의 파일을 동기화할 수 있습니다.
◆버전 관리 소프트웨어(예: Subversion)를 사용하는 것이 제가 가장 좋아하는 방법입니다. 이를 통해 코드를 매우 잘 유지할 수 있으며, 애플리케이션을 게시할 때 각 서버에서 svn update 명령을 실행하여 동기화할 수 있습니다. 또한 이 접근 방식을 사용하면 서버를 이전 버전의 코드로 전환하는 것이 더 쉬워집니다.
◆파일 서버를 사용하세요(NFS가 이에 매우 적합할 수도 있습니다). 이 방법은 파일 서버를 사용하여 웹 애플리케이션을 저장하는 것입니다. 그만큼 모든 사이트를 사용할 수 없게 됩니다. 이때 복원하려면 더 많은 비용을 지출해야 합니다.
어떤 방법을 선택하는지는 귀하의 요구 사항과 귀하가 보유한 기술에 따라 다릅니다. 버전 제어 시스템을 사용하는 경우 업데이트 명령을 동시에 실행하여 모든 서버의 코드를 업데이트하는 방법을 계획할 수 있습니다. 그러나 파일 서버를 사용하는 경우 서버가 다운되는 경우 요청 실패를 방지하기 위해 일부 오류 복구 메커니즘을 구현해야 합니다.
2.파일 업로드
서버가 하나만 있는 경우에는 파일 업로드에 문제가 없습니다. 하지만 서버가 여러 개인 경우 업로드된 파일을 어떻게 저장해야 합니까? 파일 업로드 문제는 서버 간 PHP 파일 저장과 유사합니다. 다음은 몇 가지 가능한 해결 방법입니다.
◆ 파일을 데이터베이스에 저장합니다. 대부분의 데이터는 이진 데이터를 저장할 수 있습니다. 파일 다운로드를 요청하면 액세스 데이터는 바이너리 데이터와 해당 파일 이름 및 유형을 사용자에게 출력합니다. 이 솔루션을 사용하기 전에 데이터베이스가 파일을 저장하는 방법을 고려해야 합니다. 이 접근 방식의 문제점은 데이터베이스 서버가 다운되면 파일을 사용할 수 없게 된다는 것입니다.
◆업로드한 파일을 파일서버에 저장 앞선 소개와 마찬가지로 모든 웹서버에서 공유할 파일서버를 설치하고 업로드한 모든 파일을 여기에 업로드해야 합니다. 서버는 그것을 사용할 수 있습니다. 단, 파일 서버가 다운되면 이미지 파일 다운로드가 중단될 수 있습니다.
◆파일을 각 서버로 전송하는 업로드 메커니즘을 직접 디자인하세요. 이 방법은 단일 파일 서버나 데이터베이스 솔루션의 단점은 없지만 코드가 더 복잡해집니다. 예를 들어, 여러 서버에 업로드하는 동안 서버가 다운되면 어떻게 처리합니까? 데이터베이스를 사용하여 업로드된 파일을 저장하지만 파일 캐싱 메커니즘을 설계하는 것이 좋은 솔루션입니다. 서버는 파일 다운로드 요청을 받으면 먼저 해당 파일이 캐시 시스템에 있는지 확인하고, 발견되면 캐시 시스템에서 해당 파일을 다운로드하여 파일 시스템에 캐시합니다.
3. 세션
PHP의 세션 처리에 익숙하신 분이라면 기본적으로 세션 데이터를 서버의 임시 파일에 저장한다는 사실을 아실 것입니다. 또한 이 파일은 요청한 서버에만 있지만 후속 요청은 다른 서버에서 처리될 수 있으며 이로 인해 다른 서버에서 새 세션이 생성됩니다. 이로 인해 로그인한 사용자에게 항상 다시 로그인하라는 메시지가 표시되는 등 세션이 자주 인식되지 않습니다.
제가 권장하는 솔루션은 PHP에 내장된 세션 처리 메커니즘을 재사용하여 세션 데이터를 데이터베이스에 저장하거나 자체 메커니즘을 구현하여 사용자의 요청이 동일한 서버로 전송되도록 하는 것입니다.
4. 구성
이 주제는 특별히 PHP와 관련이 없지만 언급할 필요가 있다고 생각합니다. 클러스터된 서버를 실행할 때 서버 간에 구성 파일을 동기화 상태로 유지하는 방법을 갖는 것이 좋습니다. 구성 파일이 일관되지 않으면 문제 해결이 어려울 수 있는 매우 이상하고 간헐적인 동작이 발생할 수 있습니다.
개별적으로 관리하려면 버전 관리 시스템을 사용하는 것이 좋습니다. 이렇게 하면 다양한 프로젝트 설치에 대해 다양한 PHP 구성 파일을 저장할 수 있고 모든 서버 구성 파일을 동기화 상태로 유지할 수도 있습니다.
5. 로깅
구성 문제와 마찬가지로 로깅도 PHP에만 관련된 것은 아닙니다. 하지만 서버를 건강하게 유지하는 것은 여전히 매우 중요합니다. 적절한 로깅 시스템이 없으면 PHP 코드에서 오류가 발생하기 시작하는지 어떻게 알 수 있습니까? (시스템이 공식적으로 실행될 때 항상 display_errors 설정을 끄지 않습니까?)
로깅을 구현할 수 있는 몇 가지 방법이 있습니다:
1. 서버의 모든 로깅에서. 이것이 가장 쉬운 방법입니다. 각 시스템은 하나의 파일만 기록합니다. 장점은 간단하고 구성이 거의 필요하지 않다는 것입니다. 그러나 서버 수가 증가함에 따라 각 서버의 로그 파일을 모니터링하는 것이 매우 어려워집니다.
2. 공유에 로그인 이 방법은 여전히 각 서버에 로그 파일을 가지고 있지만 공유 메커니즘을 통해 중앙 파일 서버에 저장되므로 로그를 더 쉽게 모니터링할 수 있습니다. 이 솔루션의 문제점은 파일 서버를 사용할 수 없는 경우 간단한 로그 쓰기 문제로 인해 결국 전체 애플리케이션이 중단된다는 것입니다.
3. 로그를 로깅 서버에 기록합니다. syslog와 같은 로깅 소프트웨어를 사용하여 모든 로그를 중앙 서버에 기록할 수 있습니다. 이 방법에는 더 많은 구성이 필요하지만 가장 강력한 솔루션도 제공합니다.
위 내용은 PHP를 사용한 로드 밸런싱 가이드의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!