JMS는 무엇에 좋은가요? [닫은
https://stackoverflow.com/questions/222017
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
JMS가 좋은 솔루션 인 문제의 (간단한) 사례를 찾고 있으며, 이러한 경우 JMS가 좋은 솔루션 인 이유를 찾고 있습니다. 과거에는 메시지를 즉시 B로 처리 할 수없는 경우 메시지를 A에서 B로 전달하는 수단으로 데이터베이스를 사용했습니다.
이러한 시스템의 가상의 예는 새로 등록 된 모든 사용자에게 등록 후 24 시간 이내에 환영 이메일을 보내야하는 곳입니다. 인수를 위해 DB가 각 사용자가 등록 된 시간을 기록하지 않고 대신 각 새 사용자에 대한 참조 (외국 키)가 pending_email 테이블에 저장된다고 가정합니다. 전자 메일 발신자 작업은 24 시간마다 한 번씩 실행 되며이 테이블의 모든 사용자에게 이메일을 보낸 다음 모든 보드 _email 레코드를 삭제합니다.
이것은 JMS를 사용해야하는 종류의 문제처럼 보이지만 JMS가 내가 설명한 접근 방식에 어떤 이점이 있는지는 명확하지 않습니다. DB 접근법의 장점 중 하나는 메시지가 영구적이라는 것입니다. JMS 메시지 대기열도 지속될 수 있음을 이해하지만,이 경우 JMS와 "Message Deue"접근 방식 사이에 차이가 거의없는 것 같습니다.
내가 무엇을 놓치고 있습니까? - 두목
해결책
JMS와 메시징은 실제로 완전히 다른 두 가지입니다.
- 게시 및 구독 (관심있는만큼 많은 소비자에게 메시지 보내기 - 이메일을 메일 링리스트로 전송하는 것과 같은 발신자는 누가 구독했는지 알 필요가 없습니다.
- 고성능 안정적인로드 밸런싱 (메시지 대기열)
자세한 내용을 참조하십시오 대기열이 주제와 비교되는 방법
당신이 말하는 경우는 두 번째 사례입니다. 예, 데이터베이스 테이블을 사용하여 메시지 대기열을 시뮬레이션 할 수 있습니다.
주요 차이점은 JMS 메시지 대기열이 거대한 처리량을 위해 설계된 고성능 고도로 동시로드 밸런서입니다. 많은 프로세스와 스레드에서 많은 동시 소비자에게 초당 수만 개의 메시지를 보낼 수 있습니다. 그 이유는 메시지 대기열이 기본적으로 비동기식이기 때문입니다. 좋은 JMS 제공 업체는 각 소비자에게 미리 메시지를 스트리밍합니다. 따라서 소비자를 사용할 수있는 즉시 RAM으로 처리 할 수있는 수천 개의 메시지가 있습니다. 이로 인해 대규모 통 트리션과 대기 시간이 매우 낮습니다.
예를 들어 데이터베이스 테이블을 사용하여 웹로드 밸런서 작성을 상상해보십시오 :)
데이터베이스 테이블을 사용하는 경우 일반적으로 하나의 스레드는 전체 테이블을 잠그는 경향이 있으므로 고성능로드 밸런서를 구현할 때 처리량이 매우 낮아지는 경향이 있습니다.
그러나 대부분의 미들웨어와 마찬가지로 그것은 모두 필요한 것에 달려 있습니다. 초당 몇 가지 메시지만으로 처리량 시스템이 낮은 경우 데이터베이스 테이블을 큐로 사용하십시오. 그러나 낮은 대기 시간과 높은 처리량이 필요한 경우 JMS 대기열을 적극 권장합니다.
다른 팁
제 생각에는 JMS 및 기타 메시지 기반 시스템은 필요한 문제를 해결하기위한 것입니다.
- 비동기 커뮤니케이션 : 응용 프로그램은 응답을 기다릴 필요없이 이벤트가 발생했음을 다른 사람에게 알릴 필요가 있습니다.
- 신뢰할 수 있음. 전용으로 전용 메시지 전달을 확인하십시오. DB 접근 방식을 사용하면 특히 여러 클라이언트가 메시지를 읽는 경우 "휠을 재창조"해야합니다.
- 느슨한 결합. 모든 시스템이 데이터베이스를 사용하여 통신 할 수있는 것은 아닙니다. 따라서 JMS는 시스템 경계를 통해 통신 할 수있는 디퍼링 된 시스템이있는 이기종 환경에서 사용하기가 매우 좋습니다.
JMS 구현은 새 메시지를 발견하기 위해 대기열을을을 투표 할 필요가 없다는 점에서 "푸시"입니다. 그러나 새 메시지가 도착하자마자 호출되는 콜백을 등록합니다.
원래 의견을 다루기 위해. 원래 설명 된 것은 (지점 간) JMS의 요점입니다. 그러나 JMS의 이점은 다음과 같습니다.
코드를 직접 작성할 필요는 없습니다 (그리고 논리를 생각하는 것만 큼 지속되지 않도록 논리를 망칠 수 있습니다). 또한 타사 명단은 간단한 데이터베이스 접근 방식보다 더 확장 가능할 수 있습니다.
JMS는 게시/구독을 처리합니다.
특정 구현에 묶여 있지 않으며 향후 요구 사항이 변경되면 Java 코드가없는 혼란을 일으킬 수 있습니다.
JMS의 장점 중 하나는 데이터베이스 솔루션에 의해 수행 할 수있는 비동기 처리를 가능하게하는 것입니다. 그러나 다음은 데이터베이스 솔루션보다 JMS의 다른 이점입니다.
a) 메시지 소비자는 원격 위치에있을 수 있습니다. 원격 액세스를위한 데이터베이스 노출은 위험합니다. 더 많은 노력이 필요한 데이터베이스에서 메시지를 읽기위한 추가 서비스를 제공하여이를 해결할 수 있습니다.
b) 데이터베이스의 경우 메시지 소비자는 메시지가 도착했을 때 콜백을 제공하는 메시지에 대해 데이터베이스를 설문 조사해야합니다 (SK에 언급 된대로)
c)로드 밸런싱 - 메시지가 많이 있으면 JMS에 메시지 프로세서 풀을 쉽게 설치할 수 있습니다.
d) JMS를 통한 일반적인 구현에서는 데이터베이스 경로보다 단순하고 노력이 적습니다.
JMS는 둘 이상의 클라이언트간에 메시지를 전송하는 데 사용되는 API입니다. 사양은 JSR 914에 따라 정의됩니다.
JMS의 주요 장점은 통신 엔티티의 분리 된 특성입니다. 발신자는 수신자에 대한 정보가 필요하지 않습니다. 다른 장점으로는 이기종 플랫폼을 통합하고 시스템 병목 현상을 줄이고 확장 성을 높이며 변화에 더 빨리 반응하는 기능이 있습니다.
JMS는 일종의 인터페이스/API이며 콘크리트 클래스를 구현해야합니다. 이들은 이미 다양한 조직/공급자가 구현했습니다. 그들은 JMS 제공 업체라고합니다. 예 WebSphere IBM 또는 Fioranomq Apache, Hornetq, OpenMQ 등의 Fiorano SoftWares 또는 ActiveMQ에 의해 사용 된 다른 용어는 관리자 개체 (주제, 대기열, ConnectionFactories), JMS Producer/Publisher, JMS Client 및 The Message 자체입니다.
그래서 당신의 질문에 오십시오 - what is JMS good for?나는 그것이 중요하다는 것을 설명하기 위해 실용적인 예를 제시하고 싶습니다.
당일 거래
이 기능이 호출됩니다 LVC(마지막 가치 캐시)
거래에서 주가는 정기적으로 게시자가 게시합니다. 각 주식에는 관련된 주제가 있습니다. 이제 주제가 무엇인지 알고 있다면 메시지가 줄처럼 저장되지 않는다는 것을 알아야합니다. 메시지가 게시 당시에 살아있는 가입자에게 메시지가 게시됩니다 (예외는 생성 된 시점부터 모든 메시지를 게시하는 내구성 가입자입니다. 사용). 따라서 고객이 주가를 알고 싶어한다면 가입자를 만들고 다음 주가가 게시 될 때까지 기다려야합니다 (다시 원하는 것이 아닙니다). LVC가 사진을 찍는 곳입니다. 각 LVC 메시지에는 관련 키가 있습니다. 메시지가 LVC 키 (특정 주식의 경우)와 함께 전송되고 동일한 키가있는 다른 업데이트 메시지가 표시되면 나중에 이전의 메시지를 무시합니다. 가입자가 LVC가 활성화 된 주제 (LVC가 활성화 된)를 가입하면 가입자는 고유 한 LVC 키로 모든 메시지를받습니다. 상장 회사 당 뚜렷한 키를 유지하면 클라이언트가 구독하면 최신 주가와 결국 모든 업데이트를 얻게됩니다.
물론 이것은 JMS를 강력하게 만드는 신뢰성, 보안 등의 다른 요인 중 하나입니다.
Guido는 전체 정의를 가지고 있습니다. 내 경험을 통해이 모든 것은 잘 맞는 데 중요합니다.
내가 본 용도 중 하나는 창고의 주문 배포입니다. 사무용품을 공급하는 상당수의 창고가있는 사무용 공급 회사를 상상해보십시오. 이러한 주문은 중앙 위치로 들어온 다음 올바른 창고가 배포 할 수 있도록 배치됩니다. 창고는 대부분의 경우 고속 연결이 없거나 고속 연결을 원하지 않으므로 주문이 전화 접속 모뎀을 통해 그들에게 푸시됩니다. 이것은 비동기식이 들어오는 곳입니다. 전화선은 실제로 그다지 중요하지 않으므로 주문의 절반이 들어올 수 있습니다. 신뢰성이 중요한 곳입니다.
주요 장점은 COMON 데이터베이스를 공유하거나 사용자 정의 서비스를 구축하여 데이터를 전달하는 것보다는 관련없는 시스템을 분리하는 것입니다.
은행은 예리한 예이며, 실시간 데이터 변경을 통과하는 데 사용됩니다. 소스 시스템이 "벽 위에"메시지를 던지는 것은 매우 쉽습니다. 단점은 이러한 시스템간에 계약 방식이 거의 없으며 일반적으로 소비자 측에서 입원이 구현되는 것을 볼 수 있습니다. 거의 너무 느슨하게 결합되어 있습니다.
다른 이점은 많은 응용 프로그램 서버 등의 모든 도구와 같은 모든 도구와 같은 내구성, 모니터링,보고 및 조절기의 모든 도구를 지원하는 것입니다.
여기에는 몇 가지 예가있는 좋은 글이 있습니다. http://www.winslam.com/laramee/jms/index.html
'메시지 대기열로서의 데이터베이스'솔루션은 작업에 무거울 수 있습니다. JMS 솔루션은 메시지 발신자가 수신자에 대해 아무것도 알 필요가 없다는 점에서 덜 단단히 결합됩니다. 이것은 '메시지 큐로서의 데이터베이스'에서 약간의 추가 추상화로 달성 될 수 있으므로 큰 승리가 아닙니다 ... 또한 '게시 및 구독'방식으로 큐를 사용할 수 있으며, 무엇에 따라 유용 할 수 있습니다. 당신은 성취하려고 노력하고 있습니다. 또한 구성 요소를 더 해체 할 수있는 좋은 방법입니다. 모든 커뮤니케이션이 하나의 시스템 내에 있거나/또는 응용 프로그램에서 즉시 사용할 수있는 로그가있는 경우 방법이 좋아 보입니다. 별도의 시스템간에 의사 소통하는 경우 JMS가 좋은 선택입니다.
JMA (Java Transaction API) 및 JPA (Java Persistence API)와 함께 JMS가 매우 유용 할 수 있습니다. 간단한 주석을 사용하면 동일한 트랜잭션에서 여러 데이터베이스 조치 + 메시지 보내기/수신을 할 수 있습니다. 따라서 그중 하나가 실패하면 동일한 트랜잭션 메커니즘을 사용하여 모든 것이 롤백됩니다.
