1. Pub/Sub

스프링 부트 Pub/Sub 패턴은 각 서버 간 느슨한 결합을 위해 활용이 된다.

메시지 발행자 publisher는 메시지 브로커 역할을 하는 레디스에게 메시지를 전달하게 되고, 메시지 수신자 subscriber는 레디스와 연결하고 있으며, 레디스로부터 발행된 메시지 또는 이벤트를 받게 된다.

flowchart LR
		subgraph Loose coupling
				direction TB
		    subgraph publish
		        server
		    end
		    subgraph Redis
		    end
		    subgraph subscribe
						direction TB
		        server1
		        server2
		        server3
		    end
		 end
	Redis --> publish
	Redis --> server1
	Redis --> server2
	Redis -.-> server3

| 장점 | - 이벤트 발행자가 메시지 수신 대상을 직접적으로 알 필요가 없다. 따라서 수신 대상 서버의 증감에 따른 부담이 적다.

• 레디스와 같은 인메모리 기반의 메시지 브로커를 활용하면 높은 처리량을 보장하며 실시간 처리에 적합하다. | | --- | --- | | 단점 | - 레디스와 같은 인메모리 기반의 브로커는 가용성 문제와 대량 메시지 처리에 한계가 있다.
• 레디스는 메시지를 저장하지 않아, 서버가 다운되었던 경우 해당 서버는 기존에 전달된 메시지를 다시 받을 수 없다. |

flowchart LR
	direction TB
  subgraph publish
      server
  end
  subgraph subscribe
			direction TB
      server1
      server2
      server3
  end
	publish <--> server1
	publish <--> server2
	publish ~~~ server3

만약 메시지 브로커 없이 서버 to 서버로 전달하게 된다면 메시지 발행자 입장에서 수신되는 서버의 증감에 맞게 모든 서버에 연결하게 되는 소스 코드를 수정해야 하는 상황이 생기게 된다.

라이브 채팅 서비스의 경우

1. 사용자가 라이브 채팅 서비스의 채팅방에서 메시지를 작성한다.
2. 이 작성된 메시지는 레디스를 통해 전달되며, 이때 레디스는 메시지 브로커의 역할을 수행한다.
3. 레디스에 등록된 해당 메시지를 구독하고 있는 서버는 레디스로부터 메시지를 수신한다.
4. 이 서버는 채팅방에 접속해 있는 사용자가 있다면, 그 사용자의 클라이언트에게 메시지를 전달한다.

2. Redis pub/sub

SUBSCRIBE : 채널을 등록할 수 있으며, 해당 채널에 발행된 메시지를 대기하게 된다.

127.0.0.1:6379 > **SUBSCRIBE** users:unregister

Reding messages...(press Ctrl-C to quit)
1) "subscribe"
2) "users:unregister"
3) (integer) 1