어떻게 초살 시스템 을 설계 합 니까?

스톱워치
스톱워치 장면 은 보통 전자상거래 사이트 에서 행 사 를 하거나 공휴일 에 12306 사이트 에서 표를 뺏 을 때 만난다.전자상거래 사이트 의 일부 희소 하거나 특가 상품 에 대해 전자상거래 사 이 트 는 보통 규정된 시간 에 한정 판 매 를 한다.이런 상품 의 특수성 때문에 대량의 사용자 들 이 앞 다 투어 구 매 하도록 끌 어 들일 수 있 고 약 정 된 시간 에 동시에 순식간에 페이지 에서 앞 다 투어 구 매 할 것 이다.
스톱워치 시스템 장면 특징
4.567917.초 에 죽 일 때 대량의 사용자 들 이 같은 시간 에 동시에 구 매 를 하고 사이트 의 순간 방문 트 래 픽 이 급증 합 니 다4.567917.초 살 은 일반적으로 방문 요청 수량 이 재고 수량 보다 훨씬 많 고 일부 사용자 만 초 살 에 성공 할 수 있다4.567917.초 살 업무 절차 가 비교적 간단 하고 보통 주문 을 내 려 재 고 를 줄 이 는 것 이다구조 설계 이념 을 일소 하 다.
흐름 제한:일부 사용자 만 이 순식간에 성공 할 수 있 음 을 감안 하여 대부분의 데 이 터 를 제한 하고 일부 데이터 만 서비스 백 엔 드 에 들 어 갈 수 있 도록 해 야 합 니 다.
삭 봉:초살 시스템 에 순식간에 많은 사용자 가 몰 려 들 기 때문에 사재 기 를 시작 할 때 높 은 순간 피크 가 있 을 것 입 니 다.피크 트 래 픽 은 시스템 을 무 너 뜨리 는 매우 중요 한 원인 이기 때문에 순간의 높 은 트 래 픽 을 어떻게 한 동안 안정 적 인 트 래 픽 으로 바 꾸 는 지도 디자인 스톱워치 시스템 의 중요 한 사고 이다.삭 봉 을 실현 하 는 데 자주 사용 되 는 방법 은 캐 시 와 메시지 중간 부품 등 을 이용 하 는 기술 이 있다.
비동기 처리:초살 시스템 은 높 은 병발 시스템 으로 비동기 처리 모델 을 사용 하면 시스템 의 병발 량 을 크게 향상 시 킬 수 있다.사실은 비동기 처 리 는 바로 피크 를 깎 는 실현 방식 이다.
메모리 캐 시:스톱워치 시스템 의 가장 큰 병목 은 일반적으로 데이터베이스 읽 기와 쓰기 입 니 다.데이터베이스 읽 기와 쓰 기 는 디스크 IO 에 속 하기 때문에 성능 이 매우 낮 습 니 다.만약 에 일부 데이터 나 업무 논 리 를 메모리 캐 시 로 옮 길 수 있다 면 효율 이 크게 향 상 될 것 입 니 다.
확장 가능:물론 우리 가 더 많은 사용 자 를 지원 하고 더 큰 병행 을 하려 면 시스템 을 탄력 적 으로 확장 할 수 있 는 것 으로 설계 하 는 것 이 좋 습 니 다.만약 에 데이터 가 오 면 기 계 를 확대 하면 됩 니 다.타 오 바 오,경 동 등 쌍 십일 행사 때 는 거래 피크 에 대비 한 기계 가 많이 늘어난다.
구조 안
일반 스톱워치 시스템 구조

디자인 아이디어
요청 을 시스템 상류 에 차단 하고 하류의 압력 을 낮 춥 니 다.스톱워치 시스템 의 특징 은 병발 량 이 매우 크 지만 실제 스톱워치 에 성공 하 는 요청 수량 이 매우 적 기 때문에 전단 에서 차단 하지 않 으 면 데이터베이스 읽 기와 쓰기 자물쇠 의 충돌 을 초래 할 수 있 고 심지 어 는 잠 금 을 초래 할 수 있 으 며 최종 요청 은 시간 을 초과 할 수 있 습 니 다.
캐 시 충분히 이용:캐 시 를 이용 하면 시스템 읽 기와 쓰기 속 도 를 크게 높 일 수 있 습 니 다.
메시지 큐:메시지 큐 는 피크 를 깎 을 수 있 고 대량의 동시 요청 을 차단 할 수 있 습 니 다.이것 도 비동기 처리 과정 입 니 다.백 스테이지 업 무 는 자신의 처리 능력 에 따라 메시지 큐 에서 요청 메 시 지 를 주동 적 으로 끌 어 올 려 업무 처 리 를 합 니 다.
전단 안
브 라 우 저 쪽(js):
페이지 정적 화:활성 페이지 의 모든 정적 요 소 를 정적 으로 만 들 고 동적 요 소 를 최소 화 합 니 다.CDN 을 통 해 최고치 에 저항 하 다.
중복 제출 금지:사용자 가 제출 한 후 단 추 를 누 르 면 회색 을 설치 하고 중복 제출 을 금지 합 니 다.
사용자 제한 흐름:특정한 시간 동안 사용자 가 한 번 만 요청 을 제출 할 수 있 습 니 다.예 를 들 어 IP 제한 흐름 을 사용 할 수 있 습 니 다.
백 엔 드 프로젝트
서버 컨트롤 러 층(게 이 트 웨 이)
uid(UserID)접근 빈도 제한:브 라 우 저 접근 요청 을 차단 하 였 으 나,일부 악성 공격 이나 다른 플러그 인 에 대해 서 는 서버 제어 층 에서 같은 접근 uid 를 대상 으로 접근 빈 도 를 제한 해 야 합 니 다.
서비스 계층
위 에서 일부 방문 요청 만 차단 하 였 습 니 다.초 에 죽 인 사용자 의 양 이 많 을 때 모든 사용자 가 하나의 요청 만 있 더 라 도 서비스 층 까지 의 요청 수량 이 많 습 니 다.예 를 들 어 우 리 는 100 W 사용자 가 동시에 100 대의 휴대 전 화 를 뺏 고 서비스 층 의 동시 요청 압력 은 적어도 100 W 이다.
메시지 큐 캐 시 요청 사용:서비스 층 이 재고 가 100 대의 휴대 전화 밖 에 없다 는 것 을 알 고 있 는 이상 100 W 개의 요청 을 데이터베이스 에 전달 할 필요 가 전혀 없습니다.그러면 이 요청 들 을 모두 메시지 큐 캐 시 에 기록 할 수 있 습 니 다.데이터베이스 층 의 구독 메 시 지 는 재 고 를 줄 이 고 라 이브 러 리 저장 에 성공 한 요청 은 스톱워치 에 성공 하여 실패 한 스톱워치 로 돌아 갈 수 있 습 니 다.
캐 시 를 이용 하여 읽 기 요청 에 대응 합 니 다.12306 과 같은 티켓 구 매 업무 에 대해 전형 적 인 읽 기,쓰기,적은 업무 이 고 대부분 요청 은 조회 요청 이기 때문에 캐 시 를 이용 하여 데이터 베이스 압력 을 분담 할 수 있 습 니 다.
캐 시 를 이용 하여 쓰기 요청 에 대응 합 니 다.캐 시 는 쓰기 요청 에 대응 할 수 있 습 니 다.예 를 들 어 데이터베이스 에 있 는 재고 데 이 터 를 Redis 캐 시 로 옮 길 수 있 습 니 다.모든 재고 감소 작업 은 Redis 에서 진 행 된 다음 에 백 엔 드 프로 세 스 를 통 해 Redis 에 있 는 사용자 의 스톱워치 요청 을 데이터베이스 에 동기 화 할 수 있 습 니 다.
데이터베이스 계층
데이터베이스 층 은 가장 취약 한 층 으로 일반적으로 디자인 을 응용 할 때 상류 에서 요청 을 차단 해 야 하 며 데이터베이스 층 은'능력 범위 내'의 방문 요청 만 부담 한다.따라서 위 에 서 는 서비스 층 에 대기 열 과 캐 시 를 도입 하여 최 하층 데이터 베 이 스 를 안심 시 켰 다.
사례:메시지 미들웨어 와 캐 시 를 이용 하여 간단 한 스톱워치 시스템 을 실현 합 니 다.
Redis 는 분포 식 캐 시 시스템 으로 다양한 데이터 구 조 를 지원 합 니 다.우 리 는 Redis 를 이용 하여 강력 한 스톱워치 시스템 을 쉽게 실현 할 수 있 습 니 다.
저 희 는 Redis 의 가장 간단 한 key-value 데이터 구 조 를 사용 할 수 있 습 니 다.원자 형식의 변수 값(AtomicInteger)을 key 로 하고 사용자 id 를 value 로 할 수 있 습 니 다.재고 수량 은 원자 변수의 최대 값 입 니 다.모든 사용자 의 스톱워치 에 대해 저 희 는 RPUSH key value 를 사용 하여 스톱워치 요청 을 삽입 합 니 다.삽 입 된 스톱워치 요청 수가 상한 에 도 달 했 을 때 모든 후속 삽입 을 중단 합 니 다.
그 다음 에 저 희 는 플랫폼 에서 여러 개의 작업 스 레 드 를 시작 하여 LPOP key 를 사용 하여 초 살 성공 자의 사용자 id 를 읽 은 다음 에 데이터 베 이 스 를 조작 하여 최종 주문 으로 재 고 를 줄 일 수 있 습 니 다.
물론 위의 Redis 는 ActiveMQ,RabbitMQ 등 메시지 미들웨어 로 바 꿀 수도 있 고 캐 시 와 메시지 미들웨어 를 조합 할 수도 있 습 니 다.캐 시 시스템 은 사용자 의 요청 을 기록 하고 메시지 미들웨어 는 캐 시 에 있 는 요청 을 데이터베이스 에 동기 화 하 는 것 을 책임 집 니 다.
이상 은 본 고의 모든 내용 입 니 다.본 고의 내용 이 여러분 의 학습 이나 업무 에 어느 정도 도움 이 되 기 를 바 랍 니 다.또한 저 희 를 많이 지지 해 주시 기 바 랍 니 다!