[rabbitmq] Kafka를 통해 RabbitMQ를 사용해야하는 이유가 있습니까?

Kafka 대신 RabbitMQ를 평가하라는 요청을 받았지만 Kafka보다 더 나은 일을하는 이유를 찾기가 어렵다는 것을 알았습니다. 처리량, 내구성, 대기 시간 또는 사용 편의성이 실제로 더 나은지 아는 사람이 있습니까?



답변

RabbitMQ는 AMQP, MQTT, STOMP 등과 같은 여러 프로토콜을 지원 하는 견고한 범용 메시지 브로커 입니다. 높은 처리량을 처리 할 수 ​​있습니다. RabbitMQ의 일반적인 사용 사례는 백그라운드 스캔 또는 파일 스캔 , 이미지 스케일링 또는 PDF 변환 과 같은 장기 실행 작업을 처리하는 것 입니다. RabbitMQ는 또한 마이크로 서비스간에 사용되며, 애플리케이션 간 통신 수단으로 사용되어 메시지를 전달하는 병목 현상을 방지합니다.

Kafka는 대용량 데이터 스트림 및 재생에 최적화 된 메시지 버스 입니다. 많은 양의 데이터를 이동하거나 실시간으로 데이터를 처리하거나 일정 기간 동안 데이터를 분석해야하는 경우 Kafka를 사용하십시오. 즉, 데이터를 수집, 저장 및 처리해야하는 곳입니다. 예를 들어 웹샵에서 사용자 활동을 추적하고 구매 제안 품목을 생성하려는 경우가 있습니다. 또 다른 예는 추적, 수집, 로깅 또는 보안을위한 데이터 분석입니다.

Kafka는 애플리케이션이 디스크에서 스트리밍 된 데이터를 처리하고 재 처리 할 수 있는 내구성있는 메시지 브로커 로 볼 수 있습니다 . Kafka는 매우 간단한 라우팅 접근 방식을 가지고 있습니다. RabbitMQ는 복잡한 방식으로 소비자에게 메시지를 라우팅해야하는 경우 더 나은 옵션을 제공합니다. 오프라인 일 수있는 배치 소비자 또는 대기 시간이 짧은 메시지를 원하는 소비자를 지원해야하는 경우 Kafka를 사용하십시오. 

Kafka에서 데이터를 읽는 방법을 이해하려면 먼저 소비자와 소비자 그룹을 이해해야합니다. 파티션을 사용하면 데이터를 여러 노드로 분할하여 주제를 병렬화 할 수 있습니다. 파티션의 각 레코드는 고유 한 오프셋으로 할당 및 식별됩니다. 이 오프셋은 파티션의 레코드를 가리 킵니다. 최신 버전의 Kafka에서 Kafka는 파티션의 각 레코드에 대한 숫자 오프셋을 유지합니다. Kafka의 소비자는 주기적으로 오프셋을 자동 커밋하거나이 커밋 된 위치를 수동으로 제어하도록 선택할 수 있습니다. RabbitMQ는 소비 / 확인 / 확인되지 않은 메시지에 대한 모든 상태를 유지합니다. 메시지가 잠기면 큐에서 간단히 제거되는 RabbitMQ의 경우보다 Kafka가 이해하기가 더 복잡하다는 것을 알았습니다.

RabbitMQ의 대기열은 비어있을 때 가장 빠르며 Kafka는 오버 헤드가 거의없이 많은 양의 데이터를 유지합니다. Kafka는 대량의 메시지를 보관 및 배포하도록 설계되었습니다. RabbitMQ에서 대기열이 매우 길면 지연 대기열을 볼 수 있습니다 .

Kafka는 수평 확장 (기계를 추가하여 확장)을 염두에두고 처음부터 구축되었으며 RabbitMQ는 주로 수직 확장 (전력을 추가하여 확장)을 위해 설계되었습니다.

RabbitMQ에는 웹 브라우저에서 RabbitMQ 서버를 모니터링하고 처리 할 수있는 사용자 친화적 인 인터페이스가 내장되어 있습니다. 무엇보다도 대기열, 연결, 채널, 교환, 사용자 및 사용자 권한을 브라우저에서 생성, 삭제 및 나열 할 수 있으며 메시지 속도를 모니터링하고 메시지를 수동으로주고받을 수 있습니다. Kafka는 관리 및 모니터링 기능을 제공 하는 여러 가지 오픈 소스 도구와 상용 버전을 가지고 있습니다. RabbitMQ를 잘 이해하는 것이 더 쉽고 빠릅니다.

자세한 내용과 비교 데이터는 https://www.cloudamqp.com/blog/2019-12-12-when-to-use-rabbitmq-or-apache-kafka.html 에서 확인할 수 있습니다.

또한 업계 논문을 추천 : “카프카 대 RabbitMQ : 두 산업 참조 출판 / 구독 구현에 대한 비교 연구”: http://dl.acm.org/citation.cfm?id=3093908

Apache Kafka와 RabbitMQ를 서비스로 제공하는 회사에서 일하고 있습니다.


답변

매주이 질문을 듣습니다 … RabbitMQ (IBM MQ 또는 JMS 또는 일반적으로 다른 메시징 솔루션)가 기존 메시징에 사용되는 반면 Apache Kafka는 스트리밍 플랫폼 (메시징 + 분산 스토리지 + 데이터 처리)으로 사용됩니다. 둘 다 다른 사용 사례를 위해 만들어졌습니다.

“전통적인 메시징”에는 Kafka를 사용할 수 있지만 Kafka 관련 시나리오에는 MQ를 사용할 수 없습니다.

기사“ Apache Kafka와 ESB (Enterprise Service Bus) — 친구, 적 또는 Frenemies? ( https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/ )”는 Kafka가 경쟁력이 없지만 통합 및 메시징 솔루션을 보완하는 이유에 대해 설명합니다. (RabbitMQ 포함) 및 통합 방법


답변

5 Kafka와 RabbitMQ의 주요 차이점 은 다음과 같습니다.
여기에 이미지 설명을 입력하십시오

기존 메시징 시스템 중 어떤 메시징 시스템을 선택하거나 변경해야합니까?

위의 질문에 대한 답변은 없습니다. 당신이하는 메시징 시스템을 결정해야하거나 기존의 시스템 변경해야합니다 검토 한 가지 접근 방식 “이다 범위와 비용 평가


답변

잊어 버린 한 가지 중요한 차이점은 RabbitMQ는 푸시 기반 메시징 시스템이고 Kafka는 풀 기반 메시징 시스템입니다. 이것은 메시징 시스템이 서로 다른 처리 기능을 가진 서로 다른 유형의 소비자를 만족시켜야하는 시나리오에서 중요합니다. 풀 기반 시스템을 사용하면 소비자는 푸시 시스템이 소비자의 상태에 관계없이 메시지를 푸시하여 소비자에게 높은 위험을주는 기능을 기반으로 소비 할 수 있습니다.


답변

RabbitMQ 는 일반적인 범용 메시지 브로커입니다. 웹 서버는 요청에 빠르게 응답하고 여러 서비스에 메시지를 전달할 수 있습니다. 게시자는 메시지를 게시하고 큐에서 사용할 수 있도록하여 소비자가 메시지를 검색 할 수 있습니다. 통신은 비동기식이거나 동기식 일 수 있습니다.


반면에 Apache Kafka 단순한 메시지 브로커 . 메시지 대기열 역할을하기 위해 LinkedIn에서 처음에 설계하고 구현했습니다. 2011 년부터 Kafka는 오픈 소스 방식으로 분산 스트리밍 플랫폼으로 빠르게 진화하여 실시간 데이터 파이프 라인 및 스트리밍 애플리케이션의 구현에 사용됩니다.

수평 확장 성, 내결함성, 빠른 속도를 자랑하며 수천 개의 회사에서 생산됩니다.

현대 조직에는 시스템 또는 서비스 간의 통신을 용이하게하는 다양한 데이터 파이프 라인이 있습니다. 합리적인 수의 서비스가 실시간으로 서로 통신해야 할 때 상황이 조금 더 복잡해집니다.

이러한 서비스의 상호 통신을 가능하게하려면 다양한 통합이 필요하므로 아키텍처가 복잡해집니다. 보다 정확하게는 m 개의 소스 및 n 개의 목표 서비스를 포함하는 아키텍처의 경우 nxm 고유의 통합을 작성해야합니다. 또한 모든 통합에는 서로 다른 사양이 제공되므로 다른 프로토콜 (HTTP, TCP, JDBC 등) 또는 다른 데이터 표현 (Binary, Apache Avro, JSON 등)이 필요할 수 있습니다. . 또한 소스 서비스는 잠재적으로 대기 시간에 영향을 줄 수있는 연결에서 증가 된로드를 처리 할 수 ​​있습니다.

Apache Kafka는 데이터 파이프 라인을 분리하여보다 단순하고 관리 가능한 아키텍처로 이어집니다. Kafka는 소스 서비스가 데이터 스트림을 푸시하여 대상 서비스가 실시간으로 데이터를 가져올 수 있도록하는 고 처리량 분산 시스템의 역할을합니다.

또한 Kafka Cluster 관리를위한 많은 오픈 소스 및 엔터프라이즈 수준의 사용자 인터페이스를 사용할 수 있습니다. 자세한 내용은 내 기사 Apache Kafka 클러스터 용 UI 모니터링 도구 개요Apache Kafka 이유를 참조하십시오 .


RabbitMQ 또는 Kafka로 갈지 여부는 프로젝트의 요구 사항에 따라 결정됩니다. 일반적으로 단순 / 전통적인 pub-sub 메시지 브로커를 원하면 RabbitMQ로 이동하십시오. 조직에서 실시간으로 이벤트를 수행 할 이벤트 중심 아키텍처를 구축하려면이 아키텍처 유형 (예 : Kafka Streams 또는 ksqlDB)에 더 많은 기능을 제공하므로 Apache Kafka로 이동하십시오.


답변

나는 그것이 조금 늦었다는 것을 알고 있으며 아마도 이미 간접적으로 말했지만 Kafka는 전혀 대기열이 아니며 로그입니다 (누군가 위에서 말했듯이 설문 조사 기반).

간단하게하기 위해 Kafka보다 RabbitMQ (또는 모든 큐 테크노)를 선호해야하는 가장 확실한 사용 사례는 다음과 같습니다.

대기열에서 여러 소비자가 소비하고 있으며 대기열에 새 메시지가 있고 사용 가능한 소비자가있을 때마다이 메시지를 처리하려고합니다. Kafka의 작동 방식을 면밀히 살펴보면 파티션 스케일링으로 인해 파티션 전용 소비자가 있고 기아 문제가 발생할 수 있습니다. 간단한 큐 테크노를 사용하면 쉽게 피할 수 있습니다. 동일한 파티션에서 다른 메시지를 전달하는 스레드를 사용할 수 있지만 Kafka에는 선택적 승인 메커니즘이 없습니다.

당신이 할 수있는 가장 많은 사람들이 그 일을하고 Kafka를 대기열로 변환하려고합니다 :
https://github.com/softwaremill/kmq

야닉


답변

다음과 같은 경우 RabbitMQ를 사용하십시오.

  • Bigdata를 처리 할 필요가 없으며 모니터링을 위해 편리한 내장 UI를 선호합니다.
  • 자동으로 복제 가능한 큐가 필요 없음
  • 메시지에 대한 다중 가입자 없음-로그인 Kafka와 달리 RabbitMQ는 대기열이며 메시지는 일단 소비되고 승인이 도착하면 제거됩니다.
  • 메시지에 와일드 카드 및 정규식을 사용해야하는 경우
  • 메시지 우선 순위를 정의하는 것이 중요한 경우

요약 : RabbitMQ는 우선 순위 대기열과 유연한 라우팅 옵션을 통해 데이터 트래픽이 적은 간단한 사용 사례에 적합합니다. 방대한 데이터와 높은 처리량을 위해서는 Kafka를 사용하십시오.