다섯 가지 아키텍처 원칙
우선 사용자가 요청하는 데이터는 최대한 작아야 한다는 뜻입니다. 요청된 데이터에는 시스템에 업로드된 데이터와 시스템이 사용자에게 반환한 데이터(일반적으로 웹 페이지)가 포함됩니다.
사용자가 요청한 페이지가 반환된 후 브라우저는 페이지를 렌더링할 때 CSS/JavaScript, 이미지 및 Ajax와 같은 다른 추가 요청을 포함합니다. 이 페이지가 의존하는 요청입니다. "추가 요청"으로 정의되며 이러한 추가 요청은 최소한으로 유지되어야 합니다.
요청부터 데이터 반환까지 사용자가 거쳐야 하는 중간 노드 수입니다.
여기서 종속성은 강력한 종속성을 의미합니다.
시스템의 단일 지점은 시스템 아키텍처에서 금기시된다고 할 수 있습니다. 단일 지점은 백업이 없고 제어할 수 없는 위험을 의미하기 때문입니다. 분산 시스템을 설계할 때 가장 중요한 원칙은 "단일 지점을 제거"하는 것입니다. , 또 다른 이름은 "고가용성"입니다.
건축은 균형의 예술이며, 최고의 건축물이 적응하는 장면과 분리되면 모든 것이 공허한 이야기가 될 것입니다. 여기서 기억해야 할 점은 여기에 언급된 사항은 단지 방향일 뿐이라는 점입니다. 이러한 방향으로 최선을 다해 노력해야 하지만 다른 요소의 균형도 고려해야 합니다.
동적 및 정적 분리란 정확히 무엇입니까? 소위 "동적 및 정적 분리"는 실제로 사용자가 요청한 데이터(예: HTML 페이지)를 "동적 데이터"와 "정적 데이터"로 나누는 것을 의미합니다. 간단히 말해서 "동적 데이터"와 "정적 데이터"의 주요 차이점은 페이지에 출력되는 데이터가 URL, 브라우저, 시간, 지역과 관련이 있는지, 쿠키와 같은 개인 데이터가 포함되어 있는지 여부를 확인하는 것입니다.
먼저, 사용자에게 가장 가까운 정적 데이터를 캐시해야 합니다. 정적 데이터는 상대적으로 변하지 않는 데이터이므로 캐시할 수 있습니다. 어디에 캐시되어 있나요? 세 가지 일반적인 항목이 있습니다. 사용자 브라우저, CDN 또는 서버 캐시에 있습니다. 상황에 따라 최대한 사용자 가까이에 캐시해야 합니다.
두 번째, 정적 변환은 HTTP 연결을 직접 캐시하는 것입니다. 일반적인 데이터 캐싱과 비교하면 시스템의 정적 변환에 대해 들어보셨을 것입니다. 정적 변환은 단순히 데이터를 캐싱하는 것이 아니라 HTTP 연결을 직접 캐싱하는 방식으로, 아래 그림과 같이 웹 프록시 서버가 요청 URL에 따라 해당 HTTP 응답 헤더와 응답 본문을 직접 꺼내서 직접 반환하는 방식입니다. 매우 간단하여 HTTP 프로토콜을 사용하지도 않고 HTTP 요청 헤더도 구문 분석할 필요가 없습니다.
셋째, 누가 정적 데이터를 캐시하는지도 중요합니다. 다양한 언어로 작성된 캐시 소프트웨어는 캐시된 데이터를 처리하는 효율성이 다릅니다. Java를 예로 들어 보겠습니다. Java 시스템 자체에도 약점이 있기 때문입니다(예: 많은 수의 연결 요청을 처리하는 데 능숙하지 않고 각 연결이 더 많은 메모리를 소비하며 서블릿 컨테이너의 HTTP 프로토콜 구문 분석이 느립니다). , 따라서 Java 계층에서는 캐싱을 수행할 수 없지만 웹 서버 계층에서 직접 수행하면 Java 언어 수준에서 일부 약점을 보호할 수 있습니다. 웹 서버(예: Nginx, Apache, Varnish)는 다음과 같습니다. 또한 대규모 동시 정적 파일 요청을 처리하는 데 더 좋습니다.
아키텍처의 복잡성에 따라 선택할 수 있는 3가지 옵션이 있습니다.
단일 머신 배포:
통합 캐시 계층:
플러스 CDN 레이어:
CDN 배포 솔루션에는 다음과 같은 기능도 있습니다.
핫스팟은 핫스팟 운영과 핫스팟 데이터로 구분됩니다.
많은 수의 페이지 새로고침, 다수의 장바구니 추가, Double Eleven에서 0시에 이루어진 다수의 주문 등과 같은 소위 "핫 작업"이 모두 이 범주에 속합니다. . 시스템의 경우 이러한 작업은 "읽기 요청"과 "쓰기 요청"으로 추상화될 수 있습니다. 이 두 핫스팟 요청은 매우 다른 방식으로 처리되는 반면, 쓰기 요청의 병목 현상은 일반적으로 스토리지 계층. 최적화의 개념은 CAP 이론을 기반으로 균형을 맞추는 것입니다. 이 내용은 "재고 감소" 기사에서 자세히 소개하겠습니다.
"핫스팟 데이터"는 사용자의 핫스팟 요청에 해당하는 데이터, 즉 데이터를 이해하기 더 쉽습니다. 핫스팟 데이터는 "정적 핫스팟 데이터"와 "동적 핫스팟 데이터"로 구분됩니다.
소위 "정적 핫스팟 데이터"는 사전에 예측할 수 있는 핫스팟 데이터를 말합니다. 예를 들어 등록을 통해 사전에 판매자를 필터링하고 등록 시스템을 통해 이러한 인기 상품을 표시할 수 있습니다. 또한, 빅데이터 분석을 활용해 인기 상품을 사전에 찾아낼 수도 있습니다. 예를 들어, 과거 거래 기록, 사용자 장바구니 기록을 분석하여 어떤 상품이 더 인기 있고 더 잘 팔릴 수 있는지 알아낼 수 있습니다. 미리 분석해 보세요.
소위 "동적 핫스팟 데이터"는 사전 예측이 불가능하고 시스템 작동 중에 일시적으로 생성되는 핫스팟을 의미합니다. 예를 들어, 판매자가 Douyin에 광고를 하면 해당 제품이 즉시 인기를 얻게 되어 짧은 시간 내에 대량으로 구매하게 됩니다.
핫스팟 작업은 사용자 행동이므로 변경할 수는 없지만 몇 가지 제한 및 보호는 할 수 있습니다. 따라서 이 글에서는 핫스팟 데이터를 최적화하는 방법을 주로 소개하겠습니다.
최적화
핫스팟 데이터를 최적화하는 가장 효과적인 방법은 캐시하는 것입니다. 핫스팟 데이터, 핫스팟 데이터를 정적 데이터와 분리하면 정적 데이터를 오랫동안 캐시할 수 있습니다. 그러나 핫스팟 데이터 캐싱은 "임시" 캐시에 가깝습니다. 즉, 정적 데이터이든 동적 데이터이든 큐 길이가 제한되어 있으므로 큐에 잠시 캐시됩니다. LRU 제거 알고리즘.
제한사항
제한은 보호 메커니즘에 가깝고 이를 제한하는 방법은 다양합니다. 예를 들어 액세스한 제품의 ID에 대해 일관된 해시를 수행한 다음 해시를 기반으로 버킷별로 처리 대기열을 설정합니다. 인기 있는 제품을 요청 대기열로 제한하면 특정 인기 제품이 서버 리소스를 너무 많이 차지하여 다른 요청이 서버에서 처리 리소스를 받지 못하게 되는 것을 방지할 수 있습니다.
격리
플래시 세일 시스템 설계의 첫 번째 원칙은 이러한 핫 데이터를 격리하여 1%의 요청이 나머지 99%에 영향을 미치지 않도록 하는 것입니다. 요청의 1%. 격리는 비즈니스 격리, 시스템 격리, 데이터 격리로 나눌 수 있습니다.
교통 피크 셰이빙 방법
도시의 도로와 마찬가지로 아침 피크와 저녁 피크의 문제 때문에 피크 이동 및 교통 제한에 대한 솔루션이 있습니다.
피크 클리핑의 존재는 첫째, 서버 측 처리를 보다 안정적으로 만들 수 있고, 둘째, 서버 리소스 비용을 절약할 수 있습니다.
플래시 세일 시나리오에서 피크 클리핑은 본질적으로 일부 유효하지 않은 요청을 줄이고 걸러내기 위해 사용자 요청의 발행을 더 지연시키는 것입니다. 이는 "요청 수가 최대한 적어야 한다"는 원칙을 따릅니다.
가장 쉬운 솔루션은 메시지 대기열을 사용하여 순간 트래픽을 버퍼링하고, 동기 직접 호출을 비동기 간접 푸시로 변환하고, 전달 대기열이 순간 트래픽을 처리하는 것입니다. 한쪽 끝에서는 최고조에 달하고 다른 쪽 끝에서는 메시지를 부드럽게 밀어냅니다.
메시지 대기열 외에도 다음과 같은 유사한 대기열 방법이 많이 있습니다.
이것은 매우 중요합니다. 다른 모든 단계는 보조 단계입니다. 재고가 100개 있는데 그냥 100개 팔고 데이터베이스에서 0으로 줄이면 뭐가 문제인가요? 예, 이론적으로는 그렇습니다. 그러나 특정 비즈니스 시나리오에서 "재고 감소"는 그렇게 간단하지 않습니다.
제품 페이지에서 "지금 구매" 버튼을 클릭하고 정보를 확인한 후 "주문 제출"을 클릭합니다. 주문한 후 결제 작업을 완료해야 진정한 구매가 가능합니다. 이는 "주머니에 안전"이라는 말이 있습니다.
재고 감소 작업에는 일반적으로 다음과 같은 방법이 있습니다.
즉, 구매자가 주문한 후 구매자의 구매 수량은 해당 상품의 전체 재고에서 차감됩니다. 재고를 줄이기 위해 주문하는 것은 재고를 줄이는 가장 간단한 방법이자 가장 정확한 통제 방법이기도 합니다. 주문 시 데이터베이스의 거래 메커니즘을 통해 상품의 재고가 직접 통제되므로 과매도 상태가 발생합니다. 발생하지 않습니다. 그러나 어떤 사람들은 주문한 후에 지불하지 않을 수도 있다는 것을 알아야 합니다.
즉, 구매자가 주문한 후 재고가 즉시 감소되지는 않지만 실제로는 사용자가 결제할 때까지 재고가 감소하며, 그렇지 않은 경우 해당 재고는 다른 구매자를 위해 예약됩니다. 다만, 결제가 완료된 후에야 재고가 줄어들기 때문에 동시성이 상대적으로 높을 경우, 다른 사람이 상품을 구매한 경우가 있어 구매자가 주문 후 결제를 하지 못하는 상황이 발생할 수 있습니다.
이 방법은 구매자가 주문한 후 일정 시간(예: 10분) 동안 재고가 자동으로 다른 사람에게 공개됩니다. 출시 후에도 구매자는 계속 구매할 수 있습니다. 구매자가 결제하기 전에 시스템은 주문의 재고가 아직 예약되어 있는지 확인합니다. 예약이 없으면 재고가 부족한 경우(즉, 원천징수 실패) 결제가 다시 시도됩니다. 계속 허용되며, 원천징수에 성공하면 결제가 완료되고 실제로 재고가 차감됩니다.
시스템의 고가용성 구축이라고 하면 사실상 시스템 구축의 모든 단계를 고려해야 하는 시스템 프로젝트이기 때문에 실제로 진행된다는 뜻입니다. 아래 그림과 같이 시스템 구축의 전체 수명주기:
아키텍처 단계에서는 주로 시스템의 확장성과 내결함성을 고려하고 시스템의 단일 지점 문제를 방지합니다. 예를 들어, 여러 컴퓨터실의 단위 배포에서 특정 도시의 특정 컴퓨터실에 전반적인 장애가 발생하더라도 전체 웹사이트의 운영에는 영향을 미치지 않습니다.
코딩에서 가장 중요한 것은 코드의 견고성을 보장하는 것입니다. 예를 들어 원격 통화 문제의 경우 다른 시스템에 의해 압도당하지 않도록 합리적인 시간 초과 종료 메커니즘을 설정해야 합니다. , 호출의 반환 결과 집합도 보장되어야 합니다. 반환된 결과가 프로그램의 처리 범위를 초과하는 것을 방지하기 위해 가장 일반적인 방법은 오류 예외를 캡처하고 예상치 못한 오류에 대한 기본 처리 결과를 갖는 것입니다.
테스트는 주로 테스트 사례의 적용 범위를 보장하고 최악의 사례가 발생할 경우 해당 처리 절차도 갖추고 있는지 확인하는 것입니다.
또한 릴리스할 때 주의해야 할 사항이 있습니다. 릴리스 중에 오류가 발생할 가능성이 가장 높기 때문에 긴급 롤백 메커니즘이 마련되어 있어야 합니다.
실행 시간은 시스템의 정상적인 상태입니다. 실행 상태에서 가장 중요한 것은 시스템 모니터링이 정확하고 정확해야 한다는 것입니다. 문제가 발견되면 알람이 정확해야 하며 문제 해결을 용이하게 하기 위해 알람 데이터가 정확하고 상세해야 합니다.
장애가 발생하면 제때에 손실을 막는 것이 가장 중요합니다. 예를 들어 프로그램 문제로 인해 제품 가격이 잘못되면 해당 제품을 진열대에서 꺼내야 합니다. 또는 큰 자산 손실을 방지하기 위해 구매 링크를 적시에 닫아야 합니다. 그러면 적시에 서비스를 복원하고 원인을 찾아 문제를 해결할 수 있어야 합니다.
교통량이 많을 때 시스템의 정상적인 작동을 어떻게 극대화해야 합니까?
소위 "다운그레이드"는 시스템 용량이 특정 수준에 도달하면 시스템의 특정 비핵심 기능이 제한되거나 종료되어 더 많은 핵심 비즈니스를 위해 제한된 리소스를 확보하는 것을 의미합니다. 이는 목적이 있고 계획된 실행 프로세스이므로 다운그레이드를 위해서는 일반적으로 실행을 조정하기 위한 일련의 계획이 필요합니다. 이를 체계화하면 계획 시스템과 전환 시스템을 통해 성능 저하를 달성할 수 있습니다.
전류 제한이란 시스템 용량이 병목 현상에 도달했을 때 트래픽의 일부를 제한하여 시스템을 보호해야 한다는 의미이며, 수동 전환을 수행할 수 있을 뿐만 아니라 자동화된 보호도 지원할 수 있습니다. 측정.
클라이언트 측 전류 제한과 서버 측 전류 제한의 장점과 단점:
클라이언트 측 전류 제한은 요청 발행을 제한하고 불필요한 요청 발행을 줄여 시스템 소비를 줄이는 장점이 있습니다. 단점은 클라이언트가 분산된 경우 합리적인 전류 제한 임계값을 설정하는 것이 불가능하다는 것입니다. 임계값을 너무 작게 설정하면 서버가 병목 현상에 도달하기 전에 클라이언트가 제한됩니다. 너무 크게 설정하면 제한되지 않습니다. 제한의 역할을 할 수 있습니다.
서버측 전류 제한의 장점은 서버 성능에 따라 합리적인 임계값을 설정할 수 있다는 것입니다. 단점은 제한된 요청이 잘못된 요청이며 이러한 잘못된 요청을 처리하는 것 자체도 서버 리소스를 소모한다는 것입니다.
카운터(고정 창) 알고리즘
카운터 알고리즘은 카운터를 사용하여 주기 내 방문 횟수를 누적합니다. 설정된 전류 제한 값에 도달하면 전류가 발생합니다. 제한 전략이 발동됩니다. 다음 주기가 시작되면 지워지고 다시 계산됩니다.
이 알고리즘은 독립형 또는 분산 환경에서 구현하기가 매우 간단하며 Redis의 incr 원자 자체 증가 및 스레드 안전성을 사용하여 쉽게 구현할 수 있습니다.
슬라이딩 윈도우 알고리즘
슬라이딩 윈도우 알고리즘은 기간을 N개의 소기간으로 나누고 각 소기간의 방문 수를 기록하며 시간 슬라이딩을 기준으로 만료된 소기간을 삭제합니다. 이 알고리즘은 고정 창 알고리즘의 중요한 문제를 잘 해결할 수 있습니다.
Leaky Bucket Algorithm
Leaky Bucket Algorithm은 접근 요청이 도착하면 Leaky Bucket에 직접 넣는 것입니다. 현재 용량이 상한(현재 한계 값)에 도달하면 폐기됩니다(현재 제한 정책). 누출 버킷은 누출 버킷이 빌 때까지 고정된 속도로 액세스 요청(즉, 요청 통과)을 해제합니다.
토큰 버킷 알고리즘
토큰 버킷 알고리즘은 프로그램이 토큰 버킷이 가득 찰 때까지 r(r=기간/현재 제한 값)의 비율로 토큰 버킷에 토큰을 추가하고, 토큰에 토큰을 추가하는 것입니다. 요청이 도착하면 버킷 버킷 요청 토큰, 토큰을 얻으면 요청이 통과되고 그렇지 않으면 현재 제한 정책이 트리거됩니다
현재 제한으로 문제를 해결할 수 없는 경우 최후의 수단은 다음과 같습니다. 서비스를 직접 거부합니다. 예를 들어, 시스템 로드가 특정 임계값에 도달하면, 예를 들어 CPU 사용량이 90%에 도달하거나 시스템 로드 값이 2*CPU 코어에 도달하면 시스템은 모든 요청을 직접 거부합니다. 이 방법은 가장 폭력적이지만 가장 효과적인 시스템 보호 방법이기도 합니다. . 예를 들어, 플래시 세일 시스템의 경우 다음과 같은 측면에서 과부하 보호를 설계합니다:
프론트 엔드 Nginx에 과부하 보호를 설정합니다. 머신 로드가 특정 값에 도달하면 HTTP 요청이 직접 거부되고 503 오류가 발생합니다. 코드가 반환됩니다. Java 계층에서도 동일한 작업이 수행될 수 있습니다.
서비스 거부는 최악의 상황이 발생하는 것을 방지하고 서버의 과부하로 인해 장기간 서비스를 완전히 제공할 수 없는 상황을 방지하기 위한 최후의 수단이라고 할 수 있습니다. 이와 같은 시스템 과부하 보호는 과부하 시 서비스를 제공할 수 없지만 시스템은 계속 작동할 수 있으며 부하가 떨어지면 쉽게 복구할 수 있습니다. 따라서 모든 시스템과 모든 링크는 최악의 시나리오에 대비하기 위해 이 백업 계획을 설정해야 합니다. 보호를 받고 있습니다.
데이터가 캐시에 로드되지 않거나 넓은 영역에서 동시에 캐시가 무효화되어 모든 요청이 데이터베이스를 조회하게 되어 데이터베이스, CPU 및 메모리 과부하 또는 가동 중지 시간까지 발생합니다.
간단한 눈사태 프로세스:
1) Redis 클러스터의 대규모 오류
2) 캐싱 오류가 발생했지만 여전히 캐시 서비스 Redis에 대한 액세스 요청이 많습니다.
3) 많은 수 이후; Redis 요청이 실패하면 요청이 데이터베이스로 전환됩니다.
4) 데이터베이스 요청이 급격히 증가하여 데이터베이스가 중단됩니다.
5) 대부분의 애플리케이션 서비스가 데이터베이스와 Redis 서비스에 의존하므로 곧 중단될 것입니다. 서버 클러스터의 눈사태를 일으키고 마침내 전체 시스템이 완전히 붕괴될 것입니다.
Solution:
사전 : 고가용성 캐시
고가용성 캐시는 전체 캐시 장애를 방지하기 위한 것입니다. 개별 노드, 기계 또는 컴퓨터실이 종료되더라도 시스템은 여전히 서비스를 제공할 수 있으며 Redis Sentinel과 Redis Cluster 모두 고가용성을 달성할 수 있습니다.
진행중: 캐시 다운그레이드(임시 지원)
방문량이 급격히 증가하여 서비스에 문제가 발생하는 경우 서비스를 계속 사용할 수 있는지 어떻게 확인합니까? 중국에서 널리 사용되는 Hystrix는 눈사태 후 손실을 줄이기 위해 퓨즈, 다운그레이드, 전류 제한의 세 가지 방법을 사용합니다. 데이터베이스가 죽지 않는 한 시스템은 항상 요청에 응답할 수 있습니다. 이것이 우리가 봄 축제 12306마다 여기에 오는 방식이 아닙니까? 응답할 수 있는 한 최소한 티켓을 얻을 수 있는 기회는 있습니다.
사후: Redis 백업 및 빠른 워밍업
1) Redis 데이터 백업 및 복원
2) 빠른 캐시 워밍업
캐시 분해는 핫스팟 데이터 저장 시를 의미합니다. 만료되면 여러 스레드가 동시에 핫스팟 데이터를 요청합니다. 캐시가 방금 만료되었으므로 모든 동시 요청은 데이터를 쿼리하기 위해 데이터베이스로 이동합니다.
Solution:
실제로 대부분의 실제 비즈니스 시나리오에서 캐시 붕괴는 실시간으로 발생하지만, 일반적인 기업 비즈니스에서는 동시성 양이 그렇게 많지 않기 때문에 데이터베이스에 큰 부담을 주지는 않습니다. 높은 . 물론 불행하게도 이런 일이 발생한다면 핫스팟 키가 만료되지 않도록 설정할 수 있습니다. 또 다른 방법은 뮤텍스 잠금을 사용하여 쿼리 데이터베이스에 대한 스레드 액세스를 제어하는 것입니다. 그러나 이로 인해 시스템 처리량이 감소하므로 실제 상황에서 사용해야 합니다.
캐시 침투는 확실히 존재하지 않는 데이터를 쿼리하는 것을 말합니다. 캐시에 있는 데이터에 대한 정보가 없기 때문에 시스템 수준에서 쿼리를 위해 데이터베이스 계층으로 직접 이동합니다. 캐시 레이어가 직접 DB에 도달하는 것을 캐시 침투라고 하는데, 캐시 레이어의 보호 없이 존재해서는 안 되는 데이터에 대한 이러한 쿼리는 누군가가 이 데이터를 악의적으로 사용하는 경우 시스템에 위험을 초래할 수 있습니다. 시스템에 대한 빈번한 요청, 아니 정확히 말하면 시스템에 대한 공격이 존재하지 않아야 하며, 요청이 데이터베이스 계층에 도달하여 DB 마비 및 시스템 장애를 유발합니다.
Solution:
캐시 침투 업계의 솔루션은 상대적으로 성숙합니다. 일반적으로 사용되는 주요 솔루션은 다음과 같습니다.
이 글은 이론적인 글이기 때문에 글 전체에 코드 한줄도 없지만, 글에서 제안하는 내용은 기본적으로 플래시 세일 시스템에서 일어난 일이고, 각 시스템에서 발생할 수 있는 문제는 다릅니다.
위 내용은 6,000 단어 이상 | Flash Kill 시스템 설계 시 주의 사항의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
