mysql 대규모 웹사이트 기술 아키텍처의 핵심 원칙은 무엇입니까?-MySQL 튜토리얼-php.cn

1. 대규모 웹사이트 아키텍처의 진화

A. 대규모 웹사이트 소프트웨어 시스템의 특징

높은 동시성, 높은 가용성, 대규모 데이터; 환경, 요구사항의 급격한 변화, 점진적인 개발

B. 대규모 웹사이트 아키텍처의 진화 및 개발 프로세스

1. 애플리케이션 서비스와 데이터의 분리 서비스: 애플리케이션 서버(CPU); 데이터베이스 서버(빠른 디스크 검색 및 데이터 캐싱)

3. 캐시를 사용하여 웹사이트 성능 향상: 애플리케이션 서버에 캐시 로컬 캐시(빠른 액세스 속도) 응용 프로그램 서버 메모리 제한, 데이터 양 제한), 원격 분산 캐시(클러스터를 사용하여 대용량 메모리 서버를 전용 캐시 서버로 배포)

4. 응용 프로그램 서버 클러스터: 로드 밸런싱을 통해 예약

5. 쓰기 분리

6. 역방향 프록시 및 CDN 가속 사용 : CDN(가장 가까운 네트워크 전산실에 구축), 역방향 프록시(중앙 전산실에 구축)

7.분산 파일 시스템 및 분산 데이터베이스 시스템 사용

8. NoSQL 및 검색 엔진 사용

9. 분산 서비스

C. 대규모 웹 사이트 아키텍처의 진화에 대한 가치

1. 웹사이트의 요구에 유연하게 대응하는 것2. 대규모 웹사이트 기술 발전을 이끄는 주요 원동력은 웹사이트 사업 개발

D. 웹사이트 아키텍처 디자인에 대한 오해

1. 기업2. 기술을 위한 기술

3. 기술을 사용하여 모든 문제를 해결하려고 합니다. 기술은 비즈니스 문제를 해결하는 데 사용되며 비즈니스 문제도 비즈니스 수단을 통해 해결될 수 있습니다.

2. 대규모 웹사이트 아키텍처 패턴

각 패턴은 반복되는 문제와 문제 해결의 핵심을 묘사합니다. 이렇게 하면 작업을 중복할 필요 없이 솔루션을 계속해서 사용할 수 있습니다. 패턴의 핵심은 패턴의 반복성입니다.

A. 웹 사이트 아키텍처 패턴

1. 레이어링

레이어링: 수평 차원에서 시스템을 여러 부분으로 나누고 각 부분이 일부를 담당하는 아키텍처 패턴입니다. 상대적으로 단일한 책임을 맡고 상위 계층에서 하위 계층으로의 종속성과 호출을 통해 완전한 시스템을 형성합니다.

웹사이트 소프트웨어 시스템을 애플리케이션 계층(뷰 계층, 비즈니스 로직 계층), 서비스 계층(데이터 인터페이스 계층, 논리 처리 계층), 데이터 계층으로 나누세요
거대한 소프트웨어를 더 잘 통합할 수 있습니다. 시스템은 작업 분할, 협력 개발 및 유지 관리를 용이하게 하기 위해 여러 부분으로 나누어 각 계층 간에 호출 인터페이스가 변경되지 않는 한 각 계층은 다른 부분이 필요 없이 특정 문제에 따라 독립적으로 개발을 심화할 수 있습니다. 해당 조정을 수행하는 레이어입니다.
2. 나누기

세로로 자릅니다. 서로 다른 기능과 서비스를 분리하여 응집력이 높고 결합도가 낮은 모듈형 장치로 패키징합니다. 대규모 웹사이트의 경우 세분화 수준이 매우 작을 수 있습니다.

3. 분산형

은 서로 다른 모듈이 서로 다른 서버에 배포되고 원격 호출을 통해 함께 작동한다는 의미입니다. 이는 동일한 기능을 완료하는 데 더 많은 컴퓨터를 사용할 수 있음을 의미합니다.

문제: 네트워크는 성능에 심각한 영향을 미칠 수 있습니다. 여러 서버가 다운될 가능성이 높습니다. 또한 분산 환경에서 데이터 일관성을 유지하기가 매우 어렵습니다.
일반적인 분산 솔루션: 분산된 정적 리소스, 분산된 데이터 및 스토리지, 분산된 파일 등;
4. 클러스터

여러 서버가 동일한 애플리케이션을 배포하여 클러스터를 구성하고, 로드 밸런싱 장비를 통해 공동으로 외부 서비스를 제공합니다.

5. 캐싱

캐싱은 처리 속도를 높이기 위해 계산과 가장 가까운 위치에 일부 데이터를 저장하는 것입니다.

CDN, 역방향 프록시, 로컬 캐시, 분산 캐시.
캐시 사용을 위한 두 가지 전제 조건: 첫째, 데이터 액세스 핫스팟이 불균형합니다. 둘째, 데이터가 특정 기간 내에 유효합니다.
6. 기업 간 메시징 동기식 호출 대신 , 비즈니스 운영은 여러 단계로 나누어지며, 각 단계는 데이터 공유를 통한 협업을 위해 비동기식으로 실행됩니다.

분산 시스템에서는 단일 서버가 다중 스레드 공유 메모리 대기열을 통해 비동기 실행을 달성할 수 있으며, 여러 서버 클러스터는 분산 메시지 대기열을 통해 비동기 실행을 달성할 수 있습니다.

전형적인 생산자-소비자 모델에서는 생산자와 소비자 사이에 직접적인 통화 관계가 없습니다. 이 모델의 특징은 시스템의 가용성을 향상시키고 웹사이트의 응답 속도를 높일 수 있으며, 동시성을 제거합니다.
비동기식 방법을 사용하여 비즈니스를 처리하면 사용자 경험과 비즈니스 프로세스에 영향을 미칠 수 있으며 제품 디자인 지원이 필요합니다.

7. 중복성

서버가 다운되어도 데이터 손실 없이 웹사이트가 계속해서 서비스를 제공할 수 있도록 하려면 어느 정도의 서버 중복성과 데이터 중복성 백업이 필요합니다.
클러스터를 구축하려면 최소 2개의 서버가 필요합니다. 콜드 백업을 위한 정기적인 백업 및 저장 외에도 데이터베이스는 마스터-슬레이브 공유, 실시간 동기화 및 핫 백업을 수행해야 합니다.
대기업에서는 전체 데이터 센터를 백업하고 이를 지역 재해 복구 센터와 동기화할 수 있습니다.

8. 자동화

주로 릴리스 운영 및 유지 관리에 중점을 둡니다.
릴리스 프로세스 자동화: 자동화된 코드 관리, 자동화된 테스트, 자동화된 보안 감지, 자동화된 배포.
자동 모니터링: 자동 경보, 자동 장애 조치, 자동 오류 복구, 자동 성능 저하, 자동 리소스 할당.

9. 보안

B. Sina Weibo의 아키텍처 패턴 적용

3. 대형 웹사이트의 핵심 아키텍처 요소

아키텍처: 최고 수준의 계획, 변경하기 어려운 결정 .

소프트웨어 아키텍처: 대규모 소프트웨어 시스템의 모든 측면을 설계하는 데 사용되는 소프트웨어의 전체 구조와 구성 요소에 대한 추상적인 설명입니다.

A. 성능

브라우저 측: 브라우저 캐시, 페이지 압축, 합리적인 레이아웃, 쿠키 전송 감소, CDN 등
애플리케이션 서버 측: 서버 로컬 캐시, 분산 캐시, 비동기 작업 협력 메시지 큐, 클러스터 등
코드: 멀티스레딩, 향상된 메모리 관리 등
데이터베이스: 인덱싱, 캐싱, SQL 최적화, NoSQL 기술

B. 가용성

서버, 데이터베이스, 파일저장소 등 운영환경의 주요 수단은 이중화입니다.
소프트웨어 개발 중 사전 출시 검증, 자동화된 테스트, 자동화된 출시, 그레이스케일 출시 및 기타 수단을 통해

C 확장성

확장성은 클러스터에 서버를 지속적으로 추가하는 것을 의미합니다. 동시 사용자 액세스에 대한 압력 증가와 데이터 스토리지에 대한 수요 증가를 완화하기 위한 수단입니다. 새로운 서버를 추가하면 기존 서버와 동일한 서비스를 제공할 수 있는지 여부입니다.
애플리케이션 서버: 적절한 로드 밸런싱 장비를 통해 클러스터에 서버를 지속적으로 추가할 수 있습니다.
캐시 서버: 새 서버를 추가하면 캐시 경로가 유효하지 않게 될 수 있습니다. 라우팅 알고리즘이 필요합니다.
관계형 데이터베이스: 라우팅 분할 및 기타 수단을 통해.

D. 확장성

측정 기준: 웹사이트에서 비즈니스 제품을 추가할 때 투명하고 기존 제품에 영향을 미치지 않는지 여부
의미 : 이벤트 중심 아키텍처(메시지 큐), 분산 서비스(비즈니스 및 사용 가능한 서비스 공유, 분산 서비스 프레임워크를 통한 호출)

E 보안

4. 즉각적인 응답: 웹사이트의 고성능 성능 아키텍처

A. 웹사이트 성능 테스트

1. 다양한 관점의 웹사이트 성능

사용자 관점: 페이지 HTML 스타일 최적화, 브라우저 측 동시성 및 비동기 기능 활용, 브라우저 캐싱 전략 조정 CDN 서비스, 반사 프록시 등을 사용합니다.
개발자 관점에서 본 웹사이트 성능: 캐시를 사용하여 데이터 읽기 속도 향상, 클러스터를 사용하여 처리량 향상, 비동기 메시지를 사용하여 요청 응답 속도 향상 및 최대 클리핑 달성, 코드 최적화 방법을 사용하여 프로그램 성능 향상.
운영 및 유지 관리 담당자의 관점에서 본 웹사이트 성능: 백본 네트워크 구축 및 최적화, 비용 효과적인 맞춤형 서버 사용, 가상화 기술을 사용하여 리소스 활용 최적화 등

2. 성능 테스트 지표

응답 시간: 테스트 방법은 요청을 반복하는 것이며, 총 테스트 횟수 10,000회를 합산하여 10,000으로 나눕니다.
동시 사용자 수: 시스템이 동시에 처리할 수 있는 요청 수(웹 사이트 시스템 사용자 수 >> 웹 사이트 온라인 사용자 수 >> 웹 사이트 동시 사용자 수), 테스트 프로그램은 멀티스레딩을 통해 동시 사용자를 시뮬레이션하여 시스템의 동시 처리 기능을 테스트합니다.
처리량: 단위 시간당 시스템에서 처리하는 요청 수(TPS, HPS, QPS 등)
성능 카운터: 서버 또는 운영 체제의 성능을 설명하는 일부 데이터 조이스틱. 이 문장을 다시 작성한 버전은 다음과 같습니다. 여기에는 시스템 로드, 개체 및 스레드 수, 메모리 사용량, CPU 사용량, 디스크 및 네트워크 I/O가 포함됩니다.

3. 성능 테스트 방법: 성능 테스트, 부하 테스트, 스트레스 테스트, 안정성 테스트

성능 테스트는 시스템 성능 지표, 최대 부하 용량 및 최대 압력 허용 오차를 얻기 위해 시스템에 지속적으로 부하를 추가하기 위해 수행됩니다. 소위 접근 압력이 증가한다는 것은 테스트 프로그램에 대한 동시 요청 수가 지속적으로 증가한다는 것을 의미합니다.

5. 성능 최적화 전략

성능 분석: 요청 처리의 각 링크에 대한 로그를 확인하고, 응답 시간이 비합리적이며 기대치를 초과하는 링크를 분석한 후 모니터링 데이터를 확인합니다.

B. 웹 프런트엔드 성능 최적화

1. 브라우저 액세스 최적화: http 요청 감소(CSS/JS/이미지 병합), 브라우저 캐시 사용(HTTP 헤더의 캐시 제어 및 만료) 압축(Gzip), CSS는 페이지 상단에 배치하고 JS는 페이지 하단에 배치하여 쿠키 전송을 줄입니다

2. CND 가속

3. 캐시 기능을 구성하여 웹 요청을 가속화합니다. (실제 서버를 보호하고 로드 밸런싱 기능도 구현할 수 있음)

C. 애플리케이션 서버 성능 최적화

1. 분산 캐시

웹사이트 성능 최적화의 첫 번째 법칙: 성능 최적화를 위해 캐시 사용을 우선시하라
읽기-쓰기 비율이 높고 거의 변경되지 않는 데이터를 저장하는 데 주로 사용됩니다. 캐시에 적중할 수 없으면 데이터베이스를 읽고 데이터를 캐시에 다시 씁니다.

2. 캐시의 합리적인 사용: 데이터를 자주 수정하지 않음, 핫스팟 없이 액세스, 데이터 불일치 및 더티 읽기, 캐시 가용성(캐시 핫 백업), 캐시 예열(프로그램 시작 시 일부 캐시를 미리 로드), 캐시 침투

3. 분산 캐시 아키텍처: 동기식으로 업데이트해야 하는 분산 캐시(JBoss Cache), 서로 통신하지 않는 분산 캐시(Memcached)

4. 비동기 작업: 메시지 대기열을 사용하여 확장성을 향상할 수 있습니다. 웹 사이트 안정성 및 성능) 피크 감소 효과가 좋으며 짧은 시간에 높은 동시성으로 생성된 트랜잭션 메시지를 메시지 큐에 저장합니다.

5. 클러스터 사용

6. 코드 최적화:

멀티 스레딩(IO 차단 및 다중 CPU, 시작 스레드 수 = [작업 실행 시간-(작업 실행 시간-IO 대기 시간))]*숫자 CPU 코어, 스레드 안전성에 주의 필요: 객체를 상태 없는 객체로 설계하고, 로컬 객체를 사용하고, 리소스에 동시에 액세스할 때 잠금을 사용합니다.
리소스 재사용(단일 사례 및 객체 풀);
데이터 구조;
가비지 컬렉션
D. 스토리지 성능 최적화

1. 데이터베이스는 주로 2레벨 인덱스 B+ 트리를 사용하며 트리 레벨은 최대 3개입니다. 레코드를 업데이트하려면 5번의 디스크 액세스가 필요할 수 있습니다.

2. N-order 병합 트리로 간주할 수 있는 LSM 트리를 사용하는 NoSQL 제품이 많습니다.

3. RAID(Redundant Array of Inexpensive Disks), RAID0, RAID1, RAID10, RAID5, RAID6은 기존 관계형 데이터베이스 및 파일 시스템에서 널리 사용됩니다.

4.HDFS(Hadoop Distributed File System)는 빅데이터 처리를 위해 MapReduce와 협력합니다.

5. Foolproof: 웹 사이트의 고가용성 아키텍처

A. 웹 사이트 가용성 측정 및 평가

1. 웹 사이트 가용성 측정

웹 사이트 비가용 시간(실패 시간) = 오류 복구 시점 - 장애 발견(보고) 시점

웹사이트 연간 가용성 지표 = (1개 웹사이트 이용 불가 시간/연간 총 시간)*100%
2 9초는 기본적으로 88시간 이용 가능합니다. 사용 가능, 9시간은 자동 복구 기능이 있는 고가용성, 53분은 매우 높은 가용성, 5분 미만은 99.99, 49초이며 연간 약 53분 동안 사용할 수 없습니다.
2. 웹사이트 사용성 평가

오류점수 : 웹사이트 장애를 분류하고 가중치를 부여하여 장애책임을 계산하는 방식을 말합니다

오류점수 = 장애시간(분) * 장애가중치
B. 고가용성 웹사이트 아키텍처

주요 수단은 데이터와 서비스의 중복 백업과 장애 조치입니다. 애플리케이션 계층과 서비스 계층은 클러스터 로드 밸런싱을 사용하여 고가용성을 달성하고, 데이터 계층은 데이터 동기 복제를 사용하여 중복 백업을 달성합니다.

C. 고가용성 애플리케이션

1. 로드 밸런싱을 통한 상태 비저장 서비스 장애 조치: 애플리케이션 액세스가 매우 작더라도 로드 밸런싱을 사용하여 소규모 클러스터를 구축하려면 최소 2개의 서버를 배포하세요.

2. 애플리케이션 서버 클러스터의 세션 관리

세션 복제: 서버, 소규모 클러스터 간 세션 동기화

세션 바인딩: 소스 주소 해시를 사용하여 동일한 IP에서 발생하는 요청을 동일한 서버로 분산 고가용성에 영향을 미칩니다.
쿠키를 사용하여 세션 기록: 크기 제한, 각 요청 응답을 전송해야 하며, 쿠키를 끄면 액세스할 수 없습니다.
세션 서버: 분산 캐시 사용, 데이터베이스, 고가용성, 고확장성, 고성능 좋음
D. 고가용성 서비스

1. 계층적 관리: 서버는 계층적으로 운영되고 유지 관리되며, 더 나은 하드웨어를 사용합니다. 운영 및 유지보수 응답 속도도 매우 빠릅니다.

2. 시간 초과 설정: 애플리케이션에서 서비스 호출에 대한 시간 초과를 설정합니다. 시간 초과가 만료되면 통신 프레임워크는 서비스 예약 정책에 따라 요청을 계속 재시도할지 아니면 요청을 다른 서버로 전송할지 선택할 수 있습니다. 동일한 서비스를 제공합니다.

어플리케이션은 하나의 서비스가 실패할 때 전체 애플리케이션 요청이 실패하는 상황을 피하기 위해 메시지 큐와 같은 비동기식 방법을 통해 서비스에 대한 호출을 완료합니다.

4. 서비스 저하: 서비스 거부, 우선 순위가 낮은 응용 프로그램의 호출 거부 또는 일부 요청 호출을 무작위로 거부, 일부 중요하지 않은 서비스 종료 또는 서비스 내에서 중요하지 않은 일부 기능 종료.

5. 멱등성 설계: 서비스 계층에서는 서비스에 대한 반복 호출이 한 번 호출된 것과 동일한 결과를 생성한다는 것이 보장됩니다. 즉, 서비스는 멱등성을 갖습니다.

E. 고가용성 데이터

1.CAP 원칙

고가용성 데이터: 데이터 지속성(영구 저장, 백업 복사본이 손실되지 않음), 데이터 접근성(다른 장치 간 빠른 전환) ), 데이터 일관성 (여러 복사본의 경우 복사본 데이터의 일관성이 보장됨)
CAP 원칙: 데이터 서비스를 제공하는 스토리지 시스템은 데이터 일관성(Consistency), 데이터 가용성(Availability), 파티션 허용 오차를 만족할 수 없습니다. 동시에(Partition Tolerance, 시스템은 네트워크 파티션 전반에 걸쳐 확장성을 가집니다).
일반적으로 대규모 웹사이트는 분산 시스템의 가용성(A)과 확장성(P)을 향상시키며 일관성(C)을 어느 정도 희생합니다. 일반적으로 데이터 불일치는 시스템의 동시 쓰기 작업이 많거나 클러스터 상태가 불안정할 때 발생합니다. 애플리케이션 시스템은 분산 데이터 처리 시스템의 데이터 불일치를 이해하고 어느 정도 보상 및 오류 수정을 수행해야 합니다. 잘못된 애플리케이션 시스템 데이터.
데이터 일관성은 강력한 데이터 일관성(모든 작업이 일관됨), 데이터 사용자 일관성(복사본이 불일치할 수 있지만 사용자가 액세스하면 오류 수정 검증을 통해 올바른 데이터가 결정되어 사용자에게 반환됨)으로 나눌 수 있습니다. , 데이터는 궁극적으로 일관성이 있습니다(복사본과 사용자 액세스는 일관성이 없을 수 있지만 시스템은 일정 기간의 자체 복구 및 수정 후에 일관성에 도달함)

2. 데이터 백업

비동기 핫 백업: 여러 복사본 data 쓰기 작업이 비동기식으로 완료됩니다. 애플리케이션이 쓰기 작업에 대한 데이터 서비스 시스템으로부터 성공적인 응답을 받으면 하나의 복사본만 성공적으로 기록되고 스토리지 시스템은 다른 복사본을 비동기식으로 씁니다(실패할 수 있음)
동기식 핫 대기: 다중 데이터 복사본의 쓰기 작업이 동기적으로 완료됩니다. 즉, 애플리케이션이 데이터 서비스 시스템으로부터 쓰기 성공 응답을 받으면 다중 데이터 복사본의 쓰기 작업이 성공한 것입니다.

3. 전송 실패

실패 확인: 하트비트 감지, 애플리케이션 액세스 실패
액세스 전송: 서버가 다운된 것을 확인한 후 데이터 읽기 및 쓰기 액세스를 다른 서버로 재설정
데이터 복구: 정상 서버에서 데이터를 복사하고 데이터 복사본 수를 설정한 값으로 복원

F. 고가용성 웹사이트를 위한 소프트웨어 품질 보증

1. 자동화 테스트: Selenium

도구는 사전 출시 서버에서 사전 출시 검증을 수행합니다. 먼저 개발 엔지니어와 테스트 엔지니어가 사용할 수 있도록 사전 출시 머신에 출시합니다. 프로덕션 환경과 동일한 구성, 환경, 데이터 센터 등이 필요합니다.

4. 코드 제어: svn, git; 브랜치 개발, 트렁크 릴리스(메인스트림)

6. 그레이스케일 릴리스: 클러스터 서버를 여러 부분으로 나누어 매일 서버의 일부만 릴리스하고, 해당 기간 동안 문제가 발견되면 안정적으로 작동하는지 관찰합니다. 출시된 서버의 일부입니다. 사용자 테스트(AB 테스트)에도 일반적으로 사용됩니다.

G. 웹사이트 운영 모니터링

1. 모니터링 데이터 수집

운영 체제 및 브라우저 버전, IP 주소, 페이지 접속 경로, 페이지 체류 시간 및 기타 정보를 포함한 사용자 행동 로그를 수집합니다. 서버 측 로그 수집 및 클라이언트 측 브라우저 로그 수집이 포함됩니다.

서버 성능 수집: 시스템 로드, 메모리 사용량, 디스크 IO, 네트워크 IO 등, 도구 Ganglia 등
실행 데이터 보고서: 버퍼 적중률, 평균 응답 지연 시간 등 , 분당 전송된 이메일 수, 처리할 총 작업 수 등
2. 모니터링 및 관리

시스템 알람: 다양한 모니터링 지표에 대한 임계값을 설정하고 이메일, 인스턴트 메시징 도구, SMS 등을 사용하여 알람을 보냅니다.

전송 실패: 애플리케이션에 사전에 알림 전송 실패
자동 정상 다운그레이드: 모니터링 매개변수를 기준으로 애플리케이션 로드를 판단하고, 부하가 낮은 애플리케이션 서버를 적절하게 제거하고, 부하가 높은 애플리케이션을 다시 설치하여 전체 애플리케이션 로드의 균형을 맞춥니다.

소위 웹사이트의 확장성이란 소프트웨어를 변경하지 않고 배포된 서버 수만 변경하는 것만으로도 웹사이트를 확장하거나 축소할 수 있음을 의미합니다. 및 웹사이트의 하드웨어 설계.

A. 웹 사이트 아키텍처의 확장성 설계

1. 확장성을 달성하기 위한 다양한 기능의 물리적 분리: 수직적 분리(계층화 후 분리), 시스템 확장성을 달성하기 위해 비즈니스 처리 프로세스의 여러 부분을 분리 및 배포합니다. 비즈니스 분할 후) 시스템 확장성을 달성하기 위해 다양한 비즈니스 모듈이 별도로 배포됩니다.

2. 클러스터 규모를 통해 단일 기능을 확장할 수 있습니다

B. 애플리케이션 서버 클러스터의 확장성 설계

1. 애플리케이션 서버는 상태 비저장으로 설계되어야 하며 요청 컨텍스트 정보를 저장하지 않아야 합니다.

2. 로드 밸런싱:

HTTP 리디렉션 로드 밸런싱: 사용자의 HTTP 요청을 기반으로 실제 웹 서버 주소를 계산하고, 서버 주소를 HTTP 리디렉션 응답에 적어 사용자의 브라우저에 반환합니다. 이 솔루션에는 장점이 있지만 두 개의 요청이 필요하고 리디렉션 서버 자체의 처리 능력이 제한될 수 있다는 단점이 있습니다. 또한 302 점프도 SEO에 영향을 미칠 수 있습니다.
DNS 도메인 이름 확인 로드 밸런싱: DNS 서버의 여러 A 레코드가 서로 다른 IP를 가리키도록 구성합니다. 장점은 로드 밸런싱 작업이 DNS로 전송된다는 것입니다. 또한 대부분은 가장 가까운 서버로의 지리적 위치 반환을 지원합니다. . 단점은 A 레코드가 캐시될 수 있고 제어권이 도메인 이름 서비스 제공자에게 있다는 것입니다.
반사 프록시 로드 밸런싱: 브라우저가 요청한 주소는 역방향 프록시 서버입니다. 역방향 프록시 서버는 요청을 받은 후 로드 밸런싱 알고리즘을 기반으로 실제 물리적 서버의 주소를 계산하여 요청을 전달합니다. 실제 서버는 처리가 완료된 후 역방향 프록시 서버에 응답을 반환하고 역방향 프록시 서버는 해당 응답을 사용자에게 반환합니다. 애플리케이션 계층(HTTP 계층) 로드 밸런싱이라고도 합니다. 배포는 간단하지만 역방향 프록시의 성능으로 인해 병목 현상이 발생할 수 있습니다.
IP 로드 밸런싱: 사용자 요청 데이터 패킷이 로드 밸런싱 서버에 도달한 후 로드 밸런싱 서버는 운영 체제 커널 프로세스에서 네트워크 데이터 패킷을 획득하고 로드 밸런싱 알고리즘을 기반으로 실제 웹 서버를 계산하고, 그런 다음 데이터 대상 IP 주소를 실제 서버로 수정하여 전송하며 사용자 프로세스에서 처리할 필요가 없습니다. 실제 서버에서 처리가 완료된 후 응답 패킷은 로드밸런싱 서버로 반환되고, 로드밸런싱 서버는 패킷의 소스 주소를 자신의 IP 주소로 수정하여 사용자의 브라우저로 보냅니다.
데이터 링크 계층 로드 밸런싱: 삼각 전송 모드, 데이터 분산 과정에서 로드 밸런싱 서버의 IP 주소는 수정되지 않고 대상 mac 주소만 수정되며 모든 서버의 가상 IP 주소가 일관됩니다. 로드 밸런싱 서버의 IP 주소로 데이터 패킷의 소스 주소와 대상 주소가 수정되지 않으므로 IP가 일치하므로 응답 데이터 패킷이 사용자의 브라우저로 직접 반환될 수 있습니다. 직접 라우팅(DR)이라고도 합니다. LVS(Linux 가상 서버) 제품을 나타냅니다.

3. 로드 밸런싱 알고리즘:

라운드 로빈(RR): 모든 요청이 각 애플리케이션 서버에 분산됩니다.
가중 라운드 로빈(WRR): 서버 하드웨어의 성능에 따라 Polling을 기준으로 구성된 가중치에 따라 분배됩니다.
Random: 요청이 각 응용 서버에 무작위로 할당됩니다.
Least Connections: 녹화 서버에서 처리 중인 연결 수와 새로운 요청이 분배됩니다.
소스 해싱: 요청 소스의 IP 주소를 기반으로 해시 계산

C. 캐시 클러스터의 분산 확장성 설계

1. 캐시 클러스터

KEY를 통해 라우팅 알고리즘 모듈에 들어가면 라우팅 알고리즘이 읽고 쓰기 위한 Memcached 서버를 계산합니다.

2. Memcached 분산 캐시 클러스터의 확장성 문제

간단한 라우팅 알고리즘은 나머지 해시 방법을 사용하는 것입니다. 캐시 데이터 KEY의 해시 값을 서버 수로 나누고 나머지에 해당하는 서버 번호를 찾습니다. 확장이 잘 되지 않습니다.

3.분산 캐시의 일관된 해시 알고리즘

먼저 2의 32제곱(일관적 해시 링)으로 정수 링을 구성하고 해시 값에 따라 이 해시에 캐시 서버 노드를 배치합니다. 노드 이름. 그런 다음 캐시해야 하는 데이터의 KEY 값을 기준으로 Hash 값을 계산한 다음, KEY의 Hash 값에 가장 가까운 캐시 서버 노드를 Hash 링에서 시계 방향으로 검색하여 KEY에서 KEY로 Hash 매핑 검색을 완료합니다. 섬기는 사람.

D. 데이터 스토리지 서버 클러스터의 확장성 설계

1. 관계형 데이터베이스 클러스터의 확장성 설계

데이터 복제(마스터-슬레이브), 테이블 및 데이터베이스 파티셔닝, 데이터 샤딩(Cobar)

2.NoSQL 데이터베이스 확장성 design

NoSQL은 관계형 대수학 및 SQL(구조적 쿼리 언어)을 기반으로 하는 정규화된 데이터 모델을 포기하고 트랜잭션 일관성(ACID)을 보장하지 않습니다. 고가용성 및 확장성이 향상되었습니다. (아파치 HBase)

위 내용은 mysql 대규모 웹사이트 기술 아키텍처의 핵심 원칙은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!