대규모 웹사이트에서 mysql 애플리케이션 아키텍처의 진화

이 기사에서는 웹 사이트의 다양한 동시 액세스 수준에서 Mysql 아키텍처의 진화를 주로 설명합니다.

확장성

아키텍처의 확장성은 종종 동시성과 밀접한 관련이 있으며 동시성은 없습니다. 성장, 확장성이 뛰어난 아키텍처를 구축할 필요는 없습니다. 확장성에 대해 간단히 소개합니다.

스케일업: 수직 확장, 더 나은 머신과 리소스로 교체 확장성 확보 및 서비스 성능 향상

Scale-out: 수평적 확장, 노드(머신)를 추가하여 확장성 확보 및 서비스 성능 향상

인터넷에서 동시성이 높은 애플리케이션에는 없습니다. 수평 확장이 탈출구인지 의심스럽습니다. 고급 기계를 수직으로 구입하는 것은 항상 금기시되는 문제였으며 수평 확장 이론에 따르면 확장성의 이상적인 상태는 무엇입니까?

확장성의 이상적인 상태

서비스가 더 높은 동시성을 직면할 때 단순히 머신을 추가하는 것만으로도 서비스가 지원하는 동시성을 향상시킬 수 있고, 머신 프로세스의 연결 수를 늘릴 수 있습니다. 서비스에 영향을 미치지 않습니다(다운타임 없음). 이는 확장성의 이상적인 상태입니다!

아키텍처의 진화

V1.0 간단한 웹사이트 아키텍처

간단한 작은 웹사이트나 애플리케이션 뒤에 있는 아키텍처는 매우 간단할 수 있으며, 데이터에는 단 하나의 mysql 인스턴스만 필요합니다. 저장소 데이터 읽기 및 쓰기 요구 사항을 충족하기 위해(여기에서는 데이터 백업 인스턴스가 무시됨) 이 기간의 웹사이트는 일반적으로 모든 정보를 데이터베이스 인스턴스에 저장합니다.

이러한 아키텍처에서 데이터 저장의 병목 현상은 무엇인지 살펴보겠습니다.

1. 데이터의 전체 크기는 한 머신에 들어갈 수 없습니다

2. 데이터의 인덱스(B+Tree)는 한 머신의 메모리에 들어갈 수 없습니다

3 .한 번에 방문 횟수(읽기와 쓰기 혼합)가 용납될 수 없습니다

위 세 가지 중 하나 이상 충족될 경우에만 다음 단계로의 진화를 고려해야 합니다. 수준. 이를 통해 실제로 많은 소규모 회사와 소규모 애플리케이션의 경우 이 아키텍처가 요구 사항을 충족하기에 충분하다는 것을 알 수 있습니다. 결국 초기 데이터 볼륨에 대한 정확한 평가는 과잉 설계를 방지하는 데 중요한 단계입니다. 불가능한 것에 대해 걱정하고 경험을 낭비하십시오.

다음은 간단한 예입니다. 사용자 정보 테이블(인덱스 3개)의 경우 16G 메모리는 약 2천만 행의 데이터 인덱스를 보유할 수 있으며 간단한 혼합 읽기 및 쓰기 액세스 볼륨은 약 3000/s입니다. . 질문, 귀하의 애플리케이션 시나리오는

V2.0 수직 분할

일반적으로 V1.0에서 병목 현상이 발생할 때 가장 먼저 가장 쉬운 분할 방법은 수직 분할입니다. 비즈니스 관점에서 병목 현상 제거라는 목표를 달성하기 위해 밀접하게 관련되지 않은 데이터는 여러 인스턴스로 분할됩니다. 그림의 예를 보면 사용자 정보 데이터와 비즈니스 데이터가 세 개의 서로 다른 인스턴스로 분할됩니다. 여러 유형의 반복 읽기가 있는 시나리오의 경우 캐시 계층을 추가하여 DB에 대한 부담을 줄일 수도 있습니다.

이러한 아키텍처에서 데이터 저장의 병목 현상은 무엇인지 살펴보겠습니다.

1. 단일 인스턴스 단일 비즈니스에는 여전히 V1.0에서 언급된 병목 현상이 있습니다.

병목 현상이 발생하면 읽기 요청으로 인해 이 문서의 상위 V 버전으로 업그레이드하는 것을 고려할 수 있습니다. 성능 병목 현상이 있는 경우 V3.0으로 업그레이드하고 다른 병목 현상이 있는 경우 V4.0으로 업그레이드하는 것을 고려해 보세요.

V3.0 마스터-슬레이브 아키텍처

이 유형의 아키텍처는 V2.0 아키텍처의 읽기 문제를 주로 Mysql에 실시간 데이터 백업을 첨부하여 마이그레이션합니다. 시나리오 마스터-슬레이브 구조를 통해 마스터 라이브러리는 쓰기 압력에 저항하고 슬레이브 라이브러리는 읽기 압력을 공유합니다. 쓰기가 적고 읽기가 많은 애플리케이션의 경우 V3.0 마스터-슬레이브 아키텍처가 완벽하게 지원됩니다.

이러한 아키텍처에서 데이터 스토리지의 병목 현상은 무엇인지 살펴보겠습니다.

1. 메인 라이브러리가 글쓰기 양을 감당할 수 없음

V4.0 가로 분할

V2.0 V3.0 솔루션에 병목 현상이 발생하면 수평 분할 수평 분할과 수직 분할의 결과는 하나의 인스턴스가 전체 데이터 양을 가지지만, 수평 분할 후에는 모든 인스턴스가 전체 데이터 양의 1/n만 갖는다는 것입니다. , 아래 그림의 Userinfo 분할을 예로 들어 보겠습니다. userinfo를 3개의 클러스터로 분할합니다. 각 클러스터는 전체 데이터의 1/3을 보유합니다. (참고: 이는 전체 데이터와 동일합니다. 클러스터(마스터와 슬레이브를 포함하는 작은 mysql 클러스터를 나타냄) 대신 단일 인스턴스라고 부릅니다.

데이터를 어떻게 라우팅합니까?

1. 범위 분할

샤딩 키는 연속 간격에 따라 라우팅되며 일반적으로 Userid 범위의 작은 예인 Userid와 같은 엄격한 자동 증가 ID 요구 사항이 있는 시나리오에서 사용됩니다. userid 사용 범위 1번 클러스터 사용자 ID 1-3000W 2번 클러스터 사용자 ID 3001W-6000W에 대한 3000W 분할

2. 목록 분할

목록 분할은 범위 분할과 동일한 아이디어를 가지며 둘 다 수행됩니다. 서로 다른 샤딩 키를 사용하여 서로 다른 클러스터로 라우팅하지만 구체적인 방법은 다소 다릅니다. 리스트는 샤딩 키가 연속적인 간격이 아니고 시퀀스가 ​​클러스터에 속하는 상황에 주로 사용됩니다