Redis를 통해 메시지 대기열을 구현하는 방법은 무엇입니까?

Question

대기열에 Redis를 사용하는 이유는 무엇입니까?

저는 Redis가 대기열 시스템 구현에 적합한 후보가 될 수 있다고 생각합니다.지금까지 우리는 폴링 또는 RabbitMQ와 함께 MySQL 데이터베이스를 사용해 왔습니다.RabbitMQ를 사용하면서 우리는 많은 문제를 겪었습니다. 클라이언트 라이브러리는 매우 열악하고 버그가 많으며 이를 해결하는 데 너무 많은 개발자 시간을 투자하고 싶지 않으며 서버 관리 콘솔과 관련된 몇 가지 문제 등이 있습니다.그리고 적어도 당분간은 우리는 밀리초 단위로 성능을 파악하거나 심각하게 성능을 향상시키지는 않습니다. 따라서 시스템에 대기열을 지능적으로 지원하는 아키텍처가 있는 한 우리는 아마도 좋은 상태일 것입니다.

좋아요, 그게 배경이에요.본질적으로 저는 매우 고전적이고 단순한 대기열 모델을 가지고 있습니다. 여러 생산자가 작업을 생성하고 여러 소비자가 작업을 소비하며 생산자와 소비자 모두 지능적으로 확장할 수 있어야 합니다.순진한 것으로 밝혀졌습니다 PUBSUB 내가 원하지 않기 때문에 작동하지 않습니다 모두 구독자가 일을 소비하기를 원합니다. 하나 구독자가 작품을 받을 수 있습니다.첫 번째 통과에서는 다음과 같이 보입니다. BRPOPLPUSH 지능적인 디자인이다.

BRPOPLPUSH를 사용할 수 있나요?

기본 디자인을 갖춘 BRPOPLPUSH 하나의 작업 대기열과 진행 대기열이 있습니다.소비자가 작업을 받으면 해당 항목을 진행 대기열에 원자적으로 푸시하고, 작업을 완료하면 LREM'앉다.이를 통해 클라이언트가 사망할 경우 작업 블랙홀을 방지하고 모니터링을 매우 쉽게 만들 수 있습니다. 예를 들어 작업량이 많은지 여부를 알려주는 것 외에도 소비자가 작업을 수행하는 데 오랜 시간이 걸리는 문제가 있는지 알 수 있습니다.

그것은 보장한다

• 작업은 정확히 한 명의 소비자에게 전달됩니다.
• 작업이 진행 대기열에 들어가므로 소비자가 블랙홀에 들어갈 수 없습니다.

단점

• 내가 찾은 최고의 디자인이 실제로 사용되지 않는다는 것이 나에게는 다소 이상하게 보입니다. PUBSUB 이는 Redis를 통한 큐잉에 관한 대부분의 블로그 게시물이 중점을 두는 것 같기 때문입니다.그래서 나는 분명한 것을 놓치고 있는 것 같은 느낌이 듭니다.내가 사용하는 유일한 방법은 PUBSUB 작업을 두 번 소비하지 않고 단순히 작업이 도착했다는 알림을 푸시하는 것입니다. 그런 다음 소비자는 이를 비차단 방식으로 수행할 수 있습니다. RPOPLPUSH.
• 한 번에 두 개 이상의 작업 항목을 요청하는 것은 불가능하며 이는 성능 문제인 것 같습니다.우리 상황에서는 큰 문제는 아니지만 이 작업은 높은 처리량 또는 이 상황을 위해 설계되지 않았음을 분명히 나타냅니다.
• 간단히 말해서: 내가 뭔가 멍청한 걸 놓치고 있는 걸까?

또한 node.js 태그를 추가합니다. 왜냐하면 이것이 제가 주로 다루는 언어이기 때문입니다.Node는 단일 스레드 및 비차단 특성을 고려할 때 구현 시 일부 단순화를 제공할 수 있지만 더 나아가 저는 node-redis 라이브러리를 사용하고 있으며 솔루션도 Node-redis의 강점과 약점에 민감해야 하거나 민감할 수 있습니다.

Answer 1

node.js의 메시지 대기열에 대해 Redis를 사용하려면 해당 모듈을 사용하지 않으려면 rsmq - 노드에 대한 간단한 메시지 대기열의 Redis.이 질문이 묻는 시점에서는 사용할 수 없었지만 오늘은 실행 가능한 옵션입니다.

실제로 구현 queue를 자신의 질문에 명시한 것처럼 큐를 직접 읽으려면 RSMQ의 원인을 읽을 수 있습니다..

참조 :

• http://smrchy.github.io/rsmq/
• https://github.com/smrchy/rsmq
• https://www.npmjs.com/package/rsmq

Answer 2

나는 지금까지 몇 가지 어려움에 봉착했습니다. 여기에 기록하고 싶습니다.

재연결 로직을 어떻게 처리하나요?

이는 메시지 큐를 설계하고 구현할 때 어려운 문제이자 특히 어려운 문제입니다.메시지는 소비자가 오프라인일 때 어딘가에 대기열에 들어갈 수 있어야 하므로 단순한 pub-sub로는 충분히 강력하지 않으며 소비자는 청취 상태에서 다시 연결해야 합니다. 차단 팝은 비멱등성 청취 상태이기 때문에 유지하기 어려운 상태입니다..듣기는 멱등성 작업이어야 하지만 차단 팝과 관련된 연결 끊김을 처리할 때 연결 끊김이 작업이 성공한 직후에 발생했는지 아니면 작업이 실패하기 직전에 발생했는지 매우 열심히 생각하는 즐거움을 누릴 수 있습니다.극복할 수 없는 것은 아니지만 바람직하지 않습니다.

또한 청취 작업은 다음과 같아야 합니다. 최대한 간단하게. 이상적으로는 다음과 같은 속성을 가져야 합니다.

• 듣는 것은 멱등적이다.
• 소비자는 언제나 청취 및 제한 논리는 청취 논리 코드 외부에서 처리됩니다.RabbitMQ는 소비자가 가질 수 있는 확인되지 않은 메시지 수를 제한하도록 하여 이를 캡슐화합니다.
  특히 나는 블로킹 팝에 다시 들어가는 것이 이전 작업의 성공에 달려 있는 열악한 디자인을 선택했는데, 이는 부서지기 쉽고 열심히 생각해야 했습니다.

저는 이제 Redis PUBSUB + RPOPLPUSH 솔루션을 선호합니다.이는 작업 알림과 작업 소비를 분리하여 깨끗한 청취 솔루션을 제외할 수 있게 해줍니다. PUBSUB은 작업 통지에만 책임이 있습니다. RPOPLPUSH의 원자적 특성은 소비를 담당하고 정확히 한 명의 소비자에게 작업을 위임합니다.처음에는 이 해결 방법이 차단 팝에 비해 불필요하게 복잡해 보였지만 이제는 그 복잡성이 전혀 불필요한 것이 아니라는 것을 알 수 있습니다.그것은 어려운 문제를 해결하고 있었습니다.

그러나 이 솔루션은 그다지 간단하지 않습니다.

• 소비자는 재연결 작업도 확인해야 합니다.
• 소비자는 중복성을 위해 어쨌든 새로운 작업에 대한 여론 조사를 원할 수 있습니다.폴링이 실제로 성공하면 경고가 발생해야 합니다. 이는 PUBSUB의 소비와 RPOPLPUSH의 폴링 사이에만 발생해야 하기 때문입니다.따라서 많은 폴링 성공은 구독 시스템이 손상되었음을 나타냅니다.

PUBSUB/RPOPLPUSH 디자인에도 크기 조정 문제가 있습니다. 모든 소비자는 다음과 같은 간단한 알림을 받습니다. 모든 이는 불필요한 병목 현상이 있음을 의미합니다.나는 채널을 사용하여 작업을 분할하는 것이 가능하다고 생각하지만 아마도 잘 작동하기에는 까다로운 디자인일 것입니다.

Answer 3

따라서 Redis 대신 RabbitMQ를 사용하기로 선택한 가장 큰 이유는 실패 시나리오와 클러스터링입니다.

이 기사가 이에 대해 가장 잘 설명하므로 링크만 제공하겠습니다.

https://apyr.com/posts/283-jepsen-redis

Redis sentinel과 최근의 redis 클러스터링은 대기열에 대한 잘못된 선택으로 만드는 매우 기본적인 여러 오류 시나리오를 처리할 수 없습니다.

RabbitMQ에는 자체적인 문제가 있지만 프로덕션 환경에서는 믿을 수 없을 정도로 견고하고 좋은 메시지 대기열이라고 합니다.

토끼에 대한 게시물은 다음과 같습니다.

https://apyr.com/posts/315-jepsen-rabbitmq

CAP 이론(일관성, 가용성, 파티션 처리)을 보면 3개 중 2개만 선택할 수 있습니다.우리는 메시지 로드 시 CP(일관성 및 파티션 처리)를 위해 RMQ를 활용하고 있습니다. 사용할 수 없는 경우에도 세상의 끝은 아닙니다.메시지를 잃지 않기 위해 메시지를 잃지 않기 위해 파티션 처리에 무시를 사용합니다.소스가 UUID를 관리하므로 중복을 처리할 수 있습니다.