Java 메시지 대기열의 응용 시나리오는 무엇입니까?

1. Queue란 무엇인가요?

Queue는 가장 큰 특징은 First In First Out입니다. 예를 들어, 기차역에서 표를 사기 위해 줄을 서서 기다리는 것 등입니다. 대기열은 다음 그림으로 나타낼 수 있습니다.

여기서 a1, a2 및 an은 대기열의 데이터를 나타냅니다. 데이터는 대기열의 끝에서부터 대기열에 추가된 다음 대기열의 헤드에서 제거됩니다.

2. 메시지 큐란 무엇입니까? 메시지 큐(Message Queue)는 큐(Queue)를 기본 저장소 데이터 구조로 사용하고 다양한 프로세스와 애플리케이션 간의 통신을 해결하는 데 사용할 수도 있습니다. 메시지 미들웨어라고 합니다.

현재 일반적으로 사용되는 메시지 대기열에는 ActiveMQ, RabbitMQ, Kafka, RocketMQ, Redis 등이 있습니다.

메시지 대기열과 대기열의 차이점은 무엇인가요?

유일한 차이점은 대기열에 들어갈 때는 생산자라고 하고, 대기열에서 나올 때는 소비자라고 한다는 것입니다.

3. 메시지 대기열 응용 시나리오

아래에는 보다 일반적인 시나리오가 나열되어 있습니다

1. 비동기 처리

일반적으로 우리가 작성하는 프로그램은 순서대로입니다. 실행됩니다(즉, 동기적으로). 예를 들어 전자상거래 시스템의 주문 예에서 실행 순서는 다음과 같습니다.

사용자가 주문을 제출합니다. 주문 완료 후 포인트가 추가됩니다. 포인트 변경에 대한 SMS 알림.

는 다음 순서도로 나타낼 수 있습니다.

위 순서로 실행하면 각 서비스가 1초가 걸리면 클라이언트는 3초를 소비하게 됩니다. 사용자 입장에서 3초는 당연히 용납할 수 없는 시간인데 어떻게 해결해야 할까요? 이 문제를 해결하기 위해 비동기식 방법을 사용할 수 있습니다.

이런 방식으로 포인트 서비스와 SMS 서비스는 스레드 비동기 작업을 사용하므로 클라이언트는 1초만 소비하면 됩니다. 완료하는 데 시간이 걸립니다. 그러나 이러한 비동기식 접근 방식은 동시성 감소라는 또 다른 문제를 야기합니다. 포인트 서비스와 SMS 서비스 모두 주문 서비스의 스레드를 열어야 하기 때문에 더 많은 스레드를 열면 클라이언트가 주문 서비스에 동시에 액세스하게 되어 클라이언트가 주문을 제출하는 데 실제 시간이 1초를 초과하게 될 수 있습니다. 그렇다면 비동기로 인해 발생하는 문제를 해결하는 방법은 무엇일까요? 즉, 메시지 대기열을 사용하는 방법은 아래 흐름도를 참조하세요.

위 프로세스에서 먼저 클라이언트가 주문을 제출한 다음 메시지에 주문을 작성합니다. 큐, 포인트 서비스 SMS 서비스와 동시에 메시지 큐의 메시지를 소비합니다. 이 방법은 주문 서비스에서 추가 비동기 스레드를 열 필요가 없으며 클라이언트는 1초의 실시간 소비를 달성할 수 있습니다.

1.2. 애플리케이션 분리

전자상거래 시스템을 예로 들어 설명하겠습니다. 먼저 아래 흐름도를 살펴보세요.

위 그림의 비즈니스 로직: 클라이언트가 생성 요청을 시작합니다. 이때 우리는 재고를 먼저 확보한 다음 재고를 공제해야 합니다. 이런 방식으로 주문 시스템과 재고 시스템은 매우 긴밀한 의존성을 형성합니다. 이때 인벤토리 시스템이 다운되면 주문 시스템이 인벤토리 시스템에 의존하기 때문에 현재 주문 시스템을 이용할 수 없습니다. 그렇다면 어떻게 해결해야 할까요?

아래 메시지 대기열 사용 흐름도를 살펴보세요.

위 프로세스에서 메시지 대기열을 추가했습니다. 먼저 클라이언트가 주문 생성 요청을 시작하고 주문 메시지가 메시지 대기열에 기록됩니다. 그런 다음 인벤토리 시스템은 메시지 대기열의 메시지를 구독하고 마지막으로 인벤토리 시스템을 비동기식으로 업데이트합니다. 인벤토리 시스템이 다운되는 경우 주문 시스템이 인벤토리 시스템에 직접적으로 의존하지 않기 때문에 주문 시스템은 고객의 요청에 정상적으로 응답할 수 있습니다. 이를 통해 애플리케이션 분리가 달성됩니다.

1.3. 트래픽 피크 감소

고동시성 시스템의 경우, 피크 액세스 시간 동안 갑자기 트래픽이 애플리케이션 시스템으로 흘러들어가며, 특히 일부 고동시성 쓰기 작업으로 인해 언제든지 데이터베이스 서버가 붕괴될 수 있습니다. . 서비스를 계속 제공할 수 없습니다.

메시지 대기열을 도입하면 트래픽 버스트가 애플리케이션 시스템에 미치는 영향을 줄일 수 있습니다. 소비큐는 상류의 홍수를 차단하고 하류 강으로의 최대 유량을 줄여 홍수 재해를 줄이는 목적을 달성하는 "저수지"와 같습니다.

이와 관련된 가장 일반적인 예는 플래시 세일 시스템입니다. 일반적으로 플래시 세일 활동의 순간 트래픽이 매우 높습니다. 모든 트래픽이 플래시 세일 시스템으로 흐르면 메시지 대기열을 도입하여 압도됩니다. , 버스트 트래픽은 "피크 감소" 역할을 달성하기 위해 효과적으로 버퍼링될 수 있습니다.

플래시 세일 시나리오를 사용하여 트래픽 피크 감소를 설명합니다. 먼저 아래 흐름도를 살펴보겠습니다.

위 프로세스에서는 플래시 세일 서비스를 업스트림 서비스, 주문 서비스, 재고 서비스라고 부릅니다. , 밸런스 서비스를 총칭하여 서브 다운스트림이라고 합니다. 클라이언트는 클라이언트로부터 요청을 받은 후 플래시 세일 서비스에서 주문을 생성하고 재고를 수정하며 잔액을 차감합니다. 이것이 플래시 세일의 기본 비즈니스 시나리오입니다.

다운스트림 서비스는 동시에 1,000개의 동시 요청만 처리할 수 있고, 업스트림 서비스는 10,000개의 동시 요청을 처리할 수 있으며, 클라이언트는 다운스트림 서비스가 처리할 수 있는 동시성 양을 초과하는 10,000개의 요청을 시작한다고 가정합니다. 다운스트림 서비스가 중단됩니다. 이때 메시지 대기열에 참여하여 다운타임 문제를 해결할 수 있습니다. 아래 메시지 대기열 참여 흐름도를 살펴보세요.

서비스가 클라이언트로부터 10,000개의 요청을 받은 후 모든 요청을 메시지 대기열에 기록한다는 점을 설명하면서 위 흐름도에 메시지 대기열을 추가했습니다. . , 다운스트림 서비스는 메시지 대기열에서 플래시 판매 요청을 구독한 다음 자체 비즈니스 논리 작업을 수행합니다.

간단한 예를 들어보겠습니다. 업스트림 서비스는 여전히 10,000개의 동시 요청을 처리할 수 있으며, 다운스트림 서비스는 여전히 1,000개의 동시 요청만 처리할 수 있습니다. 이때 메시지 대기열에 저장되는 동시 요청은 1,000개입니다. 업스트림 플래시 판매 서비스는 10,000개의 동시 요청을 수신했지만 메시지 대기열은 1,000개의 요청만 저장할 수 있습니다. 초과 요청은 메시지 대기열에 저장되지 않으며 "시스템이 사용 중입니다."라는 메시지와 함께 클라이언트에 직접 반환됩니다. 기다리다!" . 이것이 소위 트래픽 피크 클리핑 시나리오입니다. 이는 다운스트림 서비스가 처리할 수 있는 동시성의 양에 따라 결정됩니다. 다운스트림 서비스는 1,000개의 동시 요청만 처리할 수 있으므로 1,000개의 플래시 세일만 메시지 대기열에 저장될 수 있으며 초과하는 모든 플래시 세일 요청은 클라이언트 프롬프트로 반환됩니다. 이는 다운스트림 서비스의 정상적인 응답을 보장하고 다운스트림 서비스의 다운타임을 유발하지 않으며 시스템 가용성을 향상시킵니다.

2. 로그 시나리오

로그 전송 최적화

프로그램을 강력하게 만들기 위해 일반적으로 프로그램에 오류 로그, 작업 로그 등 다양한 로깅 기능을 추가합니다. 아래 흐름도를 참조하세요.

위 순서도는 동기 로그 기록 과정입니다. 동기 로깅 프로세스를 사용하면 전체 프로세스에 소요되는 시간이 늘어나고 비즈니스 시스템 다운타임이 발생하기 쉽습니다(데이터베이스가 손상된 경우 데이터베이스에 로그를 기록하는 작업으로 인해 오류가 발생함). 메시지 대기열을 사용하여 로그 전송을 최적화할 수 있습니다. 아래 흐름도를 보세요.

메시지 큐에 합류한 후 시스템에 소요되는 시간을 단축할 수 있으며, 애플리케이션 시스템 분리 기능도 달성할 수 있습니다.

3. 인스턴트 커뮤니케이션 시나리오

채팅방

메시지 큐의 주요 기능은 메시지를 보내고 받는 것입니다. 내부에는 효율적인 커뮤니케이션 메커니즘이 있으므로 메시지 커뮤니케이션에 매우 적합합니다.

메시지 대기열을 기반으로 하는 지점간 채팅 시스템을 개발할 수도 있고, 다수의 수신자에게 메시지를 방송하는 방송 시스템을 개발할 수도 있습니다.

위 내용은 Java 메시지 대기열의 응용 시나리오는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!