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

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

언급 한 문제에 관해서는 :

• 데이터베이스를 흐릿하고 낮은 성능으로 유지하는 폴링 : 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/

답변