PostgreSQL과 같은 데이터베이스에서 RabbitMQ와 같은 메시지 브로커가 필요한 이유는 무엇입니까?

Celery 와 같은 스케줄링 시스템을위한 작업 / 메시지 큐를 만드는 데 사용할 수있는 RabbitMQ 와 같은 메시지 브로커 를 처음 사용합니다 .

자, 여기 질문이 있습니다 :

• PostgreSQL 에서 새로운 작업을 추가하고 Celery와 같은 소비자 프로그램 에서 사용할 수있는 테이블을 만들 수 있습니다.

• 왜 지구상에서 RabbitMQ와 같은 완전히 새로운 기술을 설치하고 싶습니까?

PostgreSQL과 같은 데이터베이스가 분산 환경에서 작동 할 수 있기 때문에 스케일링이 답이 될 수 없다고 생각합니다.

데이터베이스가 특정 문제에 어떤 문제를 일으키는 지 봤습니다.

• 폴링은 데이터베이스 사용량이 적고 성능이 낮게 유지
• 테이블 잠금-> 다시 낮은 성능
• 수백만 행의 작업-> 다시 말하면 폴링 성능이 낮습니다.

이제 RabbitMQ 또는 이와 같은 다른 메시지 브로커는 이러한 문제를 어떻게 해결합니까?

또한 AMQP프로토콜이 다음과 같은 것으로 나타났습니다 . 그게 뭐에요?

Redis 를 메시지 브로커로도 사용할 수 있습니까 ? RabbitMQ보다 Memcached와 더 유사합니다.

이것에 약간의 빛을 비추십시오!

토끼의 대기열은 메모리에 상주하므로 데이터베이스에서이를 구현하는 것보다 훨씬 빠릅니다. (양호한) 전용 메시지 큐는 스로틀 링 / 흐름 제어와 같은 필수 큐잉 관련 기능과 서로 다른 라우팅 알고리즘을 선택할 수있는 기능을 제공하여 커플의 이름을 지정해야합니다 (토끼가 제공하는 것 이상). 프로젝트의 크기에 따라 메시지 전달 구성 요소를 데이터베이스와 분리하여 하나의 구성 요소에 많은 부하가 발생하는 경우 다른 구성 요소의 작업을 방해하지 않아도됩니다.

언급 한 문제에 관해서는 :

• 데이터베이스를 흐릿하고 낮은 성능으로 유지하는 폴링 : Rabbitmq를 사용하여 생산자는 폴링보다 훨씬 성능이 뛰어난 소비자에게 업데이트를 푸시 할 수 있습니다 . 데이터는 필요할 때 소비자에게 간단히 전송되므로 낭비되는 점검이 필요 없습니다.

• 테이블 잠금-> 다시 낮은 성능 : 잠글 테이블이 없습니다. : P

• 수백만 행의 작업-> 다시 폴링 성능이 낮습니다. 위에서 언급 한 것처럼 Rabbitmq는 RAM에 상주하므로 더 빠르게 작동하며 흐름 제어를 제공합니다. 필요한 경우 RAM이 부족한 경우 디스크를 사용하여 메시지를 임시로 저장할 수도 있습니다. 2.0 이후 Rabbit은 RAM 사용량이 크게 향상되었습니다. 클러스터링 옵션도 사용할 수 있습니다.

AMQP와 관련하여 정말 멋진 기능은 "교환"이며 다른 교환으로 라우팅하는 기능입니다. 따라서 유연성이 향상되고 확장시 매우 유용 할 수있는 다양한 정교한 라우팅 유형을 만들 수 있습니다. 좋은 예를 보려면 다음을 참조하십시오.

_{(출처 : springsource.com )}

및 : http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

마지막으로, redis와 관련하여 예, 메시지 브로커로 사용될 수 있으며 잘 할 수 있습니다. 그러나 rabbitmq는 완전한 기능을 갖춘 엔터프라이즈 급 전용 메시지 대기열이되기 위해 처음부터 구축 되었기 때문에 redis보다 많은 메시지 큐잉 기능을 제공합니다. 반면에 Redis는 주로 메모리 내 키-밸류 저장소로 만들어졌습니다 (현재보다 훨씬 많은 일을하지만 스위스 군용 칼이라고도 함). 그래도 소규모 프로젝트에 대해 Redis로 좋은 결과를 얻는 많은 사람들을 읽거나 들었지만 큰 응용 프로그램에서는 그에 대해 많이 들어 보지 못했습니다.

다음은 장기 폴링 채팅 구현에 사용되는 redis의 예입니다. http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/

PostgreSQL 9.5

PostgreSQL 9.5는 다음을 통합 SELECT ... FOR UPDATE ... SKIP LOCKED합니다. 따라서 작업 큐 시스템을 훨씬 간단하고 쉽게 구현할 수 있습니다. 다른 세션이 잠그지 않은 'n'개의 행을 간단하게 가져오고 작업이 완료되었다는 확인을 커밋 할 때까지 잠금을 유지하기 때문에 더 이상 외부 큐 시스템이 필요하지 않을 수 있습니다. 외부 조정이 필요한 경우 2 단계 트랜잭션에서도 작동합니다.

외부 큐잉 시스템은 유용한 기능을 제공하여 미리 준비된 기능, 검증 된 성능, 다른 시스템과의 통합, 수평 스케일링 및 페더레이션 옵션 등을 제공합니다. 그럼에도 불구하고 더 이상 간단한 경우에는 더 이상 필요하지 않습니다.

이전 버전

그러한 도구는 필요 하지 않지만 도구를 사용하면 삶을 더 쉽게 만들 수 있습니다. 데이터베이스에서 큐잉을 수행하는 것은 쉬워 보이지만 실제로는 고성능의 안정적인 동시 큐잉이 실제로 관계형 데이터베이스에서 제대로 수행하기 어렵다는 것을 알게 될 것 입니다.

PGQ 와 같은 도구 가 존재하는 이유 입니다.

당신은 사용하여 PostgreSQL을 폴링 제거 할 수 LISTEN및 NOTIFY있지만, 높은 동시 작업을 보존하고 삽입을 차단하지 않으면 서 그 단 하나의 소비자에게 큐의 맨 오프 항목 밖으로 안정적으로 나눠의 문제를 해결하지 않습니다. 당신이 생각하는 모든 간단하고 명백한 해결책은 실제로는이 문제를 해결하지 못할 것이며, 단일 작업자 대기열 가져 오기의 덜 효율적인 버전으로 퇴보하는 경향이 있습니다.

고도로 동시 다중 작업자 큐 페치가 필요하지 않은 경우 PostgreSQL에서 단일 큐 테이블을 사용하는 것이 전적으로 합리적입니다.