저는 개발중인 서버에서 Java NIO 또는 이전 Java I/O 블로킹 소켓을 선택하는 동안 어려움을 겪고 있습니다.고성능 서버용 Java NIO 또는 Java IO
매우 많은 수의 클라이언트가 있기 때문에 Java NIO가 더 좋을 것이라고 생각했습니다. 그리고 클라이언트가 연결되어있어 서버가 데이터를 사용할 수있을 때 밀어 낼 수 있습니다.
그래서 저는 자바 차단 I/O가 과도 할 것이라고 생각합니다. 스레드 수는 많을 것이기 때문입니다.
귀하의 의견은 무엇입니까?
단일 메시지 푸시가 오래 걸릴 것으로 예상되는 경우 I/O 차단에만 문제가 있습니다. 연결된 클라이언트 만 클라이언트 당 하나의 스레드를 수반하지 않습니다. 사실, 지금 나는 그런 소프트웨어 조각을 쓰고있다. 특정 시점에 동시 메시지 푸시가 발생하는만큼 많은 스레드가 필요합니다. 이것은 일반적으로 높지 않습니다. 메시지가 도착하기까지 기다리는 시간과 메시지를 푸시하는 데 필요한 시간의 비율을 고려하십시오. 동시 클라이언트 수에이 수를 곱하면 평균 활성 스레드 수가 있습니다.
각 클라이언트마다 하나씩 모든 열린 출력 스트림을 유지 관리하게됩니다. 그들은 메시지가 도착할 때까지 메모리에 앉아서 클라이언트에게 푸시해야합니다. 그 시점에서 하나의 메시지를 처리하기 위해 하나의 스레드가 필요합니다. 메시지가 푸시되고있는 동안 다른 이벤트를 처리하고 다른 클라이언트에 메시지를 보내려면 두 번째 스레드가 필요하지만 첫 번째 푸시가 완료 되 자마자 해당 스레드는 사용 가능한 풀로 리턴됩니다 스레드.
메시지 푸시를 조정하기 위해 액터 모델 구현을 조언 할 수도 있습니다. 액터 모델은이 문제와 정확히 일치합니다.
[netty] (https://netty.io/)를 사용해 보셨습니까? –
* 기존 * 프레임 워크를 사용할 것입니다. NIO를 직접 사용하지 마십시오. PITA이고 "정확함"이 어렵습니다. XNIO와 같은 래퍼를 사용해야합니다. 더 높은 수준의 추상화도 가능할 것입니다. 시작 (예 : Tomasz가 언급 한 메시지 프레임 워크 또는 이벤트 중심 서버). 나에게있어 NIO의 큰 장점은 "동시성 감소"만큼 "스레드 감소"가 아니라 스레드 간의 단일 교차점을 가짐으로써 동시성 문제에 대해 덜 생각할 필요가 있다는 것입니다. –
많은 수의 연결을 의미합니까? 서버 당 100, 1000, 10000 또는 100,000 솔루션은 정확한 요구 사항에 달려 있습니다. 더 자세한 내용이 없다면 나는 더 간단한 해결책이 최선이라고 가정 할 것이다. –