akka를 보던 중 at most once 전달이기 때문에 메시지의 유실이 발생할 수 있다는 내용이 보인다.
(http://doc.akka.io/docs/akka/snapshot/general/message-delivery-reliability.html)
그렇다면 akka를 못 쓰는 것인가? 보완하도록 메커니즘을 구성해야 되겠네....
생각난김에 메시지전송 패턴에 대해서 간략히 정리를 해본다.
- at-most-once delivery means that for each message handed to the mechanism, that message is delivered zero or one times; in more casual terms it means that messages may be lost.
- at-least-once delivery means that for each message handed to the mechanism potentially multiple attempts are made at delivering it, such that at least one succeeds; again, in more casual terms this means that messages may be duplicated but not lost.
- exactly-once delivery means that for each message handed to the mechanism exactly one delivery is made to the recipient; the message can neither be lost nor duplicated.
1. At least once
실패가 일어나더라도 메시지의 유실이 발생해서는 안되고 복구에 너무 오랜시간이 걸려도 안된다.
메시지는 최소한 한번 이상 전달되어야 한다
<context>
메시지의 전달을 확실히 보장하는 것이 최우선이며, 중복이 발생해도 무방하다.
<solution>
각 메시지를 수신했을 때 ack응답을 되돌려주도록 한다. 만약에 ack를 정해진 시간내에 못 받을경우 다시 보낸다.
2. At most once
메시지는 많아도 한번 전달된다.
<context>
중복없이 빠르게 처리하는 것이 목표이다. 유실되어도 critical하지 않은 경우
<solution>
전송에 관련된 상태등을 기억하지 않는다. fire-and-forget
3. Exactly one
메시지는 정확하게 한 번만 전달되어야 한다. 금융권이나 기타 트랜잭션을 반드시 보장해야하는 경우다. 중복x!
<context>
분산처리 환경에서 매우 중요한 요건으로 메시지 유실이 발생해서도 안되고, 중복이 발생해도 안된다.
<solution>
메시지를 생성할 때 unique message identifier를 붙인다. 이 identifier를 이용해서 송신자와 수신자간에서 발생한 중복메시지를 filter처리한다.
http://www.cloudcomputingpatterns.org/
'Software Architecture' 카테고리의 다른 글
Data 수집 아키텍처 (0) | 2016.03.13 |
---|---|
소프트웨어 아키텍처와 가장 연관이 있는 것은 조직과 문화 (0) | 2015.08.27 |
Go Reactive Systems (0) | 2015.03.25 |
scale out 이 가능한 architecture? micro service? (0) | 2015.03.25 |
빅데이터 분석에서 배치활용 (0) | 2014.10.21 |