WebSphere MQ 또는 Tibco Rendezvous와 같은 메시징 솔루션 대신 액터를 사용해야 하는 경우

WebSphere MQ 또는 Tibco Rendezvous와 같은 메시징 솔루션 대신 액터를 사용해야 하는 경우

JMS 대신 스칼라의 액터스를 선호하는 디자인 결정은 무엇입니까?에 대한 질문과 답변을 이미 읽었습니다.

일반적으로 우리는 이미 수년 전부터 존재해 온 메시징 솔루션을 사용합니다. WebSphere MQ 또는 Apache ActiveMQ와 같은 JMS 구현은 포인트 투 포인트 통신에 사용되고 Tibco Rendevous는 멀티캐스트 메시징에 사용됩니다.

매우 안정적이고 성능이 입증되었으며 높은 가용성과 성능을 제공합니다.그럼에도 불구하고 구성과 설정은 Akka보다 훨씬 더 복잡해 보입니다.

앞서 언급한 제품(WebSphere MQ 또는 ActiveMQ)이 지금까지 성공적으로 사용된 일부 사용 사례에 Akka를 사용해야 하는 시기와 이유는 무엇입니까?향후 프로젝트에서 WebSphere MQ 또는 Tibco RV 대신 Akka를 사용해야 하는 이유는 무엇입니까?

아카는 언제 피해야 하나요?다른 솔루션과 동일한 고가용성 및 성능을 제공합니까?아니면 Akka를 다른 메시징 소프트웨어와 비교하는 것조차 나쁜 생각일까요?

JVM 환경에서 JMS(Point-to-Point), TibcoRV(멀티캐스트) 및 Akka 외에 고려해야 할 메시징 솔루션이 있습니까?

우선, "오래된" 메시지 시스템(MQ)은 구현에서는 오래된 것이지만, 엔지니어링 측면에서는 새로운 개념인 트랜잭션 지속 큐입니다.Scala Actors와 Akka는 새로운 구현일 수 있지만 Actors의 오래된 동시성 모델을 기반으로 합니다.

그러나 두 모델은 모두 이벤트메시지 기반이기 때문에 실제로는 매우 비슷합니다.토끼에게 내 대답 보기MQ vs Akka.

JVM만을 위해 코드를 작성하려면 Akka를 선택하는 것이 좋습니다.그렇지 않으면 Rabbit MQ를 사용합니다.

또한 당신이 Scala 개발자인 경우, Akka는 쉬운 방법입니다.그러나 Akka의 Java 바인딩은 Java와 비슷하지 않으며 Scala의 유형 시스템으로 인해 캐스팅이 필요합니다.

또한 자바에서는 보통 메시징을 위해 추천하는 불변의 오브젝트를 만들지 않습니다.따라서 Java에서는 Akka를 사용하여 실수로 확장되지 않는 작업을 수행하는 것이 매우 쉽습니다(메시지에 가변 객체를 사용하고, 이상한 폐쇄 콜백 상태에 의존합니다).메시지는 항상 속도를 희생하여 시리얼화되므로 MQ에서는 문제가 되지 않습니다.Akka에서는 그들은 일반적으로 그렇지 않다.

또한 Akka는 대부분의 MQ보다 더 많은 소비자와 더 잘 확장됩니다. 이는 대부분의 MQ(JMS, AMQP) 클라이언트의 경우 모든 큐 연결에는 스레드가 필요하기 때문입니다.따라서 많은 큐 == 영구적으로 실행되는 많은 스레드.이것은 주로 클라이언트의 문제입니다.ActiveMQ Apollo에는 AMQP의 문제를 해결하는 논블로킹 디스패처가 있다고 생각합니다.토끼MQ 클라이언트에는 여러 컨슈머를 결합할 수 있는 채널이 있지만 다수의 컨슈머가 데드록 또는 접속을 정지시킬 수 있는 문제가 남아 있기 때문에 일반적으로 이 문제를 피하기 위해 더 많은 스레드가 추가됩니다.

Akka의 리모트는 새로운 것으로, 종래의 메시지 큐가 제공하는 신뢰성 높은 메시지 보증과 QoS를 모두 제공하는 것은 아닐지도 모릅니다(그러나, 매일 변화하고 있습니다).또한 일반적으로 피어투피어(peer-to-peer)를 지원하지만, 대부분의 MQ 시스템이 하는 것과 같은 서버 투 피어(즉, 싱글 포인트 장애)를 서포트하고 있다고 생각합니다만, 피어 투 피어(Rabbit)인 MQ 시스템이 있습니다.MQ는 서버 투 피어입니다).

드디어 Rabbit MQ와 Akka가 잘 어울립니다.Akka를 Rabbit에게 포장지로 사용할 수 있습니다.MQ는 특히 Rabbit 이후부터MQ는 메시지 소비 처리 및 로컬(단일 JVM 내) 메시지 라우팅에는 도움이 되지 않습니다.

Akka를 선택하는 시기

• 소비자가 많다.
• 짧은 레이텐시 필요
• Actor 동시성 모델에 대해 열기

시스템 예:대화식 실시간 채팅 시스템

MQ 선택 시기

• 다양한 시스템(JVM 이외)과의 통합 필요
• 메시지 신뢰성이 레이텐시보다 중요
• 더 많은 툴과 관리 UI를 원합니다.
• 이전 점 때문에 장시간 실행 태스크에 더 적합합니다.
• Actors와 다른 동시성 모델을 사용하려고 합니다.

시스템 예:일정된 트랜잭션 일괄 처리 시스템

관련된 코멘트에 근거한 편집

OP는 Akka와 Message Queues가 모두 처리할 수 있는 분산처리에 관한 것이라고 가정했습니다.분산된 아카에 대해 말하는 줄 알았는데요로컬 동시 처리를 위해 Akka를 사용하는 것은 대부분의 메시지 큐와 비교됩니다.메시지 큐 모델을 동시성 모델(토픽, 큐, 교환)로 로컬에 적용할 수 있기 때문에 React 라이브러리와 simple-react가 모두 적용되기 때문입니다.

저지연 어플리케이션에서는 적절한 동시성 모델/라이브러리를 선택하는 것이 매우 중요합니다.메시지 큐와 같은 분산 처리 솔루션은 일반적으로 이상적이지 않습니다.이는 라우팅이 거의 항상 회선을 통해 이루어지기 때문에 애플리케이션 내에서보다 속도가 느리기 때문에 Akka가 우수한 선택이기 때문입니다.단, 일부 독자적인 MQ 테크놀로지는 로컬 루팅을 가능하게 한다고 생각합니다.또한 앞서 언급했듯이 대부분의 MQ 클라이언트는 스레드에 대해 매우 어리석고 논블로킹 IO에 의존하지 않으며 연결/큐/채널마다 스레드가 있습니다.아이러니컬하게도 non-time io는 항상 짧은 지연 시간은 아니지만 일반적으로 리소스 효율성이 더 높습니다.

보시다시피 분산 프로그래밍과 동시 프로그래밍의 주제는 크고 매일 변하기 때문에 저의 원래 의도는 혼란스럽지 않고 분산 메시지 처리의 특정 영역인 OP에 중점을 두고 있었습니다.동시성 측면에서, 이러한 모든 모델이 이벤트 기반이기 때문에 일반적으로 결합될 수 있는 행위자 모델 및 메시지 대기열 모델과 유사한 "반응형" 프로그래밍(RFP/스트림)에 검색을 집중하기를 원할 수 있습니다.

메시징 시스템 전문가는 아니지만 앱에서 Akka와 결합하면 두 가지 장점을 모두 누릴 수 있습니다.다음은 Akka 및 메시징 시스템(이 경우 ZeroMQ)을 실험하는 데 도움이 될 수 있는 예입니다.

https://github.com/zcox/akka-zeromq-java

Akka-Camel은 ZeroMQ보다 좋은 예입니다.ZeroMQ는 tcp에서 tcp로의 직접 통신입니다(따라서 0-메시지 큐는 없습니다).

AkkaCamel을 사용하면 큐를 추상화하고 메시지 큐의 메시지를 푸시/풀링하는 코드 없이 배우로부터 직접 메시지를 생성/소비할 수 있습니다.

Akka-zeromq를 버리고 원격 조작으로 Akka를 직접 사용할 수 있습니다.코어 라이브러리에서 akka-zeromq가 삭제될 것 같습니다만, scala-zeromq라고 하는 aka용 zeromq 라이브러리를 구축했습니다(https://github.com/mDialog/scala-zeromq)).

Akka에는 다음과 같은 몇 가지 핵심 사용 사례가 있습니다.

1) 가변 상태

공유 상태를 배우에게 숨기면 더 쉽게 처리할 수 있습니다.액터가 동기식으로 메시지를 처리하기 때문에 액터의 상태를 유지하고 액터 API를 통해 높은 일관성으로 필드를 노출할 수 있습니다.

2) 배포

동시성은 아카어로 무료이기 때문에 당신은 그것이 정말로 유통 문제를 해결하는 것이라고 말합니다.머신과 코어에 분산.Akka는 유선으로 메시지를 보낼 수 있는 "장소 투명성"을 갖추고 있습니다.또한 단일 서비스 확장을 위한 클러스터링 및 패턴도 있습니다.따라서 배포에 매우 적합한 솔루션(마이크로 서비스 아키텍처 등)이 됩니다.

다음은 ActiveMQ에서 Akka를 Akka-Camel과 함께 사용하는 예를 보여 줍니다(Java8 사용).

import akka.actor.Props;
import akka.camel.Camel;
import akka.camel.CamelExtension;
import akka.testkit.TestActorRef;
import akka.testkit.TestProbe;
import org.junit.Ignore;
import org.junit.Test;
import akka.camel.javaapi.UntypedProducerActor;
import akka.camel.javaapi.UntypedConsumerActor;
import static com.rogers.totes.TotesTestFixtures.*;
import org.apache.activemq.camel.component.*;

public class MessagingTest {
    @Test @Ignore
    public void itShouldStoreAMessage() throws Exception{
        String amqUrl = "nio://localhost:61616";
        Camel camel = (Camel) CamelExtension.apply(system);
        camel.context().addComponent("activemq", ActiveMQComponent.activeMQComponent(amqUrl));

        TestProbe probe = TestProbe.apply(system);
        TestActorRef producer = TestActorRef.create(system, Props.create((Producer.class)));
        TestActorRef consumer = TestActorRef.create(system, Props.create((Consumer.class)));
        producer.tell("Produce", probe.ref());

        Thread.sleep(1000);
    }
}

class Producer extends UntypedProducerActor{

    @Override
    public String getEndpointUri() {
        return "activemq:foo.bar";
    }
}

class Consumer extends UntypedConsumerActor{

    @Override
    public String getEndpointUri() {
        return "activemq:foo.bar";
    }

    @Override
    public void onReceive(Object message) throws Exception {
        System.out.println("GOT A MESSAGE!" + message);

    }
}

언급URL : https://stackoverflow.com/questions/5693346/when-to-use-actors-instead-of-messaging-solutions-such-as-websphere-mq-or-tibco