2009-12-03 7 views
16

우리는 대용량의 미디어 처리 (이미지, 비디오)와 이메일 출력 등 많은 프로젝트를 준비하고 있습니다. 일반적으로 우리는 "email_queue"그리고 우리는 cron을 사용하여 테이블에서 큐를 처리하는 스크립트를 실행합니다.CRON을 통한 메시지 대기열 대 DB 테이블 대기열

저는 Beanstalkd와 같은 Message Queue 시스템에서 많은 것을 읽었으며 심지어 설정했습니다. 사용하기 쉽고 좋았습니다. 문제는 내가 뭔가를 놓치고 있는지 확신 할 수 없다는 것입니다.

누군가가 테이블과 CRON 대신 큐 시스템을 사용하면 얻을 수있는 이점에 대해 자세히 설명 할 수 있습니까? 나는 그들이 실제로 무엇인지 보지 못하기 때문에.

감사

답변

6

메시지 큐 (적어도 분포 하나, 예를 들어, RabbitMQ)는 당신에게 물리적 노드에 작업을 분배 할 수있는 기능을 제공합니다. 작업을 큐에서 제거하고 처리하려면 각 노드에 프로세스가 있어야합니다.

귀하의 요구 사항에 따라 궁극적으로 무너집니다. 메시지 대기열을 사용하면 관리가 용이 ​​한 솔루션을 대규모로 구현할 수 있습니다. 노드를보다 쉽게 ​​분리 할 수 ​​있습니다.

물론 학습 곡선이 있습니다 ... 그래서 다시 목표 목표로 돌아옵니다. (그리고 경우) 구현을 변경하고자 할 때까지 각 노드에서 여전히 크론/DB 테이블을 재사용 할 수


참고. 일 때 디커플링을 적용하면 그 점이 좋습니다.

+1

안녕하세요, 일종의 이해하지만 테이블/cron으로 동일한 작업을 수행 할 수 없으며 원격으로 db에 연결하고 다른 컴퓨터에서 cron을 실행할 수 있습니까? – Bowen

+0

당신은 당연히 그러나 그 때 이것은 "결합 된 해결책"인 것처럼 보일 수 있습니다. 메시지 대기열 접근 방식을 사용하면 노드 구현에 대해 더욱 분리 될 수 있습니다. 이것은 좋은 것일 수 있습니다. – jldupont

+0

Coupled beacuse는 데이터베이스 x를 형식 y와 함께 사용하거나 큐 a를 형식 b로 사용하기 때문에? 좋은 질문 @bowen. – graffic

19

차이 :

  1. 메시지가 즉시 전달 될 수 큐에 넣어되면. 따라서 cron이 일반적으로 5 분마다 실행되면 대기열 처리 속도가 빨라질 수 있습니다.

  2. 큐 시스템이 트랜잭션을 지원하면 처리가 실패 할 경우 자동으로 메시지를 다시 전달합니다.

  3. 대기열에있는 항목을 쿼리하는 것이 더 어려울 수 있습니다. 데이터베이스 테이블은 좋은 검색 방법 (sql)을 가지고 있습니다.

  4. 메시지를 처리하는 서버/프로세스/스레드가 여러 개인 경우 대기열 시스템에서 메시지가 그 중 하나에만 전달되는지 확인합니다. DB를 표하면

+2

좋은 지적, 제 의견으로는 더 좋은 대답입니다. –

4

첫째, 큐은 종종 실제 DB 테이블에 의해 백업됩니다 및 메시지 내구성을 유지할 수 있습니다 (... 잠금, 플래그, 등) 응용 프로그램 코드를 통해이 문제를 해결할 필요가있다. 대기열은 비동기식으로 수행해야하는 작업을 중단시키는 자연스러운 방법입니다. 처음부터 해당 보안 주체를 디자인하면 매우 강력합니다.

테이블 (엔티티)이 하드 열 (속성) 집합을 갖고 있다는 것 외에도 큐를 구성하는 레코드 세트로 구성된이 테이블은 모두 당신이 사용하는 것들의 목록 일뿐입니다 정규 큐 (queue)로서의 테이블 큐 (queue-as-a-table).

MQ는 일반적으로 메시지 자체에 대한 액세스를 동기화하지만 다른 멋진 기능을 추가합니다 (다음 단계를 얻으려면 SQL에서이 작업을 수행 할 수도 있고 수행하지 않을 수도 있습니다).

나는 cron/table 메커니즘을 POLL 기반으로, MQ를 EVENT 기반으로 생각하고 싶다.

이점 내 의견으로는 큐의은 sync'ing, 상태 업데이트를 처리한다는 것입니다. MQ는 "브로드 캐스트"(주제)로 설정되거나 소비자 또는 청취자 그룹에 메시지를 사용 가능하게 할 수 있습니다.

MQ하지만 비동기 적으로 cron 창간에 작동합니다. 다음 cron 작업이 실행되기 전에 테이블에서 처리하는 메시지 수를 완료하고 이전 작업을 수행하려고 시도하는 것을 어떻게 알 수 있습니까?

MQ의 여러 소비자를 사용하면 적합하다고 생각되는대로 작업을 확장 할 수 있습니다. 위의 예에서 OS의 프로세스 대기열에있는 것과 동일한 load average이 원하는 것보다 크다면 다른 소비자가 해당 부하를 처리하도록 준비하고 메트릭 요구에 따라 오프라인으로 가져 오게 할 수 있습니다.

MQ는 메시지 우선 순위 및 성능과 같은 다른 작동 매개 변수를 갖도록 설정할 수 있습니다 (일부 큐는 메모리에 남아 있고 다른 큐는 디스크에 남아 있습니다).

아래쪽은 (이미 언급했듯이) 큐가 때때로 쿼리하기 어렵고 메트릭을 얻는 데 어려움이 있다는 것을 의미합니다. 나는 항상 SQL을 사용하여 대기열을 볼 수 있도록 DB 백업 저장소가있는 MQ 시스템을 찾습니다.

1

이것은 자주 묻습니다. 데이터베이스가 마음에 들면 MQ를 갈 이유가 없습니다. Here's one example thread.

데이터 요구 사항에 예외적으로 높은 볼륨이 포함되어 있지 않으면 학습 곡선을 피할 수 있습니다. 타이머가있는 프로세스보다는 cron 일 가능성이 낮습니다 (타이머가있는 다중 프로세스가 훨씬 적음).