publisher(송신자)로부터 전달받은 메세지를 subscriber(수신자)로 전달해주는 중간역할을 해준다. 이때 메세지가 적재되는 공간이 message queue(메세지큐), 메세지의 그룹을 topic(토픽)이라고 한다.
일반적인 방법:
⇒ 실시간으로 처리하기 위해서는 최신의 데이터를 빠르게 조회해야하는데 실시간으로 데이터가 계속 쌓이는 테이블을 빠르게 조회하는 것은 힘듬. 그렇다고 조회성능을 높이기 위해서 테이블에 인덱스를 걸게 되면 insert 속도가 느려지기 때문에 실시간 처리에 적합하지 않음.
message broker와 함께한 방법:
⇒ B서버에서 별도의 조회과정 없이 메세지 큐에 적재되는 메세지를 감시하고 있다가 메세지가 적재되면 가져다가 사용함. 이러한 구조를 publish/subscribe 패턴 또는 producer/consumer 패턴이라고 함.
장점: 실시간 데이터 처리를 할 때 DB에서 조회하는 것보다 성능이 뛰어남
단점: DB에서는 query를 이용하여 원하는 데이터만 필터링하여 조회가능. 하지만 메세지 브로커의 경우 queue에 적재된 그대로를 사용. → 적재할 때 필터링된 데이터를 적재하던가 적재된 데이터를 logstash 를 사용하여 필터링하여 사용.
장기간 보관할 수 없음.
apache kaflka, redis, rabbitMQ, celery