JMS 대신 Scala의 액터를 선호하는 디자인 결정은 무엇입니까?
JMS 대신 Scala Actor를 사용하는 차이점은 무엇입니까?
예를 들어 성능 및 확장 성 관점에서 Scala Actor 모델이 JMS에 비해 추가하는 것은 무엇입니까? 어떤 경우에 JMS보다 액터를 사용하는 것이 더 합리적입니까? 즉, JMS가 처리 할 수없는 액터가 다루는 문제는 무엇입니까?
JMS와 Scala 액터는 이론상 유사성을 공유하지만 반드시 동일한 문제를 구조적으로 해결하는 것으로 생각하지는 않습니다. 액터는 레이스와 교착 상태가 일반적으로 실수로 생성하기가 더 어려운 공유 메모리 동시성에 대한 가벼운 대안입니다. JMS는 직접 메시징, 게시 / 구독, 트랜잭션, EJB 통합 등을 포괄하는 정교한 API입니다.
행위자에 해당하는 가장 가까운 JMS는 비 영구적이고 트랜잭션이없는 비공개 / 구독 큐에 의해 지원되는 메시지 구동 Bean입니다. 이것을 "단순 JMS 빈"이라고 부를 것입니다.
이제 귀하의 질문에.
JMS는 구현이 아닌 사양이기 때문에 성능에 대해 이야기하기 어렵습니다. 그럼에도 불구하고 간단한 JMS bean을 사용할 때 성능이 시간과 메모리 측면에서 액터에 약간의 우위를두고 거의 비슷할 것으로 예상합니다. pub / sub, 트랜잭션 등과 같은 기능을 JMS에 추가하면 자연스럽게 성능이 더욱 저하되지만 사과와 오렌지를 비교하려고합니다.
확장성에 관해서는 간단한 JMS bean은 액터와 거의 동일한 방식으로 확장되어야합니다. JMS 믹스에 트랜잭션을 추가하면 트랜잭션 범위에 따라 자연스럽게 확장 성이 저하됩니다.
JMS가 할 수없는 행위자가 무엇을 하는가에 대한 더 광범위한 질문. 음, 내장 된 pub sub 또는 트랜잭션이 없으면 행위자가 JMS에서 빼는 것처럼 보일 것입니다. 대체로 그것은 사실입니다. 하지만 여기에 문제가 있습니다. 액터는 매우 작은 코드를 필요로하기 때문에 매우 미세한 동시성을 위해 기꺼이 사용할 수 있습니다. 일반적인 Java 코드에서는 "JMS와 그 종속성 또는 필요한 코드 등을 망쳐 놓고 싶지 않아서 스레드를 생성하고 잠금을 사용하고 데이터 구조를 공유 할 것입니다."라고 말할 수 있습니다. 스칼라 배우들과 함께 저는 "배우를 채찍질하고 넘어가겠습니다"라고 말할 가능성이 훨씬 더 높습니다.
디자인에도 철학적 차이가 있습니다. 액터에는 수퍼바이저 계층 구조라는 단순하고 내장 된 개념이 있습니다. 액터는 일반적으로 "let it crash"디자인에 사용됩니다. 배우가 어떤 이유로 죽으면 다른 배우는 그 배우를 다시 시작하고, 여러 배우를 죽이고 모두를 다시 시작하거나, 다른 배우가 할 수 있도록 여러 배우와 자신을 죽이는 등 어떻게해야할지 결정할 책임이 있습니다. 문제를 처리하십시오. 이런 종류의 것은 JMS에 추가 할 수 있지만 API의 핵심이 아니므로 어떻게 든 외부에서 관리해야합니다.
그건 그렇고, JMS가 다루는 영역으로 더 많이 이동하는 Scala 액터 라이브러리에 대해서는 Akka를 참조하십시오 . Akka는 또한 많은 일반적인 행위자 계층 전략에 선언적 접근 방식을 제공합니다.
'Development Tip' 카테고리의 다른 글
| 문자열 연결 대신 {}를 사용하여 형식화하는 Logger slf4j 장점 (0) | 2020.10.05 |
|---|---|
| FTL 파일이란? (0) | 2020.10.05 |
| 클라이언트 측의 JavaScript require () (0) | 2020.10.05 |
| System.Double을 '0'(숫자, 정수?)과 비교하는 올바른 방법 (0) | 2020.10.04 |
| ng-model 동적 할당 (0) | 2020.10.04 |