JMS의 장점은 무엇입니까?
저는 JMS가 좋은 솔루션 인 문제의 (간단한) 예와 이러한 경우에 JMS가 좋은 솔루션 인 이유를 찾고 있습니다. 과거에는 B가 메시지를 즉시 처리 할 수없는 경우 A에서 B로 메시지를 전달하는 수단으로 데이터베이스를 사용했습니다.
이러한 시스템의 가상 예는 새로 등록 된 모든 사용자에게 등록 후 24 시간 이내에 환영 이메일을 보내야하는 경우입니다. 인수를 위해 DB는 각 사용자가 등록한 시간을 기록하지 않고 대신 각 새 사용자에 대한 참조 (외래 키)가 pending_email 테이블에 저장되어 있다고 가정합니다. 이메일 발신자 작업은 24 시간마다 한 번씩 실행되고이 테이블의 모든 사용자에게 이메일을 보낸 다음 모든 pending_email 레코드를 삭제합니다.
이것은 JMS를 사용해야하는 종류의 문제처럼 보이지만 내가 설명한 접근 방식에 비해 JMS가 어떤 이점을 가질지는 분명하지 않습니다. DB 접근 방식의 한 가지 장점은 메시지가 지속적이라는 것입니다. JMS 메시지 큐도 지속될 수 있다는 것을 이해합니다.하지만이 경우 JMS와 제가 설명한 "데이터베이스로서의 메시지 큐"접근 방식 사이에 약간의 차이가있는 것 같습니다.
내가 무엇을 놓치고 있습니까? -돈
JMS와 메시징은 실제로는 완전히 다른 두 가지입니다.
- 게시 및 구독 (관심있는 많은 소비자에게 메시지 보내기-메일 링리스트에 이메일을 보내는 것과 비슷하므로 보낸 사람은 구독자가 누구인지 알 필요가 없습니다.)
- 고성능의 안정적인로드 밸런싱 (메시지 큐)
대기열이 주제 와 어떻게 비교되는지 에 대한 자세한 정보보기
두 번째 경우는 데이터베이스 테이블을 사용하여 메시지 대기열을 시뮬레이션 할 수있는 두 번째 경우입니다.
가장 큰 차이점은 JMS 메시지 큐는 엄청난 처리량을 위해 설계된 고성능 동시로드 밸런서입니다. 일반적으로 많은 프로세스와 스레드에서 많은 동시 소비자에게 초당 수만 개의 메시지를 보낼 수 있습니다. 그 이유는 메시지 대기열이 기본적으로 매우 비동기 적이기 때문입니다. 좋은 JMS 공급자는 각 소비자에게 미리 메시지를 스트리밍 하므로 소비자가 사용 가능 해지는 즉시 RAM에서 처리 할 수있는 수천 개의 메시지가 있습니다. 이는 엄청난 처리량과 매우 낮은 대기 시간으로 이어집니다.
예를 들어 데이터베이스 테이블을 사용하여 웹로드 밸런서를 작성한다고 상상해보십시오. :)
데이터베이스 테이블을 사용할 때 일반적으로 하나의 스레드가 전체 테이블을 잠그는 경향이 있으므로 고성능로드 밸런서를 구현하려고 할 때 처리량이 매우 낮아지는 경향이 있습니다.
그러나 대부분의 미들웨어와 마찬가지로 모든 것은 필요한 것에 달려 있습니다. 초당 몇 개의 메시지 만있는 낮은 처리량 시스템의 경우 데이터베이스 테이블을 대기열로 자유롭게 사용하십시오. 그러나 짧은 대기 시간과 높은 처리량이 필요한 경우 JMS 대기열을 적극 권장합니다.
제 생각에는 JMS 및 기타 메시지 기반 시스템은 다음이 필요한 문제를 해결하기위한 것입니다.
- 비동기 통신 : 애플리케이션은 응답을 기다릴 필요없이 이벤트가 발생했음을 다른 사용자에게 알려야합니다.
- 신뢰성 . 단 한 번의 메시지 전달을 보장합니다. DB 접근 방식에서는 특히 메시지를 읽는 여러 클라이언트가있는 경우 "바퀴를 재발 명"해야합니다.
- 느슨한 결합 . 모든 시스템이 데이터베이스를 사용하여 통신 할 수있는 것은 아닙니다. 따라서 JMS는 시스템 경계를 통해 통신 할 수있는 분리 된 시스템이있는 이기종 환경에서 사용하기에 매우 좋습니다.
JMS 구현은 새 메시지를 찾기 위해 큐를 폴링 할 필요가 없다는 점에서 "푸시"이지만 새 메시지가 도착하자마자 호출되는 콜백을 등록합니다.
원래 의견을 처리합니다. 원래 설명 된 것은 (지점 간) JMS의 요점입니다. 그러나 JMS의 이점은 다음과 같습니다.
코드를 직접 작성할 필요가 없습니다 (그리고 생각만큼 영속적이지 않도록 논리를 망칠 수도 있습니다). 또한 타사 impl은 단순한 데이터베이스 접근 방식보다 확장 성이 더 클 수 있습니다.
jms는 발행 / 구독을 처리합니다. 이는 귀하가 제공 한 지점 간 예제보다 조금 더 복잡합니다.
특정 구현에 묶여 있지 않으며 향후 필요가 변경되면 Java 코드를 엉망으로 만들지 않고 바꿀 수 있습니다.
JMS의 장점 중 하나는 데이터베이스 솔루션으로도 수행 할 수있는 비동기 처리를 가능하게하는 것입니다. 그러나 다음은 데이터베이스 솔루션에 비해 JMS의 다른 이점입니다.
a) 메시지 소비자는 원격 위치에있을 수 있습니다. 원격 액세스를 위해 데이터베이스를 노출하는 것은 위험합니다. 더 많은 노력이 필요한 데이터베이스에서 메시지를 읽기위한 추가 서비스를 제공하여이 문제를 해결할 수 있습니다.
b) 데이터베이스의 경우 메시지 소비자는 메시지가 도착했을 때 JMS가 콜백을 제공하는 메시지에 대해 데이터베이스를 폴링해야합니다.
c)로드 밸런싱-많은 메시지가 들어 오면 JMS에 메시지 프로세서 풀을 갖기 쉽습니다.
d) 일반적으로 JMS를 통한 구현은 데이터베이스 경로보다 간단하고 적은 노력이 필요합니다.
JMS는 둘 이상의 클라이언트간에 메시지를 전송하는 데 사용되는 API입니다. 사양은 JSR 914에 정의되어 있습니다.
JMS의 주요 장점은 통신 엔티티의 분리 된 특성입니다. 발신자는 수신자에 대한 정보를 가질 필요가 없습니다. 다른 장점으로는 이기종 플랫폼을 통합하고, 시스템 병목 현상을 줄이고, 확장 성을 높이고, 변화에보다 빠르게 대응할 수있는 기능이 있습니다.
JMS는 일종의 인터페이스 / API이며 구체적인 클래스를 구현해야합니다. 이들은 이미 다양한 조직 / 제공 업체에서 구현하고 있습니다. 이를 JMS 제공자라고합니다. 예 를 들어 IBM의 WebSphere 또는 Fiorano Softwares의 FioranoMQ 또는 Apache, HornetQ, OpenMQ 등의 ActiveMQ입니다. 사용되는 다른 용어로는 Admin Objects (Topics, Queues, ConnectionFactories), JMS 생산자 / 게시자, JMS 클라이언트 및 메시지 자체가 있습니다.
그래서 귀하의 질문에- what is JMS good for?
나는 그것이 중요성을 설명하기 위해 실용적인 예를 제공하고 싶습니다.
데이 트레이딩
LVC (Last value cache) 라는 기능이 있습니다.
거래에서 주가는 발행인이 정기적으로 발행합니다. 각 공유에는 게시 된 관련 주제가 있습니다. 이제 토픽이 무엇인지 안다면 메시지가 큐처럼 저장되지 않는다는 것을 알아야합니다. 메시지는 메시지가 게시 된 시점에 살아있는 구독자에게 게시됩니다 (생성 된 시점부터 모든 메시지를 게시 한 Durables 구독자는 예외이지만 다시 한 번 너무 오래된 주가를 얻고 싶지 않아 그것을 사용). 따라서 클라이언트가 주가를 알고 싶다면 구독자를 만들고 다음 주가가 발표 될 때까지 기다려야합니다 (다시 우리가 원하는 것이 아닙니다). 이것이 LVC가 등장하는 곳입니다. 각 LVC 메시지에는 연관된 키가 있습니다. LVC 키 (특정 주식에 대한)와 함께 메시지가 전송 된 다음 동일한 키가있는 다른 업데이트 메시지가 전송되면 나중에 이전 메시지가 무시됩니다. 구독자가 LVC가 활성화 된 토픽을 구독 할 때마다 구독자는 고유 한 LVC 키가있는 모든 메시지를 받게됩니다. 상장 회사별로 고유 한 키를 유지하면 고객이 구독 할 때 최신 주가와 결국 모든 업데이트를 받게됩니다.
물론 이것은 JMS를 강력하게 만드는 신뢰성, 보안 등의 다른 요소 중 하나입니다.
귀도는 완전한 정의를 가지고 있습니다. 내 경험으로 볼 때이 모든 것이 잘 맞는 데 중요합니다.
제가 본 용도 중 하나는 창고에서의 주문 분배입니다. 대규모 사무실에 사무용품을 공급하는 창고가 상당히 많은 사무용품 회사를 상상해보십시오. 이러한 주문은 중앙 위치로 들어간 다음 올바른 창고가 배포되도록 일괄 처리됩니다. 창고는 대부분의 경우 고속 연결이 없거나 필요하지 않으므로 주문은 전화 접속 모뎀을 통해 주문이 전달되며 여기에서 비동기가 들어오는 곳입니다. 전화선도 그다지 중요하지 않으므로 주문의 절반이 들어오고 이것은 신뢰성이 중요한 곳입니다.
주요 이점은 관련없는 시스템이 공통 데이터베이스를 공유하거나 데이터를 전달하기위한 맞춤형 서비스를 구축하는 것보다 분리하는 것입니다.
은행은 실시간 데이터 변경이 발생하는 즉시 전달하는 데 사용되는 하루 중 메시징을 사용하는 예입니다. 소스 시스템이 "벽 너머"라는 메시지를 던지는 것은 매우 쉽습니다. 단점은 이러한 시스템 간의 계약 방식이 거의 없으며 일반적으로 소비자 측에서 입원이 시행되는 것을 볼 수 있습니다. 그것은 거의 너무 느슨하게 결합되어 있습니다.
다른 이점은 많은 애플리케이션 서버 등에 대한 JMS 지원과 그와 관련된 모든 도구 (내구성, 모니터링,보고 및 조절)에 있습니다.
여기에 몇 가지 예가있는 멋진 글이 있습니다. http://www.winslam.com/laramee/jms/index.html
The 'database as message queue' solution may be heavy for the task. The JMS solution is less tightly coupled in that the message sender does not need to know anything about the recipient. This could be accomplished with some additional abstraction in the 'database as message queue' as well so it is not a huge win...Also, you can use the queue in a 'publish and subscribe' way which can be handy depending on what you are trying to accomplish. It is also a nice way to further decouple your components. If all of your communication is within one system and/or having a log that is immediately available to an application is very important, your method seems good. If you are communicating between separate systems JMS is a good choice.
JMS in combination with JTA (Java Transaction API) and JPA (Java persistence API) can be very useful. With a simple annotation you can put several database actions + message sending/receiving in the same transaction. So if one of them fails everything gets rolled back using the same transaction mechanism.
참고URL : https://stackoverflow.com/questions/222017/what-is-jms-good-for
'developer tip' 카테고리의 다른 글
C ++ std :: ref (T)와 T &의 차이점은 무엇입니까? (0) | 2020.10.29 |
---|---|
JavaScript에서 Array.map으로 요소 제거 (0) | 2020.10.29 |
WPF 확인란 바인딩 (0) | 2020.10.29 |
리플렉션을 통해 한 클래스의 필드에서 다른 클래스로 모든 값 복사 (0) | 2020.10.29 |
자바로 웹 스크래핑 (0) | 2020.10.29 |