소규모에서 대규모로 MySQL 아키텍처의 진화에 대한 세부 정보

웹사이트(discuz)가 처음부터 일일 PV 수천만 건의 방문 횟수가 적다고 가정해 보겠습니다. mysql 서버 아키텍처의 진화를 추측해 보겠습니다.

첫 번째 단계
일일 웹사이트 방문 pv 수준은 1w 미만입니다. 한 대의 머신으로 웹과 DB를 구동하며, 아키텍처 계층 튜닝이 필요하지 않습니다(예: Memcached 캐시를 늘릴 필요가 없습니다). 이때 데이터는 매일 콜드백업을 하는 경우가 많지만, 데이터 보안을 고려하면 mysql 마스터-슬레이브를 설정하는 경우도 있다.

2단계
일일 웹사이트 방문 PV가 수만명을 돌파했습니다. 이때 단일 머신은 이미 어느 정도 로드가 되어 있습니다. 웹과 DB를 분리하고, 캐시로 memcached 서비스를 구축해야 합니다. 즉, 이 단계에서는 단일 시스템을 사용하여 mysql을 실행하여 전체 웹사이트의 데이터 저장 및 쿼리를 수행할 수도 있습니다. MySQL 마스터-슬레이브를 수행하는 경우 그 목적도 데이터 보안을 위한 것입니다.

3단계
일일 웹사이트 방문 PV가 수십만을 돌파했습니다. 단일 머신에서도 이를 지원할 수 있지만 필요한 머신 구성은 이전 머신보다 훨씬 좋습니다. 자금이 허락한다면 MySQL 서비스를 실행하기 위해 높은 구성의 머신을 구입할 수 있습니다. 그러나 이는 구성을 두 배로 늘려도 성능이 두 배로 향상된다는 의미는 아닙니다. . 따라서 이 단계에서는 mysql 서비스 클러스터링을 고려할 것입니다. 이는 여러 시스템을 사용하여 MySQL을 실행할 수 있음을 의미합니다. 하지만 MySQL 클러스터는 웹 클러스터와 다르기 때문에 데이터 일관성을 고려해야 하기 때문에 단순히 웹 클러스터링(lvs, nginx 프록시) 방식을 적용할 수는 없습니다. 가능한 아키텍처는 mysql 마스터-슬레이브, 하나의 마스터와 여러 슬레이브 입니다. 아키텍처의 견고성과 데이터 무결성을 보장하기 위해 하나의 마스터와 여러 개의 슬레이브만 있을 수 있습니다.

우리가 생각해야 할 또 다른 문제가 있습니다. 즉, 프런트 엔드 웹 계층에서 우리 프로그램은 MySQL 시스템의 IP를 지정합니다. 기계, 프로그램에서는 어떤 일이 일어나나요? discuz에는 실제로 MySQL 읽기 및 쓰기 분리를 지원하는 기능이 있습니다. 즉, 여러 머신을 사용하여 MySQL을 실행할 수 있는데, 그 중 하나는 쓰기용이고 다른 머신은 읽기용입니다. 프로그램에 읽기 및 쓰기 IP만 구성하면 프로그램이 자동으로 머신을 구별합니다. 물론, discuz와 함께 제공되는 구성을 사용하지 않는 경우 mysql-proxy라는 소프트웨어를 사용하여 읽기-쓰기 분리를 달성할 수도 있습니다. 하나의 마스터와 다중 슬레이브 모드를 지원합니다.

네 번째 단계
일일 웹사이트 방문 횟수가 수백만에 달합니다. 이전의 1-마스터-다중-슬레이브 모델은 웹 사이트 방문 횟수가 증가하면 데이터베이스를 읽는 양도 증가하기 때문에 병목 현상이 발생했습니다. 그러나 슬레이브 수가 수십 개로 증가하면, 모든 bin-log는 모든 슬레이브에 배포되어야 하기 때문에 이 프로세스 자체가 매우 번거로운 문제이며 빈번한 읽기와 결합되어 슬레이브에서 동기화되는 데이터에 큰 지연이 발생할 수 있습니다. 따라서 우리는 최적화를 할 수 있으며 MySQL의 원래 마스터 하나와 여러 슬레이브를 하나의 마스터와 하나의 슬레이브로 변경하면 슬레이브가 다른 슬레이브의 마스터 역할을 하게 됩니다. 및 후속 슬레이브 웹사이트의 모든 업무에 대해서는 책임을 지지 않으며, 빈 로그를 다른 슬레이브와 동기화하는 역할만 담당합니다. 이런 방식으로 여러 개의 슬레이브 라이브러리를 계속해서 쌓을 수 있습니다.

다섯 번째 단계
웹사이트 일일 방문 PV가 1,000만 건에 도달했을 때 웹사이트 이전 아키텍처에는 마스터가 하나만 있었고 여기의 마스터는 병목 현상이 발생했습니다. 따라서 추가 조정이 필요합니다. 예를 들어 업무를 모듈로 나누어 사용자 관련 항목, 권한, 포인트 등을 분리하여 별도의 라이브러리를 운영한 후 이를 마스터-슬레이브, 즉 소위 서브 라이브러리로 사용할 수 있습니다. . 물론 위도를 변경하거나, 액세스량이 많거나 쓰기량이 많은 테이블을 분리하여 서버에서 실행할 수도 있습니다. 테이블을 여러 개의 작은 테이블로 나눌 수도 있습니다. 이 작업 단계에는 일부 절차적 변경이 수반되므로 사전에 개발 동료들과 소통하고 설계하는 것이 필요합니다. 간단히 말해서, 이 단계에서 해야 할 일은 하위 데이터베이스와 하위 테이블입니다.

뒷면에 쓰기
추가 개발을 위해 계속해서 큰 테이블을 작은 테이블로 나누세요. 국내 Alibaba Taobao 웹사이트는 방대한 양의 데이터를 보유하고 있으며, MySQL 아키텍처는 하위 데이터베이스 및 하위 테이블 원칙을 따릅니다. 구매자와 판매자에 따라 나눌 수 있고, 시간에 따라 나눌 수 있습니다.

위 내용은 MySQL 아키텍처가 소규모에서 대규모로 진화하는 과정을 자세히 설명한 내용이므로, 더 많은 관련 내용은 PHP 중국어 홈페이지(m.sbmmt.com)를 참고해주세요!