[%] 메시지 큐 왜 씀? 많이 사용함?

[익명(117.111)]

검색을 해봐도 이유가 와닿지 않는데... 비동기로 처리할수 있다고 하는데 걍 언어 자체에서 비동기 처리 시키면 안되는건가?
어떤 이득이 있는거지

[미쿠쟝스키스키(39.7)]

나는 컴터가 열 대가 있어요 - dc App

[미쿠쟝스키스키(211.246)]

어떤 애는 빠르고 어떤 애는 지혼자 꺼지기도 하고 그런데 - dc App

[미쿠쟝스키스키(211.246)]

이런 상황에서는 메세지 버퍼를 외부에 두는게 현명할 지도 몰라요 - dc App

[미쿠쟝스키스키(211.246)]

아님말고 - dc App

[익명(175.223)]

1. 비동기 연산을 수행하다가 서버가 죽었다. 어떻게 요청을 복구할 것인가? - dc App

[익명(175.223)]

2. 수천만 건의 요청이 들어왔다. 서버의 개수는 동적으로 늘어났다가, 줄어들었다 한다. 어떻게 해야 요청을 각 서버에 잘 분배할까? - dc App

[익명(175.223)]

3. 서버는 개당 아무리 많아야 약 6만개의 커넥션을 가질 수 있다. 수천만 건은 어떻게 처리할 것인가? - dc App

[익명(175.223)]

4. 요청이 어디서 왔는지, 어떻게 처리되었는지에 대해 알고싶다. 다양한 역할을 하는 A~Z 서버가 있는데, 각 서버마다 해당 기능을 똑같이 전부 구현해야 하는가? - dc App

[익명(175.223)]

5. 요청과 그에 따른 응답의 구조가 조금씩 바뀐다. 이때마다 서버를 계속 재배포 해야하는가? - dc App

[익명(116.36)]

정보) 커넥션 수 제한은 메모리 크기 만큼이다. 6만개는 listen할 수 있는 포트의 범위이다.

[익명(39.7)]

tcp 연결이면 포트기준으로 봐도 된느거 아님?? 틀린거 있으면 지적좀 - dc App

[익명(116.36)]

tcp 연결은 (소스 ip, 소스 port, 목적지 ip, 목적지 port)이므로, 목적지 ip, 목적지 port에 보통 서버가 해당한다고 할 때, 소스 ip, 소스 port는 뭐 엄청나게 늘어날 수 있으니까. 그래서 메모리 한계까지 가능한거임.

[익명(59.11)]

질문. 메모리 한계 뿐만 아니라 file descriptor 범위 제한도 고려해야 하는거 아니야? 그 제한이 엄청 널널해서 메모리 한계만 고려해도 되는건가

[익명(116.36)]

파일디스크립터도 고려해야하는게 맞을걸

[Sayori(arwen02)]

OS 내부에서도 쓰는 게 메시지 큐인데 - dc App

[익명(218.39)]

RabbitMQ나 NATS같은거 아닐까