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에서 빼는 것처럼 보일 것입니다. 대체로 그것은 사실입니다. 하지만 여기에 문제가 있습니다. 액터는 매우 작은 코드를 필요로하기 때문에 매우 미세한 동시성을 위해 기꺼이 사용할 수 있습니다. 일반적인 자바 코드에서는 “JMS와 그 종속성 또는 필요한 코드 등을 망쳐 놓고 싶지 않아서 스레드를 생성하고 잠금을 사용하고 데이터 구조를 공유 할 것입니다.”라고 말할 수 있습니다. 스칼라 배우들과 함께 저는 “배우를 채찍질하고 넘어가겠습니다”라고 말할 가능성이 훨씬 더 높습니다.
디자인에도 철학적 차이가 있습니다. 액터는 수퍼바이저 계층 구조의 단순하고 내장 된 개념을 가지고 있습니다. 액터는 일반적으로 “let it crash”디자인에 사용됩니다. 어떤 이유로 배우가 죽으면 다른 배우가 그 배우를 다시 시작하고, 여러 배우를 죽이고 모두를 다시 시작하거나, 다른 배우가 할 수 있도록 여러 배우와 자신을 죽이는 등 어떻게해야할지 결정할 책임이 있습니다. 문제를 처리하십시오. 이런 종류의 것은 JMS에 추가 할 수 있지만 API의 핵심이 아니므로 어떻게 든 외부에서 관리해야합니다.
그건 그렇고, JMS가 다루는 영역으로 더 많이 이동하는 Scala 액터 라이브러리에 대해서는 Akka를 참조하십시오 . Akka는 또한 많은 일반적인 행위자 계층 전략에 선언적 접근 방식을 제공합니다.
