Java 고동시성 아키텍처 설계 소개(그림 및 텍스트)

이 기사는 Java의 높은 동시성 아키텍처 설계에 대한 소개(그림 및 텍스트)를 제공합니다. 이는 특정 참조 가치가 있으므로 도움이 될 수 있습니다.

서문

플래시 세일 활동, 일반 빨간 봉투 등 활성 사용자 수가 많고 사용자가 집중된 비즈니스 시나리오에서 높은 동시성이 자주 발생합니다.

비즈니스가 원활하게 운영되고 사용자에게 좋은 상호 작용 경험을 제공하려면 비즈니스 시나리오의 예상 동시성 등의 요소를 기반으로 자체 비즈니스 시나리오에 적합한 높은 동시성 처리 솔루션을 설계해야 합니다.

동영상 강좌 추천→: "수백만 개의 데이터 동시성 솔루션(이론 + 실무)"

지난 몇 년간 전자상거래 관련 제품 개발을 하면서 여러 가지 함정에 부딪히는 행운을 누렸습니다. 동시적으로, 그 과정에서 많은 피와 눈물이 있었습니다. 여기에서 요약한 내용은 나만의 아카이브 기록으로 사용되며 여러분과 공유하겠습니다.

一丶서버 아키텍처

비즈니스는 개발 초기 단계에서 점진적으로 성숙해졌으며, 서버 아키텍처도 상대적으로 단일에서 클러스터링된 다음 분산 서비스로 진화했습니다.

높은 동시성을 지원할 수 있는 서비스에는 균형 잡힌 로드, 데이터베이스용 마스터-슬레이브 클러스터, nosql 캐시용 마스터-슬레이브 클러스터, 정적 파일 업로드용 CDN이 필요한 우수한 서버 아키텍처가 필요합니다. 비즈니스 프로그램을 원활하게 실행할 수 있는 강력한 도구입니다.

서버 부분은 주로 운영 및 유지 관리 인력이 협력하여 공사를 진행합니다. 자세한 내용은 언급하지 않고 여기까지 하겠습니다.

대략 필요한 서버 아키텍처는 다음과 같습니다.

Server

로드 밸런싱(예: nginx, Alibaba Cloud SLB)

리소스 모니터링

분산

데이터베이스

마스터-슬레이브 분리, 클러스터

DBA 테이블 최적화, 인덱스 최적화 등

분산

nosql

마스터-슬레이브 분리, 클러스터

마스터-슬레이브 분리, 클러스터

마스터-슬레이브 분리, 클러스터

redis

mongodb

memcache

cdn

html

css

js

image

동시성 테스트

동시성 테스트가 필요한 비즈니스는 동시성 테스트가 필요하며, 전체 아키텍처가 수행할 수 있는 동시성 정도를 평가하기 위해 대량의 데이터 분석이 사용됩니다. 지원하다.

높은 동시성을 테스트하려면 타사 서버나 자체 테스트 서버를 사용하고, 테스트 도구를 사용하여 동시 요청을 테스트하고, 테스트 데이터를 분석하여 지원 가능한 동시성 수를 추정할 수 있습니다. 자신과 적을 알면 결코 위험에 빠지지 않는다는 속담처럼 조기 경보 참고 자료로 사용하십시오.

타사 서비스:

Alibaba 클라우드 성능 테스트

동시성 테스트 도구:

Apache JMeter

Visual Studio 성능 로드 테스트

Microsoft 웹 애플리케이션 스트레스 도구

실용적인 솔루션

범용 솔루션

높음 사용자 트래픽이 상대적으로 분산되어 있고 때때로 사용자 집합이 많을 수 있습니다.

시나리오: 사용자 체크인, 사용자 센터, 사용자 순서 등

서버 아키텍처 다이어그램:

설명 :

시나리오 이러한 업체는 기본적으로 사용자가 APP에 진입한 후 운영하게 되는 것입니다. 이벤트일(618, Double 11 등)을 제외하면 이러한 업체의 사용자 수는 높지 않습니다. 이들 업무와 관련된 테이블은 모두 빅데이터 테이블이다. 대부분의 업무가 쿼리 작업이므로 사용자가 직접 캐시를 조회하고, 캐시가 없으면 이후에 DB 쿼리를 수행하는 방식이 필요하다. 쿼리 결과를 캐시합니다.

사용자 관련 캐시를 업데이트하려면 해시 그룹화를 위해 사용자 ID를 사용하고 사용자를 다른 캐시에 분산시키는 등 분산된 저장소가 필요합니다. 이러한 방식으로 캐시 세트의 총량이 크지 않으며 쿼리 효율성에 영향을 미치지 않습니다.

다음과 같은 방식:

사용자가 포인트를 얻기 위해 로그인합니다

사용자가 배포한 키를 계산하고 redis 해시에서 오늘 사용자의 체크인 정보를 찾습니다

체크인 정보를 쿼리하면 체크인 정보가 반환됩니다

찾지 못할 경우 DB 쿼리를 통해 오늘 체크인하셨나요? 그렇다면 체크인 정보를 Redis Cache에 동기화하세요.

오늘의 체크인 기록이 DB에 없으면 체크인 로직을 수행하여 오늘의 체크인 기록과 체크인 포인트를 추가하는 DB를 운영합니다. (이 전체 DB 작업이 트랜잭션입니다)

체크인 정보를 redis에 캐시하고 체크인 정보를 반환합니다

Attention

하루에 여러 번 체크인하고 사용자에게 여러 포인트를 발급하는 등 동시성 상황에서는 논리적인 문제가 있을 수 있습니다.

내 블로그 게시물 [빅토크 프로그래머의 눈으로 본 높은 동시성]에는 관련 솔루션이 있습니다.

사용자 주문

여기서 우리는 사용자의 첫 페이지에만 주문 정보를 캐시합니다. 한 페이지에 40개의 데이터가 있으며, 사용자는 일반적으로 첫 번째 페이지에서만 주문 데이터를 볼 수 있습니다

사용자가 액세스하는 주문 목록 첫 번째 페이지라면 캐시를 읽고, DB를 읽고 있지 않다면

, 사용자 배포 키를 계산하고, redis 해시에서 사용자 주문 정보를 검색

사용자 주문 정보를 쿼리하면, 주문정보 반환

존재하지 않는 경우 첫 번째 페이지의 주문 데이터에 대해 DB 쿼리를 수행한 후 redis를 캐시하고 주문 정보를 반환합니다.

User Center

사용자 분포의 키를 계산하고 에서 사용자 주문 정보를 검색합니다. the redis hash

사용자가 정보를 조회하면 사용자 정보를 반환

존재하지 않으면 사용자 DB 쿼리를 수행한 후 Redis를 캐시하고 사용자 정보를 반환

기타 사업

위의 예는 비교적 간단합니다. 동시성이 높은 아키텍처이며 동시성이 높지 않으면 매우 복잡할 수 있습니다. 좋은 지원이지만 비즈니스가 성장하고 사용자 동시성이 증가함에 따라 각 서비스에 대한 서비스를 제공하는 등 아키텍처가 계속 최적화되고 발전할 것입니다. 자체 동시성 아키텍처, 균형 잡힌 서버 및 배포 데이터베이스, nosql 마스터-슬레이브 클러스터(예: 사용자 서비스, 주문 서비스

메시지 대기열

플래시 판매, 플래시 구매 및 기타 활동 비즈니스, 사용자 유입)

시나리오: 정기적으로 빨간 봉투를 받습니다.

서버 아키텍처 다이어그램:

설명:

시나리오에서 예약된 수집은 동시성이 높은 비즈니스입니다. 예를 들어, 플래시 세일 활동을 하는 사용자들은 적시에 쏟아져 들어오고, DB는 순식간에 하나를 받게 될 것입니다. 치명타를 기억하십시오. 이를 유지하지 못하면 충돌이 발생하고 전체 비즈니스에 영향을 미칩니다.

쿼리 작업뿐만 아니라 동시성 데이터 삽입 또는 업데이트 업무도 수행하는 이러한 작업과 마찬가지로 위에서 언급한 일반적인 솔루션은 이를 지원할 수 없습니다. , 메시지 대기열이 사용됩니다. 메시지 대기열에 참여하는 사용자 정보를 추가한 다음 대기열을 사용하고 대기열에 데이터를 추가하는 다중 스레드 프로그램을 작성할 수 있습니다.

다음과 같은 솔루션이 있습니다.

빨간 봉투를 정기적으로 받습니다

일반적으로 redis 목록을 사용하는 데 사용됩니다

사용자가 이벤트에 참여하면 사용자 참여 정보를 대기열에 푸시합니다.

그런 다음 멀티스레드 프로그램을 작성하여 데이터를 팝하고, 빨간 봉투 발행

이것은 동시성이 높은 사용자가 정상적으로 활동에 참여할 수 있도록 지원하고 데이터베이스 서버 다운타임의 위험을 피할 수 있습니다

1차 캐시

고동시성 요청 연결 캐시 서버가 서버가 수신할 수 있는 수준을 초과합니다. 요청된 연결 중 일부 사용자는 연결 설정에 문제가 있어 시간이 초과되어 데이터를 읽을 수 없습니다.

따라서 동시성이 높을 때 캐시 서버에 대한 적중 수를 줄이는 솔루션이 필요합니다. 1단계 캐시는 사이트 서버 캐시를 사용해 데이터를 저장하는데, 요청량이 많은 데이터 중 일부만 저장하는데 주의해야 하며, 캐시되는 데이터의 양을 조절해야 한다. 과도하게 사용될 수 없으며 사이트 애플리케이션의 정상적인 작동에 영향을 미칠 수 없습니다. 캐시는 만료 시간을 초 단위로 설정해야 합니다. 구체적인 시간은 비즈니스 시나리오에 따라 설정됩니다. 요청이 있으면 캐시된 NoSQL 데이터 서버에 연결하지 않고도 데이터 수집이 1단계 캐시에 도달하여 NoSQL 데이터 서버의 부하를 줄일 수 있습니다. Pressure

예를 들어 APP 첫 화면의 제품 데이터 인터페이스, 이러한 데이터는 공개되어 사용자를 위해 맞춤화되지 않으며 자주 업데이트되지 않습니다. 이 인터페이스의 요청량이 상대적으로 크면 첫 번째 수준 캐시에 추가할 수 있습니다.

서버 아키텍처 다이어그램:

nosql 캐시 데이터베이스를 합리적으로 표준화하여 사용하고, 비즈니스에 따라 캐시 데이터베이스 클러스터를 분할하면 기본적으로 비즈니스를 잘 지원할 수 있습니다. 그래서 아직도 그것을 잘 활용하세요. 정적 데이터

동시 요청이 많은 데이터가 변하지 않는다면, 데이터를 얻기 위해 자체 서버를 요청할 필요가 없다면 서버에 대한 리소스 부담을 줄일 수 있습니다.

업데이트 빈도가 높지 않고 데이터가 짧은 지연을 허용하는 경우 데이터를 JSON, XML, HTML 및 기타 데이터 파일로 정적으로 변환하여 CDN에 업로드할 수 있습니다. 가져오지 못한 경우에는 캐시와 데이터베이스에서 데이터를 검색합니다. 관리자가 백그라운드에서 데이터를 편집하면 정적 파일이 다시 생성되어 동기화를 위해 CDN에 업로드됩니다. 동시성이 높은 시간 동안 CDN 서버에서 검색됩니다. CDN 노드 동기화에는 일정 지연이 있으므로 안정적인 CDN 서버 공급자를 찾는 것도 중요합니다.

위 내용은 Java 고동시성 아키텍처 설계 소개(그림 및 텍스트)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!