Page History

...

• SSE(Simple Sent Event)를 이용해 구독(sub)을 하고
• API 액터모델을 이용해 발행(pub)을 할수 있습니다.

메시지 브로커에서 일반적으로 지원하는 pub/sub 방식도 akka가 지원하는 분산처리 장치중 하나로 여기서는 자세한 설명이 생략되었으나~

아래 코드를 통해  샘플클라이언트를 통해 기능작동 확인을 할수 있으며 유닛테스트도 포함되어 있습니다.

이 장치는 redis 의 pub/sub 에 대응하며 해당장치와 연동하거나 대체할수도 있습니다. 

• https://medium.com/@abu_nadhr/akka-typed-with-redis-2958be8daf16
• https://github.com/psmon/kopring-reactive-labs/tree/main/KotlinBootReactiveLabs/src/main/kotlin/org/example/kotlinbootreactivelabs/actor/sse

ExacltlyOnce Delivery

Akka의 Actor 메시지전송은 기본적으로 AtMostOnce 로 동작합니다. 전송보장을 위해 별도 설계를 할수도 있겠지만

중요 도메인 이벤트인경우 Kafka와 연동하는것을 권장하며 Reactive Stream(AkkaStream)을 통해 액터모델은 외부장치와의 연결도 유연하게 할수 외부장치와 연결해

다양한 Consumer 전략을 선택할수 있습니다. 

Link :

• https://pekko.apache.org/docs/pekko-connectors-kafka/current/
• https://pekko.apache.org/docs/pekko-connectors-kafka/current/consumer.html#choosing-a-consumer

At-Most-Once Delivery란?

• 메시지가 최대 한 번만 전달됨을 보장합니다.
• 네트워크 장애 또는 기타 원인으로 인해 메시지가 손실될 수 있음.
• 메시지 중복이 발생하지 않음.
• 성능이 가장 우수하지만, 신뢰성이 낮음.
• 손실이 허용되는 경우
  • 예: 모니터링 시스템(일부 로그 손실이 치명적이지 않음)
  • 예: 게임 로직에서의 이벤트(일시적인 위치 업데이트)
• 고성능이 중요한 경우
  • ACK 기반 재전송이 필요 없기 때문에 메시지 처리 속도가 중요할 때 사용
• 데이터가 중요하지 않거나, 외부에서 보완할 수 있는 경우
  • 예: UI 알림 전송 (사용자가 새로고침하면 다시 불러올 수 있음)

...

1. At-Least-Once Delivery

   • 재전송을 통해 메시지 전달을 보장하지만, 중복이 발생할 수 있음.
   • Akka에서는 ask 패턴 또는 Akka Persistence(이벤트 소싱) 사용.

2. Exactly-Once Delivery

   • 중복 제거 로직을 추가하여 메시지가 정확히 한 번만 처리되도록 보장.
   • Kafka 등의 외부 메시지 브로커와 조합하여 구현.

3. Akka Reliable Delivery 사용

   • Akka의 Reliable Delivery 기능을 활용하면 At-Least-Once 또는 Exactly-Once 보장을 구현할 수 있음.

메시지 브로커에서 일반적으로 지원하는 pub/sub 방식도 akka가 지원하는 분산처리 장치중 하나로 여기서는 자세한 설명이 생략되었으나~

...

1. • .

새로운 패러다임의 개발패턴을 적용한다고하면  유닛테스트를 통해 설명가능하고 작동가능한 코드를 먼저 작성하는것이 권장되며

...