P2P가 아닌 클라이언트 - 서버 기반의 인스턴트 메시징 응용 프로그램이 있다고 가정 해 봅니다. 실제 프로토콜은 중요하지 않습니다. 중요한 것은 서버 아키텍처입니다. 이 서버는 논 블로킹 소켓을 사용하여 단일 스레드, 비 병렬 모드로 작동하도록 코딩 할 수 있습니다.이 소켓은 정의에 따라 읽기 - 쓰기와 같은 작업을 즉시 또는 즉시 수행 할 수 있습니다. 비 블로킹 소켓의이 기능 덕분에 서버의 핵심 부분에서 일종의 선택/폴링 기능을 사용할 수 있으며 실제 소켓 읽기/쓰기 작업 시간을 낭비하지 않고이 모든 정보를 처리하는 데 시간을 소비 할 수 있습니다 . 적절하게 코딩되었으므로 이해하는 한 매우 빠를 수 있습니다. 그러나 두 번째 방법은 적극적으로 멀티 쓰레드를 만드는 것입니다. 새로운 스레드를 생성하는 것입니다 (어떤 종류의 스레드 풀을 사용하는 것은 분명합니다. 왜냐하면 바로 그 작업이 일부 플랫폼과 경우에 따라 느려질 수 있기 때문입니다) 병렬로 작업하는 반면, 기본 백그라운드 스레드는 accept()와 stuff를 처리합니다. 이 접근법이 인터넷을 통해 여러 곳에서 설명 된 것을 보았 기 때문에 분명히 존재합니다.Instant Messaging Server 디자인
이제 비 블로킹 소켓과 즉각적인 읽기/쓰기 작업 및 간단하고 쉽게 코딩 된 디자인이있는 경우 두 번째 변형이 왜 존재합니까? 두 번째 디자인, 즉 쓰레드로 극복하려는 문제는 무엇입니까? AFAIK는 일반적으로 느리고 가능하면 차단 작업을 처리하는 데 사용되지만 이러한 작업은 여기에있는 것처럼 보이지 않습니다!
사실, 정확히 1 : 1 클라이언트 : 스레드 매핑 디자인을 언급했습니다. 당신이 언급 한 하이브리드 디자인은 의미가 있으며 실제로 잘 알고 있습니다. 1 : 1 디자인에 대해 좀 더 자세히 설명해 주시겠습니까? – iksemyonov
감사합니다 !!! 여기에 "Win32 fiber"만 추가 할 수 있습니다. 그건 내가 알고있는 유일한 가벼운 API이다. 그러나 일반적으로 그렇습니다. 당신이 말하는 것은 말이됩니다. 단일 스레드 모델에서 데이터베이스 호출을 막는 방법 (이 토론의 맥락에서 스레드와 스레드를 즉시 염두에 두는 것이 가장 명백한 방법입니다)을 피하는 방법은 무엇입니까? – iksemyonov
섬유는 가벼울 수 있지만 차단 호출을 원할 경우 절약 할 수는 없습니다. 차단 호출을 피하는 것은 일반적으로 불가능하므로 1 : 1 모델이 일반적입니다. 일부 DB API는 비 차단 호출을 제공하지만 대부분은 그렇지 않습니다. 후자의 경우 비동기 패턴을 구현하고 (풀 풀) 차단 호출을 예약하고 완료되면 통지를받을 수 있습니다. 즉, 차단 호출을 처리하는 스레드 (많은 스레드)에 많은 클라이언트를 매핑 할 수 있습니다. 호출이 차단되는 속도와 각 호출에 걸리는 평균 시간에 따라 잘 작동하는지 여부에 달려 있습니다. – nos