메시지 처리
-
RabbitMQ : 컨슈머가 큐에 연결하여 메시지를 수신하거나, 수신후 ack를 알리면 해당 큐에서 메시지가 제거 된다.
-
Kafka : 큐에 지정된 기간이 경과되거나 특정 크기가 초과되기 전까지는 메시지가 지속적으로 저장된다. 메시지가 몇번이고 재사용되어야 할 때 유리하다.
아키텍처
-
RabbitMQ : Exchange, Binding, Queue, Routing Key를 사용한다.
-
Kafka : Broker, Topic, Partition, Replication 등 더 복잡한 아키텍처를 사용한다.
컨슈머에 메시지 전달
- RabbitMQ : Push 방식이 주로 사용된다.
- Kafka : 컨슈머가 polling하여 자기 성능에 맞게 처리할 수 잇다.
프로그래밍 언어 및 프로토콜
-
RabbitMQ : 광범위한 언어 및 레거시 프로토콜을 지원한다. AMQP, STOMP, MOTT 와 같은 표준 프로토콜을 지원
-
Kafka : 프로그래밍 언어 선택의 폭이 제한적이며 TCP를 통한 바이너리 프로토콜을 데이터 전송에 사용한다.
라우팅
-
RabbitMQ : Direct, Fanout, Topic, Header 등의 라우팅 옵션을 제공하여 메시지를 큐에 유연하게 라우팅이 가능하다.
-
Kafka : 기본기능으로는 라우팅에 대해서 지원을 하지않아 Kafka Stream 활용이 필요하다.
메시지 우선 순위
- RabbitMQ : 우선순위 큐를 지원하여, 우선 순위에 따라 처리가 가능하다.
- Kafka : 우선순위를 지원하지 않고 변경이 불가능한 시퀀스 큐이다.
응답
-
RabbitMQ : 프로듀서 ack를 지원하며, 해당 브로커에 메시지가 안전하게 전달되었는지 알 수 있다. 컨슈머도 마찬가지로 메시지가 안전하게 클라이언트에게 전달되었는지 확인할 수 잇다.
-
Kafka : RabbitMQ와 마찬가지로 프로듀서 ack를 지원하고, 컨슈머는 오프셋을 통해 메세지의 처리를 추적할 수 있다.
스케일링
-
RabbitMQ : 많은 컨슈머들이 경쟁을 통해 메시지 처리가 가능하며 컨슈머의 추가 및 제거로 스케일을 조절할 수 있다. 브로커는 수평적으로 확장을 하더라도 항상 더 나은 성능을 제공해주지는 못한다.
-
Kafka : 컨슈머들을 하나 이상의 파티션에 할당하여 스케일링하고, 브로커는 클러스터에 더 추가하여 스케일을 조절할 수 있다. RabbitMQ 보다 더 큰 규모의 확장이 이루어질 수 있다.
성능
-
RabbitMQ : 지연시간이 짧고 초당 수천 개의 메시지를 전송한다.
-
Kafka : 초당 최대 수백만개의 메시지를 실시간으로 전송한다.
참조한 책 및 사이트
https://ellune.tistory.com/29