메시지 대기열의 개념, 원리 및 사용 시나리오에 대한 자세한 소개(사례 포함)

우리 모두 알고 있듯이 웹사이트를 디자인하다 보면 사용자에게 보내는 '대량 문자 메시지', '주문 시스템의 대량 로그', '플래시 세일 디자인' 등을 접하게 됩니다. 서버가 이를 처리할 수 없습니다. 일종의 순간적인 압력 폭발입니다. 시스템의 정상적이고 효과적인 사용을 보장하려면 "메시지 대기열"의 도움이 필요합니다. 이 글은 주로 메시지 큐(Message Queue)라는 개념을 통해 연구합니다.

주로 다음 지식을 이해하세요.

　1. 대기열이란 무엇이며 무엇을 할 수 있나요?

　2. 정렬 적용 시나리오는 무엇입니까?

　3. 대기열을 사용하여 서비스를 분리하는 방법은 무엇입니까?

　4. Redis 대기열을 사용하여 높은 압력을 제거하는 방법은 무엇입니까?

　5. 전문 정렬 시스템 RabbitMQ를 사용하는 방법은 무엇입니까?

주요 내용을 요약하면 다음과 같습니다

　@메시지 큐의 개념, 원리 및 시나리오

　@디커플링 사례: 큐 처리 순서 시스템 및 분배 시스템

　 @트래픽 피크 컷팅 사례: Redis의 List 유형에서 플래시를 구현합니다. sale

　　@ RabbitMQ: 보다 전문적인 메시지 시스템 구현 솔루션

1. 메시지 큐의 이해

1.1 메시지 큐의 개념

본질적으로 메시지 큐는 큐 구조의 미들웨어입니다. 메시지는 여기에 저장됩니다. 그러면 미들웨어는 시스템의 즉각적인 처리 없이 직접 반환될 수 있습니다. 다른 프로그램은 데이터를 읽고 순서대로 하나씩 처리합니다.

즉, 동시성이 매우 높고 시간이 오래 걸리는 상황에 직면하여 처리 결과를 즉시 반환할 필요가 없는 경우 메시지 대기열을 사용하면 이러한 문제를 해결할 수 있습니다.

1.2 핵심 구조

는 비즈니스 시스템에 의해 대기열에 추가되며 메시지가 메시지 대기열에 하나씩 삽입되면 성공적인 결과가 직접 반환됩니다. 메시지 시스템을 처리할 미래는 입력된 레코드를 하나씩 꺼내어 처리하여 대기열 제거 프로세스를 완료합니다.

1.3 응용 시나리오

데이터 중복성: 예를 들어 주문 시스템에서는 향후 엄격한 데이터 변환 및 기록이 필요합니다. 메시지 대기열은 이러한 데이터를 대기열에 지속적으로 저장할 수 있으며 주문 및 후속 처리가 있습니다. 프로그램은 처리 후 이 기록을 삭제하여 각 기록을 처리할 수 있도록 합니다.

시스템 분리: 메시징 시스템을 사용한 후 엔큐 시스템과 디큐 시스템이 분리됩니다. 즉, 어느 날 충돌이 발생하더라도 다른 시스템의 정상적인 작동에는 영향을 미치지 않습니다.

트래픽 피크 절감: 예를 들어 반짝 세일이나 급행 세일에서는 메시지 대기열을 캐싱과 함께 사용할 수 있는데, 이는 순간적인 방문량을 효과적으로 견디고 서버가 과부하되어 충돌을 일으키는 것을 방지할 수 있습니다.

비동기 통신: 메시지 자체는 대기열에 추가된 후 직접 반환될 수 있습니다.

확장성: 예를 들어 주문 대기열은 주문을 처리할 수 있을 뿐만 아니라 다른 비즈니스에서도 사용할 수 있습니다.

정렬 보장: 데이터가 특정 순서로 처리되도록 하려면 단일 입력 및 단일 출력과 같은 일부 시나리오를 제품 순서대로 처리해야 합니다. 메시지 대기열을 사용할 수 있습니다.

위는 메시지 대기열의 일반적인 사용 시나리오입니다. 물론 메시지 대기열은 미들웨어일 뿐이며 다른 제품과 함께 사용할 수 있습니다.

1.4 공통 대기열 구현의 장점과 단점

Queue Media

1. mysql과 같은 데이터베이스(높은 신뢰성, 구현하기 쉬움, 느린 속도)

2. 패킷이 너무 큽니다. 효율성이 낮음)

3. RabbitMq와 같은 메시징 시스템(매우 전문적이고 신뢰성이 높으며 학습 비용이 높음)

메시지 처리 트리거 메커니즘

1. 무한 루프 읽기: 구현하기 쉽고 시간 내에 복구할 수 없음 실패할 경우(플래시 판매, 상대적으로 중앙 집중식, 중앙 집중식 운영 및 유지 관리에 적합)

2. 예약된 작업: 현재 인기 있는 처리 트리거 메커니즘으로 압력이 균등하게 분산됩니다. (유일한 단점은 간격과 데이터에 주의를 기울여야 한다는 점입니다. 이전 작업이 완료되지 않고 다음 작업이 다시 시작될 때까지 기다리지 마십시오.)

3 데몬 프로세스: php-fpm 및 php-와 유사합니다. cg, 쉘 기본 사항 필요

2. 사례 연구: 대기열 처리 "Order System" 및 "Distribution System"

주문 프로세스를 위해 두 가지 시스템을 설계할 수 있습니다. 하나는 "주문 시스템"이고 다른 하나는 "유통 시스템"입니다. 우리 모두는 전에 주문을 제출한 후 내 상품이 배송되는 것을 볼 수 있었습니다. 이때 '배달 시스템'이 필요하다.

건축을 할 때 '주문 시스템'과 '배송 시스템'을 함께 설계한다면, 우선 주문 시스템의 경우 시스템에 대한 부담이 더 커지겠지만, '배송 시스템'이 문제가 됩니다. "하지 않을 것입니다. 이러한 압력에 대한 즉각적인 대응이 필요합니다.

둘째, 주문 시스템 오작동으로 인해 배송 시스템이 오작동하여 두 시스템의 정상적인 작동에 동시에 영향을 미치는 것을 원하지 않습니다. 그래서 우리는 이 두 시스템을 분리하기를 희망합니다. 두 시스템이 분리된 후 중간 "큐 테이블"을 통해 두 시스템 간에 통신할 수 있습니다.

2.1 Architecture design

1 먼저 주문 시스템이 사용자의 주문을 받은 다음 주문을 처리합니다.

2. 그러면 이러한 주문 정보가 대기열 테이블에 기록됩니다. 이 대기열 테이블은 두 시스템 간 통신의 핵심입니다.

3. 처리를 위해 대기열 테이블을 읽기 위해 분배 시스템에서 정기적으로 실행되는 프로그램입니다.

4. 유통 시스템에 의해 처리된 후 처리된 기록이 표시됩니다.

2.2 프로그램 흐름

3. 트래픽 피크 컷팅 사례: Redis 리스트 방식으로 플래시 세일을 실현# 🎜 🎜#

redis는 메모리를 기반으로 하며 속도가 매우 빠릅니다. redis는 내구성이 뛰어나 데이터베이스에 대한 매우 좋은 보완책입니다. redis는 주기적으로 하드 디스크에 데이터를 기록하므로 이런 점에서 다른 캐시 memcache보다 더 많은 장점이 있습니다. 또한 redis는 5가지 데이터 유형(string, double linked list, hash, set,ordered set)을 제공합니다.# 🎜🎜## 🎜🎜# 일반적인 상황에서 redis는 플래시 세일, 급하게 구매하는 경우, 가격이 순간적으로 귀하의 가격보다 높아서 줄을 서야 하는 경우에 좋은 선택입니다.

3.1 Redis 데이터 유형의 목록 유형

Redis의 목록은 이중 연결 목록이며 데이터는 머리 또는 꼬리에서 추가될 수 있습니다.

* LPUSH/LPUSHX: (/기존) 목록의 머리 부분에 값을 삽입합니다.

* RPUSH/RPUSHX: (/기존) 목록의 끝 부분에 값을 삽입합니다. ) list# 🎜🎜#

* LPOP: 목록의 첫 번째 요소를 제거하고 가져옵니다

* RPOP: 목록의 마지막 요소를 제거하고 가져옵니다

* LTRIM : 지정된 범위의 요소 유지

* LLEN: 목록의 길이 가져오기

* LSET: 목록 요소의 값을 인덱스 #🎜🎜로 설정 #

* LINDEX: 인덱스로 목록의 요소 가져오기

* LRANGE: 목록의 지정된 범위에 있는 요소 가져오기

3.2 건축 설계

구조물 플래시 판매를 위한 간단한 프로그래밍.

1. 어떤 유저가 플래시 세일에 참여했는지 첫 번째 기록과 시간을 기록합니다.

2. 사용자 ID를 redis 목록에 저장하고 대기열에 넣습니다. 선착순 10명만 성공적으로 참여할 수 있다고 규정한 경우, 목록에 있는 인원이 충분할 경우 계속해서 데이터를 추가할 수 없습니다. 이렇게 하면 Redis 목록의 길이는 10개만 됩니다.

3. 마지막으로 Redis의 데이터를 데이터베이스에 천천히 써서 데이터에 대한 부담을 줄입니다.

3.3 코드 수준 디자인

1. 사용자가 플래시 세일을 시작하면 플래시 세일 프로그램 요청을 Redis(uid, time_stamp)에 작성합니다.

2. 10명만 플래시 세일에 성공할 수 있다고 규정된 경우 Redis에 저장된 데이터의 길이를 확인하고 상한선을 초과하면 플래시를 즉시 폐기한다는 의미입니다. 판매가 완료되었습니다.

3. 마지막으로 Redis에 저장된 10개의 데이터를 무한 루프로 처리한 후 천천히 데이터를 가져와 mysql 데이터베이스에 저장합니다.

플래시 판매 영역은 데이터베이스에 많은 부담을 줍니다. 이러한 디자인이 없으면 mysql에서 쓰기 병목 현상이 발생합니다. Redis에서 대기열 목록을 사용한 다음 Redis에 플래시 판매 요청을 넣습니다. 마지막으로 웨어하우징 프로그램을 통해 데이터를 데이터베이스에 천천히 씁니다. 이러한 방식으로 트래픽이 균형을 이루고 mysql에 영향을 주지 않습니다. .너무 많은 압박감.

4. RabbitMQ

여기서는 먼저 RabbitMQ의 몇 가지 용도에 대해 설명하겠습니다. 앞서 플래시 세일 사례에 대해 이야기했을 때, 다른 프로그램이 동일한 레코드를 처리하는 것을 방지하기 위한 잠금 메커니즘에 대해 언급했습니다. 시스템 아키텍처가 매우 복잡하고 실시간으로 대기열을 읽는 여러 프로그램이 있거나 동시에 하나 이상의 대기열을 작동하는 여러 전송 프로그램이 있는 경우 이 프로그램을 다른 컴퓨터에 배포하고 싶은 경우에도 Redis 대기열을 사용하는 것은 다소 비효율적입니다. 지금 무엇을 해야 할까요? 문제를 더 잘 해결할 수 있는 좀 더 전문적인 메시지 대기열 시스템을 도입해야 합니다.

4.1 RabbitMQ 아키텍처 및 원칙

기능: AMQP의 완전한 구현, 클러스터 단순화, 지속성, 크로스 플랫폼 #🎜 🎜#

RabbitMQS는

1을 사용합니다. RabbitMQ 설치(rabbitmq-server, php-amqplib)

2 생산자는 메시지 채널#🎜 🎜 #

3. 소비자 프로세스 메시지

작업 대기열

아이디어: 메시지는 생산자에 의해 전송됩니다. 메시지 시스템은 작업을 메시지 대기열로 캡슐화한 다음 여러 소비자가 동일한 대기열을 사용할 수 있도록 허용합니다

이는 생산자와 소비자 간의 디커플링을 해결할 뿐만 아니라 소비자와 작업의 공유를 가능하게 하여 서버에 대한 부담을 줄입니다.

5. 요약

위의 내용은 주로 메시지 대기열의 개념, 원리 및 시나리오를 학습하는 데 중점을 둡니다. 사례를 분리하고 RabbitMQ의 간단한 사용을 이해합니다.

6. 질문

Redis와 메시지 서버 선택의 가장 큰 차이점은 무엇인가요?

제가 이해한 바에 따르면 Redis는 요청을 하나씩 처리합니다. Redis는 메시지 서버 IO 구현과 다릅니다. 하나는 동기식이고 다른 하나는 동기식 차단을 사용합니다. 메시지 서버는 비동기 비차단을 사용합니다.

Redis 관련 지식을 더 보려면 Redis 사용 튜토리얼 컬럼을 방문하세요!

위 내용은 메시지 대기열의 개념, 원리 및 사용 시나리오에 대한 자세한 소개(사례 포함)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!