Redis 기반으로 메시지 큐를 구현하는 방법

Message Queue는 동시 시스템의 리소스 일관성 문제를 해결하고 최대 처리 기능을 개선하며 메시지의 순서와 복구 가능성을 보장하는 데 자주 사용됩니다. 전달, 애플리케이션 분리, 비동기 통신 구현 등을 수행합니다. (추천 학습: Redis 비디오 튜토리얼)

시중에는 많은 MQ 애플리케이션이 있으며(예: Kafka, RabbitMQ, Disque) Redis 기반 구현을 위한 보다 일반적인 솔루션은 다음과 같습니다.

List 기반 LPUSH+BRPOP 구현

PUB/SUB, 구독/게시 모드

# 🎜🎜#Sorted-Set 기반 구현

스트림 유형 기반 구현

메시지 대기열 사용에는 생산자와 소비자가 있습니다. 생산자는 메시지 생성을 담당하고 소비자는 메시지 처리를 담당합니다.

Production은 메시지를 메시지 대기열에 넣는 것을 의미합니다.

소비란 메시지를 읽고 처리하는 것을 의미합니다. 일반적으로 메시지가 소비된 후에는 메시지 대기열에서 삭제되어야 합니다.

목록 기반 LPUSH+BRPOP 구현

Typical 명령은 다음과 같습니다.

LPUSH，将消息队列
BRPOP，从队列中取出消息，阻塞模式

은 FIFL 대기열을 기반으로 하는 일반적인 솔루션입니다. 그 중 LPUSH는 생산자가 하는 일이고, BRPOP은 소비자가 하는 일입니다.

이 모델에는 많은 장점이 있습니다.

구현이 간단함

Reids는 영구 메시지를 지원합니다. 그것은 손실되며 반복적으로 볼 수 있습니다(소비되지 않고 보기만 가능하며 LRANGE 유형 지침에 유의하십시오).

메시지 순서를 보장하려면 LPUSH 명령을 사용하세요.

RPUSH를 사용하면 메시지를 대기열의 시작 부분에 넣을 수 있습니다. 메시지 우선순위 지정의 목적은 간단한 메시지 우선순위 대기열을 구현하는 것입니다.

동시에 몇 가지 단점도 있습니다.

소비 확인 ACK를 하는 것이 더 번거롭습니다. 즉, 소비자가 다운타임 문제를 읽은 후 처리되지 않은 ACK를 처리하지 않도록 보장합니다. 예기치 않은 메시지 손실이 발생했습니다. 일반적으로 메시지가 처리되고 확인되도록 보류 목록을 직접 유지 관리해야 합니다.

일반적인 Pub/Disscribe 모드와 같은 방송 모드를 수행할 수 없습니다.

반복적으로 소비할 수 없으며, 한 번 소비하면 삭제됩니다

그룹 소비를 지원하지 않습니다. 비즈니스 로직 레이어에서 직접 해결해야 합니다

#🎜 🎜#

PUB/SUB, 구독/게시 모드

SUBSCRIBE，用于订阅信道
PUBLISH，向信道发送消息
UNSUBSCRIBE，取消订阅

생산자와 소비자는 동일한 채널(채널)을 통해 상호 작용합니다. 채널은 실제로 대기열입니다. 일반적으로 소비자는 여러 명입니다. 여러 소비자가 동일한 채널을 구독하면 생산자가 채널에 메시지를 게시하면 채널은 즉시 각 소비자에게 메시지를 하나씩 게시합니다. 채널은 소비자를 위한 다양한 채널이며 각 소비자는 동일한 메시지를 받을 수 있음을 알 수 있습니다. 일반적인 일대다 관계.

일반적인 장점은 다음과 같습니다.

일반적인 방송 모드, 메시지는 여러 소비자에게 게시될 수 있습니다

#🎜🎜 #Multi -채널 구독, 소비자는 동시에 여러 채널을 구독하여 여러 유형의 메시지를 받을 수 있습니다

메시지는 즉시 전송되며 메시지는 소비자가 읽을 때까지 기다릴 필요가 없습니다. 채널에서 게시한 메시지를 자동으로 수신합니다# 🎜🎜#

에도 몇 가지 단점이 있습니다.

메시지가 게시되면 수신할 수 없습니다. 즉, 게시할 때 클라이언트가 온라인 상태가 아니면 메시지가 손실되어 검색할 수 없습니다각 소비자가 받는 시간이 일정하다는 보장은 없습니다

#🎜🎜 #소비자라면 클라이언트에 메시지의 백로그가 있고, 어느 정도 강제로 연결이 끊기게 되어 예상치 못한 메시지 손실이 발생하게 됩니다. 주로 메시지 생성 속도가 소비 속도보다 훨씬 빠를 때 발생합니다

Pub/Sub 모드는 메시지 저장 및 메시지 백로그 서비스에는 적합하지 않지만 방송 처리에는 적합함을 알 수 있습니다 , 인스턴트 메시징 및 인스턴트 피드백 서비스.

SortedSet 주문 세트 기반 구현

ZADD KEY score member，压入集合
ZRANGEBYSCORE，依据score获取成员

주문 세트 솔루션은 세트를 사용하여 직접 메시지 ID를 결정할 때 더 일반적으로 사용됩니다. 메시지 ID의 순서와 단조로운 증가를 보장하기 위해 회원의 점수를 메시지 ID로 사용합니다. 일반적으로 타임스탬프 + 시퀀스 번호의 솔루션을 사용할 수 있습니다. 메시지 ID의 단조로운 증가를 보장하고 점수에 따라 정렬하는 SortedSet의 기능을 사용하여 정렬된 메시지 대기열을 생성합니다.

위 솔루션과 비교했을 때 메시지 ID를 맞춤 설정할 수 있다는 장점이 있는데, 이는 메시지 ID가 의미 있는 경우 더욱 중요합니다. 단점도 분명합니다. 중복된 메시지는 허용되지 않습니다(컬렉션이라고 생각하세요). 동시에 메시지 ID 결정 시 오류가 발생하면 메시지 순서가 잘못됩니다.

그래서 메시지 ID를 맞춤설정할 필요가 없다면 이 솔루션은 좀 쓸모가 없을 것 같습니다...

스트림 유형 기반 구현#🎜 🎜#

# 🎜🎜#이 스트림 유형 redis는 메시지 대기열을 구현하는 데 사용됩니다. 메시지 ID 자동 생성, 그룹 소비, ACK, 메시지 전송, 대기열 모니터링 등 핵심 메시지 대기열 기능을 지원합니다. 공부하세요!

위 내용은 Redis 기반으로 메시지 큐를 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!