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를 지원하여 우선 순위에 따라서 처리가 가능하다. | 변경 불가능한 시퀀스 큐로, 한 파티션 내에서는 시간 순서를 보장한다. 하지만 여러 파티션이 병렬로 처리할 때는 시간 순서 보장 못함 | 우선순위 처리는 커녕 이벤트가 도착할 지 보장도 못함 |
| 장점 |
|
|
|
| 단점 | Kafka 보다 느림 | 범용 메세징 시스템에서 제공되는 다양한 기능이 제공되지 않음 | 이벤트 도착 보장을 못함 |
- 대용량 데이터 처리, 실시간, 고성능, 고가용성이 필요한 경우, 또는 저장된 이벤트를 기반으로 로그를 추적하고 재처리 하는게 필요한 경우 kafka를 쓰자
- 복잡한 라우팅을 유연하게 처리해야하고, 정확한 요청-응답이 필요한 Application을 쓸 때 또는 트래픽은 작지만 장시간 실행되고 안정적인 백그라운드 작업이 필요한 경우 RabbitMQ를 쓰자.
- 이벤트 데이터를 DB에 저장하기 때문에 굳이 미들웨어에 이벤트를 저장할 필요가 없는 경우, consumer에게 굳이 꼭 알람이 도착해야한다는 보장 없이 알람처럼 push 보내는것만 중요하다면 유지보수가 편한 Redis를 사용하자