왜 Redis를 큐잉해야합니까?
Redis가 큐잉 시스템을 구현하기에 좋은 후보가 될 수 있다는 인상을 받고 있습니다. 지금까지는 폴링 또는 RabbitMQ와 함께 MySQL 데이터베이스를 사용했습니다. RabbitMQ를 사용하면 많은 문제가 발생했습니다. 클라이언트 라이브러리는 매우 가난하고 버그가 많으며 서버 관리 콘솔에 몇 가지 문제 등을 해결하는 데 너무 많은 개발자 시간을 투자하고 싶지 않습니다. 시스템이 큐를 지능적으로 지원하는 아키텍처를 가지고있는 한 우리는 아마도 밀리 초나 성능을 크게 향상 시키지는 않을 것입니다.
자, 이것이 배경입니다. 본질적으로 나는 매우 고전적이고 간단한 대기열 모델을 가지고 있습니다. 여러 생산자가 작업을 생산하고 여러 소비자가 작업을 소비하며 생산자와 소비자 모두 지능적으로 확장 할 수 있어야합니다. 순진한 방식으로 PUBSUB작동하지 않는 것으로 나타났습니다. 모든 구독자가 작업을 소비 하지 않기 때문에 한 명의 구독자가 작업을 받기를 원합니다 . 처음 BRPOPLPUSH에는 지능적인 디자인 인 것 같습니다 .
BRPOPLPUSH를 사용할 수 있습니까?
기본 디자인 BRPOPLPUSH은 하나의 작업 대기열과 진행 대기열이 있다는 것입니다. 소비자가 작업을 수신하면 원자 적으로 항목을 진행 큐로 푸시하고 작업을 완료하면 완료 LREM됩니다. 이렇게하면 클라이언트가 죽으면 작업이 블랙홀 링되는 것을 방지 할 수 있습니다. 예를 들어 소비자가 작업을 수행하는 데 시간이 오래 걸리는 문제와 대량의 작업이 있는지를 알려주는 문제가 있는지 알 수 있습니다.
그것은 보장합니다
- 작업은 정확히 한 소비자에게 전달됩니다
- 작업이 진행 대기열에 들어가므로 소비자에게는 블랙홀이되지 않습니다.
단점
- 내가 찾은 최고의 디자인
PUBSUB이 실제로 사용하지 않는다는 것이 다소 이상하게 보입니다. 그래서 나는 명백한 것을 놓치고있는 것처럼 느낍니다.PUBSUB작업을 두 번 소비하지 않고 사용하는 유일한 방법 은 작업이 도착했다는 알림을 푸시하는 것입니다. 소비자는이를 막을 수 없습니다RPOPLPUSH. - 한 번에 둘 이상의 작업 항목을 요청할 수 없으며 이는 성능 문제인 것 같습니다. 우리의 상황에는 큰 것이 아니지만 오히려이 작업은 높은 처리량이 나이 상황을 위해 설계된 것이 아니라고 분명히 말합니다
- 한마디로 : 바보 같은 것이 빠졌습니까?
또한 내가 다루는 언어이기 때문에 node.js 태그도 추가합니다. Node는 단일 스레드 및 비 차단 특성을 고려하여 구현시 약간의 단순화를 제공 할 수 있지만, 노드 Redis 라이브러리를 사용하고 있으며 솔루션은 강점과 약점에도 민감하거나 민감 할 수 있습니다.