Skip to content

Message queue

메시지 큐(message queue)는 사용자가 키보드나 마우스로 명령한 것을 메시지 형태로 변환하여 저장하는 큐이다. 메시지 큐는 윈도 운영 체제의 모든 스레드에 존재한다. 사용자가 창에 어떤 명령을 보내면 프로그램(또는 창)이 그 큐에서 메시지를 읽고 처리한다. 예를 들어, 마우스를 움직이면 마우스를 움직였다(WM_MOUSEMOVE)는 메시지가 메시지 큐에 저장되고 프로그램은 이에 맞는 처리를 한다. 즉, 메시지 큐는 프로그램(또는 창)에게 사용자가 취한 행동을 변환, 실행하게 만든다.

Kafka vs RabbitMQ vs Redis

RabbitMQ

Kafka

Redis Pub/Sub

이벤트 저장 in Queue

메세지가 성공적으로 전달되었다고 판단될 경우 메세지가 큐에서 삭제되기 때문에 재처리가 어렵다

이벤트를 삭제하지 않고 스트림에 저장함으로 영속성(durability)이 보장되고, 재처리가 가능하다. 저장하지 않음. 심지어 channel에 이벤트가 도착했을 때 해당 채널의 subscriber가 존재하지 않으면 이벤트 사라짐

프로토콜

AMQP, MQTT, STOMP 등 여러 메세징 플랫폼을 지원한다.

단순한 메시지 헤더를 지닌TCP 기반 custom 프로토콜을 사용하기 때문에 대체가 어렵다.

RESP (Redis Serialization Protocol) - TCP 통신

라우팅

Direct, Fanout, Topic, Headers의 라우팅 옵션을 제공하여 유연한 라우팅이 가능하다.

기본기능으로 라우팅에 대해서 지원하지 않는다. Kafka Streams를 활용하여 동적라우팅을 구현할 수 있다.

우선순위

priority queue를 지원하여 우선 순위에 따라서 처리가 가능하다.

변경 불가능한 시퀀스 큐로, 한 파티션 내에서는 시간 순서를 보장한다. 하지만 여러 파티션이 병렬로 처리할 때는 시간 순서 보장 못함

우선순위 처리는 커녕 이벤트가 도착할 지 보장도 못함

장점

  • 오래전에 개발되어 제품 성숙도가 크다
  • 필요에 따라 동기/비동기식 가능
  • 유연한 라우팅
  • producer/consumer간의 보장되는 메세지 전달
  • Manage UI 기본 제공
  • 데이터 처리보단 관리적 측면이나 다양한 기능 구현을 원할 때 사용
  • 이벤트가 전달되어도 삭제하지 않고 스트림에 저장
  • 고성능, 고가용성, 분산처리에 효과적
  • producer 중심적 (많은 양의 데이터를 병렬 처리)
  • channel을 구독하는 모든 subscriber가 이벤트를 받기 때문에 synchronization 문제에서 kafka보다 덜하다
  • 미들웨어가 필요 없어서 가볍다

단점

Kafka 보다 느림

범용 메세징 시스템에서 제공되는 다양한 기능이 제공되지 않음

이벤트 도착 보장을 못함

  • 대용량 데이터 처리, 실시간, 고성능, 고가용성이 필요한 경우, 또는 저장된 이벤트를 기반으로 로그를 추적하고 재처리 하는게 필요한 경우 kafka를 쓰자
  • 복잡한 라우팅을 유연하게 처리해야하고, 정확한 요청-응답이 필요한 Application을 쓸 때 또는 트래픽은 작지만 장시간 실행되고 안정적인 백그라운드 작업이 필요한 경우 RabbitMQ를 쓰자.
  • 이벤트 데이터를 DB에 저장하기 때문에 굳이 미들웨어에 이벤트를 저장할 필요가 없는 경우, consumer에게 굳이 꼭 알람이 도착해야한다는 보장 없이 알람처럼 push 보내는것만 중요하다면 유지보수가 편한 Redis를 사용하자

Projects

See also

Favorite site