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

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

---

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

---

RabbitMQ는 AMQP, MQTT, STOMP 등과 같은 여러 프로토콜을 지원 하는 견고한 범용 메시지 브로커 입니다. 높은 처리량을 처리 할 수 ​​있습니다. 일반적인 사용 사례는 백그라운드 작업을 처리하거나 마이크로 서비스 간의 메시지 브로커 역할을하는 것입니다. Kafka는 대용량 데이터 스트림 및 재생에 최적화 된 메시지 버스 입니다.

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

RabbitMQ는 소비 / 승인 / 확인되지 않은 메시지에 대한 모든 상태를 유지하지만 Kafka는 그렇지 않지만 소비자는 소비 된 내용을 추적하지 않는 것으로 가정합니다. RabbitMQ의 대기열은 비어있을 때 가장 빠르며 Kafka는 오버 헤드가 거의없이 많은 양의 데이터를 유지합니다. Kafka는 대량의 메시지를 보관 및 배포하도록 설계되었습니다. RabbitMQ에서 대기열이 매우 길면 지연 대기열을 볼 수 있습니다 .

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

RabbitMQ에는 웹 브라우저에서 RabbitMQ 서버를 모니터링하고 처리 할 수있는 사용자 친화적 인 인터페이스가 있습니다. 무엇보다도 대기열, 연결, 채널, 교환, 사용자 및 사용자 권한을 브라우저에서 생성, 삭제 및 나열 할 수 있으며 메시지 속도를 모니터링하고 메시지를 수동으로주고받을 수 있습니다. Kafka 관리자는 아직 RabbitMQ Management의 인터페이스만큼 개발되지 않았습니다. RabbitMQ에 대해 잘 이해하는 것이 더 쉽고 빠릅니다.

자세한 내용과 비교 데이터는 여기에서 확인할 수 있습니다 : https://www.cloudkarafka.com/blog/2016-12-05-apachekafka-vs-rabbitmq.html

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

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

---

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

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

“ 아파치 카프카와 ESB (Enterprise Service Bus) – 친구, 적 또는 프렌 미? ( https://www.confluent.io/blog/apache-kafka-vs-enterprise-service-bus-esb-friends-enemies-or-frenemies/ )”는 Kafka가 경쟁적이지 않고 통합 및 메시징 솔루션을 보완하는 이유를 설명합니다. (RabbitMQ 포함) 및 통합 방법

---

5 Kafka와 RabbitMQ의 주요 차이점 은 다음과 같습니다.

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

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

---

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 및 / 또는 KSQL)에 더 많은 기능을 제공하므로 Apache Kafka로 이동하십시오. .

---

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

---

나는 둘 다에 대한 나의 경험을 바탕으로 객관적인 답변을 제공 할 것이고, 이미 알고 있거나 다른 답변이 이미 충분히 제공했다고 가정하고 그 뒤에있는 이론을 건너 뛸 것입니다.

RabbitMQ : 요구 사항이 채널 / 큐를 통한 시스템 통신을 처리하기에 충분히 단순하고 유지 및 스트리밍이 요구 사항이 아닌 경우이 방법을 선택합니다. 예를 들어 제조 시스템이 자산을 구축 할 때 계약 시스템에 계약 등을 구성하도록 알립니다.

Kafka : 이벤트 소싱 요구 사항은 주로 스트림 (때로는 무한대), 한 번에 대량의 데이터를 적절히 균형 조정하고 주어진 상태 등을 보장하기 위해 오프셋을 재생해야 할 때 필요합니다. 이 아키텍처는 주제 / 파티션 / 브로커 / 톰 스톤 메시지 등과 같은 개념을 최우선으로 중요하게 포함하기 때문에 더 복잡합니다.

---

내가 생각할 수있는 유일한 이점은 거래 기능이며 나머지는 Kafka를 사용하여 수행 할 수 있습니다.

---

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

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

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

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

야닉

---

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

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

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

---

분산 내결함성 방식으로 두 가지를 모두 확장하는 것은 어렵지만 RabbitMQ를 사용하면 대규모로 훨씬 어려울 수 있습니다. Shovel, Federation, Mirrored Msg Queues, ACK, Mem 문제, Fault Tollanceance 등을 이해하는 것은 쉬운 일이 아닙니다. Kafka의 Zookeeper 등과 관련된 특정 문제는 없지만 관리해야 할 부분이 적습니다. 즉, Kafka가 아닌 RMQ와 Polyglot 교환을받을 수 있습니다. 스트리밍하려면 Kafka를 사용하십시오. 간단한 IoT 또는 이와 유사한 대용량 패킷 전달을 원하면 Kafka를 사용하십시오. 똑똑한 소비자에 관한 것입니다. 높은 비용과 약간의 복잡성으로 msg 유연성과 높은 안정성을 원한다면 RMQ를 사용하십시오.

참고 URL : https://stackoverflow.com/questions/42151544/is-there-any-reason-to-use-rabbitmq-over-kafka