왜 우리는 래빗과 같은 메시지 브로커가 필요합니까?PostgreSQL과 같은 데이터베이스를 통한 MQ?

왜 우리는 래빗과 같은 메시지 브로커가 필요합니까?PostgreSQL과 같은 데이터베이스를 통한 MQ?

저는 래빗과 같은 메시지 브로커가 처음입니다.셀러리와 같은 스케줄링 시스템에 대한 작업/메시지 큐를 만드는 데 사용할 수 있는 MQ입니다.

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

• Postgre에서 테이블을 만들 수 있습니다.새 작업에 추가할 수 있고 셀러리와 같은 소비자 프로그램에서 사용할 수 있는 SQL.

• 도대체 왜 제가 RabbitMQ와 같은 완전히 새로운 기술을 설정하려고 합니까?

Postgre와 같은 데이터베이스 때문에 확장이 답이 될 수 없다고 생각합니다.SQL은 분산 환경에서 작동할 수 있습니다.

데이터베이스가 특정 문제에 대해 어떤 문제를 제기하는지 검색해보니 다음과 같습니다.

• 폴링은 데이터베이스를 계속 사용하고 낮은 성능을 유지합니다.
• 테이블 잠금 -> 다시 낮은 성능
• 수백만 줄의 작업 -> 다시, 폴링 성능이 낮습니다.

자, 어떻게 토끼가MQ 또는 기타 메시지 브로커가 이러한 문제를 해결합니까?

또한, 나는 그것을 발견했습니다.AMQP프로토콜은 그것이 따르는 것입니다.그게 뭐가 좋아요?

Redis를 메시지 브로커로도 사용할 수 있습니까?나는 그것이 RabbitMQ보다 Memcached와 더 유사하다고 생각합니다.

이것 좀 비춰주세요!

Rabbit의 대기열은 메모리에 상주하므로 데이터베이스에서 이를 구현하는 것보다 훨씬 빠릅니다.(좋은) 전용 메시지 큐는 또한 조절/흐름 제어와 같은 필수적인 큐잉 관련 기능을 제공해야 하며, 커플 이름을 지정하기 위해 다른 라우팅 알고리즘을 선택할 수 있는 기능을 제공해야 합니다(토끼가 이러한 기능 등을 제공합니다).프로젝트의 크기에 따라 메시지 전달 구성요소가 데이터베이스와 분리되어 한 구성요소의 부하가 높을 경우 다른 구성요소의 작업을 방해하지 않도록 할 수도 있습니다.

말씀하신 문제에 대해서는 다음과 같습니다.

• 폴링으로 인해 데이터베이스 사용량이 많고 성능이 낮습니다.Rabbitmq를 사용하여 생산자는 투표보다 훨씬 더 성능이 좋은 업데이트를 소비자에게 푸시할 수 있습니다.데이터는 필요할 때 소비자에게 전송되므로 불필요한 검사가 필요하지 않습니다.

• 테이블 잠금 -> 다시 낮음 수행:잠글 테이블이 없습니다.p

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

AMQP와 관련하여, 저는 정말 멋진 특징은 "교환"과 다른 거래소로 라우팅할 수 있는 능력이라고 말하고 싶습니다.따라서 유연성이 향상되고 확장 시 매우 유용한 다양한 라우팅 유형을 만들 수 있습니다.좋은 예는 다음을 참조하십시오.

_{(출처: springsource.com )}

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

마지막으로, 레디스와 관련하여, 네, 그것은 메시지 브로커로 사용될 수 있고, 잘 할 수 있습니다.그러나 Rabbitmq는 완전한 기능을 갖춘 엔터프라이즈 수준의 전용 메시지 큐로 처음부터 구축되었기 때문에 Rabbitmq는 Redis보다 더 많은 메시지 큐 기능을 가지고 있습니다.반면에 Redis는 주로 메모리 내 키 값 저장소로 만들어졌습니다(지금은 그보다 훨씬 더 많은 기능을 수행하지만, 스위스 군용 칼이라고도 함).여전히, 저는 많은 사람들이 Redis와 소규모 프로젝트에서 좋은 결과를 얻는 것을 읽거나 들었습니다. 그러나 대규모 애플리케이션에서는 별로 들어본 적이 없습니다.

다음은 Red가 오랜 기간 채팅 구현에 사용된 예입니다. http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/

PostgreSQL 9.5

9에는 Postgre가 통합되어 있습니다.SQL 9.5 버전SELECT ... FOR UPDATE ... SKIP LOCKED따라서 작업 대기열 시스템을 훨씬 더 간단하고 쉽게 구현할 수 있습니다.이제 다른 세션이 잠그지 않은 'n'개의 행을 가져와 작업 완료를 확인할 때까지 잠글 수 있으므로 더 이상 외부 대기열 시스템이 필요하지 않을 수 있습니다.외부 조정이 필요한 경우 2단계 트랜잭션에서도 작동합니다.

외부 대기열 시스템은 통조림 기능, 입증된 성능, 다른 시스템과의 통합, 수평 확장 및 연합 옵션 등을 제공하여 여전히 유용합니다.그럼에도 불구하고 단순한 경우에는 더 이상 필요하지 않습니다.

이전 버전

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

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

Postgre에서 투표를 없앨 수 있습니다.사용한 SQLLISTEN그리고.NOTIFY그러나 이는 매우 동시적인 작업을 유지하고 삽입물을 차단하지 않으면서 정확히 한 명의 소비자에게 항목을 안정적으로 전달하는 문제를 해결하지 못할 것입니다.여러분이 이 문제를 해결할 수 있을 것이라고 생각하는 모든 간단하고 명백한 해결책들은 실제로 현실 세계에서는 그렇지 않으며, 단일 작업자 대기열 가져오기의 비효율적인 버전으로 전락하는 경향이 있습니다.

다중 작업자 대기열을 동시에 가져올 필요가 없는 경우 Postgre에서 단일 대기열 테이블 사용SQL은 전적으로 합리적입니다.

언급URL : https://stackoverflow.com/questions/13005410/why-do-we-need-message-brokers-like-rabbitmq-over-a-database-like-postgresql