PHP 메시지 대기열 구현 및 응용-PHP 튜토리얼-php.cn

우리 모두 알고 있듯이 웹사이트를 디자인할 때 사용자에게 보내는 '대량 문자 메시지', '주문 시스템의 대량 로그', '플래시 세일 디자인' 등을 접하게 됩니다. 서버는 이러한 순간적인 폭증을 감당할 수 없습니다. 이러한 상황은 반드시 보장되어야 합니다. 시스템을 정상적으로 사용하려면 "메시지 대기열"의 도움이 필요합니다. 이 글은 주로 메시지 큐(Message Queue)라는 개념을 통해 연구합니다.

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

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

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

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

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

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

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

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

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

　 @트래픽 피크 컷팅 사례 : Redis의 List 유형으로 플래시 세일을 구현합니다

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

1. 메시지 큐의 이해

1.1 메시지 큐의 개념

본질적으로 메시지 큐는 큐 구조를 가진 미들웨어입니다. 메시지가 이 미들웨어에 배치된 후 직접 반환될 수 있으며 시스템에서 즉각적인 처리가 필요하지 않습니다. 다른 프로그램이 데이터를 읽고 순서대로 하나씩 처리합니다.

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

1.2 핵심 구조

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

1.3 응용 시나리오

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

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

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

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

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

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

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

1.4 공통 대기열 구현 장점 및 단점

큐 미디어

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

　　2. redis와 같은 캐시(빠른 속도, 단일 메시지 패킷이 너무 큽니다. 효율성이 낮음)

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

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

　 1. 무한 루프 읽기: 구현하기 쉬우나 복구 불가능 실패 시 시간(플래시 판매, 상대적으로 중앙 집중식, 중앙 집중식 운영 및 유지 관리에 적합)

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

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

2. 디커플링 사례: 대기열 처리 "주문 시스템" 및 "배포 시스템"

프로그램 디커플링에 대해 간략히 설명: 프로그램 디커플링은 아내와 어머니를 방지하기 위한 것입니다. 물에 빠지는 것과 동시에 누구를 구할 것인가(웃음)

주문 과정에서는 두 가지 시스템을 설계할 수 있는데, 하나는 '주문 시스템'이고 다른 하나는 '배송 시스템'입니다. 우리 모두 온라인 쇼핑을 할 때 봤어야 했는데, 주문을 하고 나면 내 상품이 배송되는 모습을 배경에서 볼 수 있습니다. 이때 '배달 시스템'이 필요하다.

　 아키텍처를 구성할 때 "주문 시스템"과 "배송 시스템"을 함께 설계하면 우선 주문 시스템의 경우 시스템에 대한 부담이 커지기 때문에 몇 가지 문제가 있을 것입니다. 이러한 압력에 대한 즉각적인 대응이 필요합니다.

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

2.1 Architecture design

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

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

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

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

2.2 프로그램 흐름

3. 트래픽 피크 컷팅 사례: Redis의 리스트 방식은 플래시 세일을 구현합니다.

　 Redis는 메모리 기반이므로 속도가 매우 빠릅니다. Redis는 주기적으로 데이터를 하드 디스크에 쓰기 때문에 정전에 대한 걱정이 없습니다. 또한 Redis는 5가지 데이터 유형을 제공합니다. (문자열, 이중 연결 목록, 해시, 세트, 주문 세트)

일반적으로 redis는 플래시 세일, 급하게 구매하는 경우, 가격이 순간적으로 높아져서 대기해야 하는 경우에 적합합니다. 위로.

3.1 redis 데이터형의 리스트형

　redis의 리스트는 이중 연결 리스트이며, 데이터는 head 또는 tail에서 추가될 수 있습니다.

　 * LPUSH/LPUSHX: (/기존) 목록의 선두에 값을 삽입

　 * RPUSH/RPUSHX: (/기존) 목록의 꼬리에 값을 삽입

　 * LPOP: 제거하고 첫 번째 항목 가져오기 목록 요소 중

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

　 * LTRIM: 지정된 범위의 요소를 유지합니다.

　 * LLEN: 목록의 길이를 가져옵니다.

　 * LSET: 값을 설정합니다. the list element by index

　 * LINDEX: index로 list의 요소 가져오기

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

3.2 Architecture design

　간단한 구조의 flash-kill 프로그램 디자인.

　　1. 사용자가 플래시세일에 참여한 최초의 기록과 시간을 기록합니다.

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

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

3.3 코드 수준 설계

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

　　2. 플래시 세일은 10명만 성공할 수 있다고 규정한 경우 Redis에 저장된 데이터의 길이를 확인하여 상한을 초과한 경우 바로 폐기하면 플래시 세일이 완료된 것입니다.

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

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

IV.RabbitMQ

먼저 앞서 플래시 세일에 관해 이야기할 때 우리 시스템에서 다른 프로그램이 동일한 기록을 처리하지 못하도록 하는 잠금 메커니즘을 언급했습니다. 아키텍처는 매우 복잡합니다. 프로그램이 실시간으로 대기열을 읽거나 동시에 하나 이상의 대기열을 작동하는 여러 전송 프로그램이 있습니다. 이 경우에는 이러한 프로그램을 다른 시스템에 배포하고 싶습니다. Redis 대기열을 사용하는 것은 다소 부적절합니다. 지금 무엇을 해야 할까요? 문제를 더 잘 해결할 수 있는 좀 더 전문적인 메시지 대기열 시스템을 도입해야 합니다.

4.1 RabbitMQ 아키텍처 및 원칙

특징: AMQP 완벽 구현, 클러스터 단순화, 지속성, 크로스 플랫폼

　RabbitMQS 사용

　　1. RabbitMQ 설치(rabbitmq-server, php-am qplib)

2. 생산자는 메시지 채널

　에 메시지를 보냅니다. 3. 소비자는 메시지를 처리합니다.

작업 대기열

　　 아이디어: 생산자는 이를 메시지 시스템으로 보냅니다. 메시지 시스템은 작업을 메시지 대기열로 캡슐화한 다음 여러 소비자에 대해 동일한 대기열을 사용합니다.

　　이것은 생산자와 소비자 간의 분리를 해결할 뿐만 아니라 소비자와 작업의 공유를 실현하여 서버에 대한 부담을 줄입니다.

5. 요약

위 내용은 주로 메시지 대기열의 개념, 원리 및 시나리오를 학습하는 데 중점을 둡니다. 디커플링 케이스와 피크 클리핑 케이스, 그리고 RabbitMQ의 간단한 사용법을 이해합니다.

6. Question

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

　 Redis는 요청을 하나씩 처리하는 것으로 알고 있습니다. Redis는 메시지 서버 IO 구현과 다릅니다. 하나는 동기식 차단을 사용하고, 다른 하나는 비동기식 차단을 사용합니다. -블로킹.

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

큐 미디어:

Mysql: 높은 신뢰성, 구현 용이, 느린 속도
Redis: 단일 대형 메시지 패키지에 대한 빠르고 낮은 효율성
메시지 시스템: 강력한 전문성, 신뢰성, 학습 높은 비용(예: RabbtiMQ)

메시지 처리를 위한 트리거 메커니즘:

무한 루프 읽기: 구현이 쉽고 오류 발생 시 시간 내에 복구할 수 없음
예약된 작업: 압력이 균등하게 분산되며 상한값이 있습니다. 처리 용량 제한. (가장 큰 단점: 위치결정 작업의 시간 간격과 처리되는 데이터를 정확하게 파악해야 한다. 이전 작업이 완료되기 전에 다음 작업이 시작되었다고 볼 수 없다.)

데몬 프로세스: PHP-FPM과 유사 및 PHP-CGI, 쉘 지식 필요