전 rabbit mq로 처리합니다.

@박준영  오우... 이런게 있었네요.

감사합니다.

푸시, 메일은 전형적인 메시지 모델인데,

이 모델은 전화 통신을 가지고 이해하면 좀 쉽습니다.

1) 동기 방식

    전화를 걸었는데, 마침 사람이 있어서 통화를 하는 방식과 유사합니다.

    대화를 직접하는 것이니까, 말하고, 응답을 기다리고 대개 그렇게 하죠.

    그렇지만, 때마침 사람이 없으면, 메시지 전달에 실패를 하는거죠.

    이 경우는 계속 전화를 받을때까지 다시 할 수 밖에 없지요.

2) 비동기 방식

    전화를 했는데, 아무도 없어서 자동 응답기로 연결되는 것과 유사합니다.

   응답기에 녹음이 되고, 나중에 메모리를 확인하는것과 매우 유사합니다.

   시차는 생기지만, 확실히 메시지는 전달이 가능 합니다.

위의 예에서 푸시 및 메일은 메시지 모델의 2) 비동기 방식을 많이 사용합니다.

왜냐면, 메시지 전달 신뢰성이 우선하기 때문입니다. 

그래서 중간에 큐에 넣는 방식을 쓰는 겁니다. 물론 시차는 생길 수 밖에 없지만,

메시지 전달 유연성이 증대되는 거죠.

도움이 되셨으면 합니다.

ActiveMQ를 주로 오픈용으론 많이 씁니다.

mosquitto mq도 푸시용으론 많이 쓰더군요.

@pwrlove 처음 듣는 솔루션들이 많이 있네요 ^^

큰 도움이 되었습니다.

@변종원(웅파)

100% 성공해야 하니 반드시 비동기식으로 해야겠네요.

감사합니다.

100% 성공해야하니 비동기식을 이용한다는 좀 잘못 판단하신듯합니다.

웅파님 말씀을 해석(?)해보면, 성공여부를 몰라도 된다면 비동기식으로 하면 된다. 입니다.

물론, 동기식으로 해야 100% 보장할 수 있다는 의미는 아닙니다만,

동기던, 비동기던, 100% 성공이 가능할지는 모르겠으나, 그에 가깝게 하기 위해선 많은 고민과 문제발생시에 대한 코드등도 많이 필요할 겁니다.

음... 단어가 참 오해 소지가 높네요.

우선 단어 정리부터 합시다.

동기식

나는 계약서 싸인했어. 계약서 보낼게. 받았어?

ㅇㅇ 받았음. 나도 싸인함. 싸인한 계약서 다시 보내줌. 받았음?

ㅇㅇ 받았음. 좋은 계약이었다.

비동기식

내꺼 싸인해서 계약서 보냄. 알아서 싸인해.

자 누가 더 신뢰성이 높은 계약을 했나요?

이번엔 다른 의미로 

동기식

페이지 전환이 이루어 지는 submit 방식. 

비동기식

페이지 전환이 이루어지지 않는 ajax 호출 방식.

같은 단어 다른느낌 다른 의미.

다만 다른 의미라고 해도 100% 성공해야 하니 비동기식. 이라는 발상은 나올 수가 없습니다.

비동기식은 신뢰성하고는 조금 거리가 멀거든요.

참고로 MQ 방식으로 만드셔도 실패율은 항상 존재합니다. 

"그럼 비동기식은 실패하면 별수 없는 건가요?"

에이 설마~ 짱구가 아니고서야 그렇게 만들까요?

비동기로 전송 시도해서 전송 실패 나면,  실패 메세지를 받을 수 있습니다.

그 실패 메세지로 다시 리턴 해서 보낼 수 있게 만듭니다.

고민하고 찾아보시면 있습니다. 고민하지 않고 찾지 않으면 없구요.

특정 프로세스가 끝나고 이메일 전송 끝날때까지 기다려야 하느냐 아니냐로 생각하시면 될 것 같네요.

서비스로 접근해보면

이메일은 부수적인 서비스다 라는 전제가 있다면 꼭 동기식으로 다 보낼때까지 기다릴 필요가 없는거고

이메일 보내는 것까지 아주 중요한 프로세스이면 기다려야 하는게 맞다라는 의미로 글을 쓴겁니다.

qmail의 경우 자체 큐를 가지고 있어서 그냥 던지면 되는데 외부smtp의 경우는 지체시간이 좀 있습니다.

동기/비동기 방식의 의미를 이해하지 못해서 적은게 아니고,

저분에게 가장 적합한 설명을 하려고 필요한 내용만 딱 찍어서 설명하려다 보니

그런 예를 든겁니다.

여기 프로그래밍 밥좀 먹은 사람치고 저거 기본내용 이해 못하시는 분 별로 없을듯 합니다.

메시지 모델 관련 책에도 저걸 가지고 예를 들고 있거든요.

그냥 고민 하시는분 쉽게 해결을 바라고 그런겁니다.

사실 메시지 전송처리에서 의미로 볼때,

동기/비동기 방식은 효율성때문에 선택이 되는 모델입니다.

동기방식 보단 성능상 이유로 비동기식을 많이 선택하지 않습니까?

저분의 고민 중

클라이언트에 의해서 발송되는건 동기로 처리하면 되기는 한데

발송중에 창을 꺼버리거나 할 수도 있다는 생각이 들어서요.

동기식만으로 해결할 수 없는 문제점이죠.

동기식의 문제점은 수신/송신 양쪽이 리소스 사용을 많이해야하고, 비효율적인 점입니다.

이런 방식을 서버등에 적용하면 신뢰성이 매우 안좋겠죠? 많은 사용자들의 관점에선 처리를 못하는 경우가 많아지기 때문이죠.

그래서 거의 대부분 메시지 모델이 큐 방식의 비동기를 쓰는 이유입니다.

관점을 달리하면, 그런 부분이 신뢰성과 연관이 되어 있을 수 있죠. 메시지 모델이란게

임베디드의 시리얼 통신 관점은 아니니까요.

개인적으론 자신의 의견을 피력하는건 좋지만,

자칫 상대방이 들으면 불쾌할 수도 있다고 생각합니다.

여기 모인 분들은 거의 같은 분야에 종사할 가능성이 높고, 서로 경쟁자 일 수도 있지만,

적어도 여기서 글을 올리는 건 협력자의 관점에서 모인것 아닙니까?

상대가 실수로 내용을 적었더라도 배려하고, 어쩌면 불쾌할 수 있는 부분은 자제를 부탁드립니다.

여기 포럼 시샵님도 그런걸 원한건 아닐테니까요.

그리고 kaido 님 적으신 내용은 메시지 모델의 적절한 예는 아닌것 같습니다.

@pwrlove

제가 공격적인 부분이 없지 않아 있습니다.

알고 있으면서도 이제와서 딱히 고치고 싶지도 않구요.  

그냥 트러블 메이커 한명 있다고 생각 해 주시면 됩니다.

100% 성공해야 하니 비동기식. 이라는 단어를 보고 어떤 오해를 하고 있는지 짚어 드린것 입니다.

보시면 아시겠지만 위에도 계속 차이점을 이야기 하고 있는데 마지막에 엉뚱한 답을 꺼내서 노파심에 하는 말입니다.

[단순히 오타 였다면 할 말 없습니다.]

그리고 메시지 모델의 적절한 예가 아니라 단어 표현에 대한 예 입니다.