MDB (Message Driven Bean)의 여러 인스턴스가 수신 대기하는 메시지 큐에 여러 작업 단위를 배치하여 동시 처리가 이루어지는 데이터 처리 응용 프로그램에서 작업합니다. 이러한 방식으로 동시성을 달성하지 못하면 메시징 인프라와 MDB를 사용할 구체적인 이유가 없습니다.멀티 스레드를위한 메시징 (예 : JMS)의시기는 언제입니까?
이렇게 여러 스레드를 사용하여 동일한 결과를 얻을 수 없었던 이유를 알게되었습니다.
내 질문에, 동시성을 달성하기위한 수단으로 mutithreading 대신에 비동기 메시징 (예 : JMS)을 사용할 수있는 상황은 무엇입니까? 하나의 접근법을 다른 접근법보다 사용하는 데있어 장점/단점은 무엇입니까?
멀티 스레딩의 대안으로 사용할 수 없으며 멀티 스레딩을 구현하는 방법입니다. 여기에는 다음과 같은 세 가지 기본 솔루션이 있습니다.
멀티 스레딩/멀티 프로세싱의 형식이 없으면 실제로 데이터를 수신 할 수 없기 때문에 수신 데이터가 여기에 있습니다. 그렇지 않으면 한 번에 하나의 요청 만 처리하게됩니다. 멀티 스레딩없이 데이터를 전송하는 것이 훨씬 더 실용적이지만, 거기에서 이러한 메시지를 처리하는 책임은 외부 시스템으로 전달할뿐입니다. 따라서 멀티 스레딩의 대안이 아닙니다.
메시지 구동 Bean의 경우 컨테이너가 스레드를 만들고 관리하여 멀티 스레딩의 대안이 아니며 단순히 다른 사람의 구현을 사용하는 것입니다.
메시징을 사용하여 추가 네트워크 계층을 추가하기 때문에 성능이 뛰어난 멀티 스레딩이 모든 메시징보다 빠릅니다.
응용 프로그램 별 메시징은 공용 객체가 없으므로 잠금 및 데이터 공유 문제를 방지 할 수 있습니다.
확장 성 관점 메시징은 응용 프로그램을 변경하는 대신 메시지 서비스를 구성하여 여러 서버에서 노드를 더 많이 구성 할 수 있으므로 훨씬 유용합니다.
메시징은 데이터 경쟁 위험을 줄이므로 다중 스레드 응용 프로그램의 오류 수를 크게 줄일 수 있습니다. 또한 나머지 응용 프로그램을 변경하지 않고 새 스레드를 간단하게 추가 할 수 있습니다.
여기서는 JMS가 약간 잘못 사용 된 것 같습니다. java.util.concurrent의 스레드 안전 큐와 jetlang과 같은 라이브러리는 더 나은 성능을 제공 할 수 있습니다.
EJB 컨테이너에는 실제로는 EJB 컨테이너에 자신의 스레드를 만들 수 없기 때문에 대안이 없습니다. JMS는 큐 프로세서를 통해 실행하는 대신에 모든 작업을 수행합니다. 컨테이너와 더 밀접한 관계가있는 (따라서 스레드를 가질 수도있는) Java Connector를 만들 수도 있지만 훨씬 더 많은 작업이 필요합니다.
JMS 대기열을 사용하는 오버 헤드가 성능에 영향을 미치지 않으면 가장 쉬운 해결책입니다. 거래 및 내구성 : 내가 언급하고있다 생각하지 않는다 두 개의 추가 보너스가
입니다. 기술적으로 J2EE 컨테이너에 스레드를 생성해서는 안되지만 사람들이 웹 컨테이너에서이 작업을 수행하는 것이 일반적입니다. J2EE 스펙은 규칙보다 더 많은 지침으로 간주되어야합니다. 결국 그것은 파일 시스템에 직접 접근하는 것을 허락하지 않지만, 사람들은 설정 파일 등으로 항상 이것을한다. 특히 봄을 사용할 때. – cletus
있습니다.
필수 구성 요소는 아니지만 기본 구성이 아니더라도 JMS 공급자는 메시지를 유지하고 코드를 거의 변경하지 않고 XA 트랜잭션에 참여하도록 구성 할 수 있습니다.
예, 시스템/모듈을 분리하는 좋은 방법입니다. 시스템의 시스템을 서버 충돌과 같은 기술적 인 문제에 훨씬 더 탄력적으로 만듭니다. –
대부분의 경우 비동기 메시징은 * 멀티 스레딩 – skaffman