Spring Boot Redis Sub/Pub


Publish/Subscribe 아키텍처

많이 사용하는 HTTP Request/Response 방식은 Client-Server 사이에 강한 의존성이 생기며

서버가 실행 중일 때만 데이터를 전달받을 수 있다. (동기식 통신 방식)

HTTP 통신과 반대로 느슨하게 결합된 비동기 시스템 통합 방식 중 대표 기술이 메시징 이다.

메시징은 중간 시스템을 통해서 전송하기 때문에 발신자는 수신자에 대해서 전혀 알지 못한다.


Messaging Pub/Sub VS. Messaging Queuing

메시징이라는 용어는 매우 포괄적인 용어이다.

메시징을 구현하는 방법도 다양한데, 그 중 Pub/Sub와 메시지 큐잉에 대해서 알아보자.


Messaging Queuing

메시지 큐잉은 point-to-point channel 방식으로 오직 한 수신자만 메시지를 수신(소비) 한다.

순차적으로 처리하기 때문에 메시지가 채널에 쌓이게 되면 소비할 수 있는 client를 늘려서 병목현상을 해결할 수 있다.

그런데 client를 늘리며 이벤트에 대한 순서를 보장받을 수 없다.

이벤트 순서를 보장하기 위해 별도의 작업이 또 필요하다.

예) kafka 브로커의 파티션 지정 메시지 전송


Messaging Pub/Sub

메시지 큐잉과 반대로 Pub/Sub는 수신자(client) 모두에게 동일한 메시지를 전송한다.


Redis Pub/Sub

Redis Pub/Sub는 매우 심플한 기능을 제공하는데 메시지를 별도로 저장하지 않기 때문에

메시지 전송 후 해당 메시지가 삭제되어 전송 신뢰성을 보장하지는 않는다.

실시간 데이터 처리에 매우 적합한데, 이를 개발자가 인지하고 있어야 한다.


redis-cli로 기능 확인해보기

subcribe channel

“ch01” 이라는 이름의 채널에 메시지를 수신

6379> subscribe ch01
1) "subscribe"
2) "ch01"
3) (integer) 1


publish channel "message"

“ch01” 이라는 채널에 메시지 발행

6379> publish ch01 "test message"
(integer 2)

여기서 2는 2개의 수신자에서 메시지를 받았다는 것을 의미한다.

6379> subscribe ch01
1) "subscribe"
2) "ch01"
3) (integer) 1
1) "message"
2) "ch01"
3) "test message"


pubsub numsub channel

pubsub 명령으로 해당 채널 커넥션 연동 중인 수신자 개수 확인

6379> pubsub numsub ch01
1) "ch01"
2) (integer) 2


Spring Boot Redis Sub/Pub

참고