메시지 대기열. 데이터베이스 대 전용 MQ

메시지 대기열에 대한 조언을 받고 있습니다. "작업"을 메시지 큐에 게시해야합니다.

원래 제안은 단지 SQL Server 인스턴스를 사용하고 그로부터 메시지를 처리하는 것입니다. 인터넷에서 읽은 모든 내용은 Message Queue에 데이터베이스를 사용하는 것이 확장 가능한 솔루션이 아니라고 제안합니다. 이러한 이유로 RabbitMQ 또는 다른 타사 MQ를 사용한다는 아이디어가 제안되었습니다.

고려해야 할 또 다른 사항은 "작업 처리"에 대한 요구 사항이 30 초 미만이 아니므로 작업을 수행하는 프로세스가 30 초마다 데이터베이스를 폴링한다는 것입니다. 나에게 이것은 나쁜 것처럼 보이지 않으며 데이터베이스에 큰 부하를 추가하지 않으면 정상적으로 작동합니다.

우리는 이미 사용할 수있는 데이터베이스를 고객에게 가지고 있으므로 클라이언트에 필요한 추가 지원을 많이 추가하지 않지만 타사 MQ를 추가하면 네트워크 구성 등에 대한 추가 지원이 있습니다. 많은 사용자가 있다는 점을 감안할 때 상당히 중요합니다.

내가 고려하고있는 다른 옵션은 사용자가 둘 중 하나를 선택할 수있게하는 것입니다. 소규모 사용자 인 경우 Sql Server 솔루션은 정상이지만 더 큰 사용자 인 경우 타사 MQ 솔루션을 구성 할 수 있습니다.

나는 어떤 해결책으로도 판매되지 않으며, 누군가 내가 고려해야하거나 조언해야 할 것이 있는지 궁금합니다.

인터넷에서 읽은 모든 내용은 Message Queue에 데이터베이스를 사용하는 것이 확장 가능한 솔루션이 아니라고 제안합니다.

" 확장하지 않기 때문에 X를 사용 하지 마십시오 "(링크에 불쾌감을 줄 수있는 언어가 포함되어 있음)에 의해 종종 무시되는 현실 은 규모가 항상 중요하지 않다는 것입니다. 지구 표면의 모든 응용 프로그램을 종합적으로 살펴보면 규모가 거의 중요 하지 않다고 말할 수 있습니다 .

귀하의 의견은 매일 20,000 건의 메시지를 인용하며 이는 초당 평균 0.23 개의 메시지 (4.3 초마다 하나씩)를 지원해야한다는 것을 의미합니다. 프로젝트가 예상보다 2 배 더 성공한 것으로 판명되면 요구 사항이 초당 23 개의 메시지를 처리하는 것으로 넘어갑니다. 이는 4 살짜리 휴대폰이나 라즈베리에 매우 편안한 작업입니다. 파이 그 위에 또 다른 몇 배의 크기를 두어도 여전히 높은 수준의 응용 프로그램은 아닙니다.

나는 (다행히도 부수적으로) 프로젝트가 너무 끝나는 시간이 너무 오래 걸리지 않았거나 시간이 전혀 걸리지 않은 스케일에 너무 집착하여 결국에는 그 규모에 짓눌 렸기 때문에 나쁜 결과를 겪었습니다. 다른 모든 것들과 마찬가지로 행복한 매체가 있습니다. 응용 프로그램의 대규모 확장이 현실적으로 가능하다고 생각한다면 적은 비용으로 추가 작업을 수행하여 현재 배포 하기에 저렴한 비 확장 부품에 대해 충분한 추상화를 구축하는 비즈니스 사례를 만드는 것이 어렵지 않아야합니다 . 이렇게하면 나중에 스케일이 필요할 경우 전체 시스템을 다시 생각할 필요없이 해당 부품을 도매로 교체 할 수있는 방법 (및 가능한 수익)이 있습니다.

응용 프로그램의 메시지 볼륨으로 인해 데이터베이스 나 메시지 큐 시스템이 겸손한 하드웨어에서도 땀을 흘리지는 않지만 메시지 트랜잭션을 처리하는 방법에 대한 다른 요구 사항이있을 수 있습니다. 이러한 요구 사항을 평가해야합니다.

Message Queue는 메시지 큐가 많을 때 실제로 자체적으로 들어와 메시지를 라우팅하고 둘 이상의 소비자에게 팬 아웃합니다.

하나의 '작업 대기열'에 '오프라인'을 처리하려는 경우 SQL 테이블이 정상적으로 작동합니다.

진행중인 작업을 표시하고 오래된 작업을 정리하며 시스템이 중지 될 때 경고하는 방법을 잊지 마십시오. 그러나 단일 대기열의 경우 이러한 작업을 수동으로 관리하면 별도의 큐 솔루션을 유지 관리하는 것보다 작업이 줄어 듭니다.

다른 언급했듯이 여기서 규모는 중요하지 않을 것입니다. 서로 다른 두 가지 저장 메커니즘을 사용하는 데 따른 문제는 트랜잭션 통합입니다.

전용 메시지 대기열을 사용하는 경우 실패 할 경우 다음 중 하나를 선택해야합니다.

1. 데이터는 mb에 있지만 db에는 없어야합니다.
2. 데이터는 db에는 있지만 mb에는 없어야합니다.
3. DB MQ간에 2 단계 커밋 또는 분산 트랜잭션 설정이 복잡 할 수 있음

일반 트랜잭션을 사용하여 한 곳에만 데이터를 저장하면 이러한 모든 문제가 사라집니다. 이러한 이유로 db를 작업 대기열로 사용하는 것이 완벽하게 훌륭한 솔루션입니다.

실용성을 위해 메시지 큐를 사용해야하는 주된 이유는 다음과 같습니다.

• 나는 바퀴를 재발 명 할 필요가 없었습니다. 데이터베이스를 사용하여 가장 간단한 메시지 대기열을 디자인하려면 최소한 2 시간의 사고와 몇 시간의 코딩 등이 필요합니다. 메시지 대기열을 구현하는 것과 비교하여 구성을 구성 및 / 또는 자동화하는 데 필요한 시간은 간단합니다.
• 메시지 대기열에는 생산자와 소비자를위한 훌륭하고 명확한 인터페이스가 있습니다. 이것은 아마도 응용 프로그램 작성에서 가장 중요한 것입니다. 인터페이스가 없으면 메시지 큐는 기본적으로 데이터 모음 일뿐입니다.
• 메시지 대기열은 향후 필요할 수있는 더 많은 기능을 제공합니다

사용자가 선택할 수 있도록 허용하는 것은 실제로 사용자가 신경 쓰지 않아야 할 구현 세부 사항입니다. 사용자는 동일한 인터페이스를 가져야하며 데이터베이스 또는 메시지 큐가 사용되는 경우 사용자와 차이가 없어야합니다. 단일 디자인이 설정되면 사용자가 선택할 수있는 선택은 자신의 요구를 수용하기 위해 몇 개의 노드를 배포해야 하는가입니다.

성능 테스트에 따라 초당 20k 작업을 처리 할 수있는 Mssql 메시지 큐 솔루션을 만들었으며 대부분 10 / 초가 필요합니다. 우선 순위를 실제로 가질 수 있다는 사실은 전용 메시지 큐가없는 기능이라고 생각합니다. 그리고 이것은 필자의 경우 주요 요구 사항이었습니다.