[java] WebSphere MQ 또는 Tibco Rendezvous와 같은 메시징 솔루션 대신 액터를 언제 사용해야합니까?

먼저 “오래된”메시지 시스템 (MQ)은 구현이 오래되었지만 트랜잭션 영구 대기열 이라는 엔지니어링 아이디어의 새로운 개념입니다 . Scala Actors와 Akka는 새로운 구현 일 수 있지만 이전의 Actors 동시성 모델을 기반으로 구축되었습니다.

그러나 두 모델은 모두 이벤트 메시지 기반이기 때문에 실제로 매우 유사 합니다. RabbitMQ 대 Akka에 대한 내 대답을 참조하십시오 .

JVM 용으로 만 코딩하려는 경우 Akka가 좋은 선택 일 것입니다. 그렇지 않으면 RabbitMQ를 사용합니다.

또한 Scala 개발자라면 Akka는 생각할 필요가 없습니다. 그러나 Akka의 Java 바인딩은 Java와 같지 않으며 Scala의 유형 시스템으로 인해 캐스팅이 필요합니다.

또한 Java에서 사람들은 일반적으로 메시징을 위해 권장하는 불변 객체를 만들지 않습니다. 결과적으로 Java에서 확장되지 않는 Akka를 사용하여 실수로 작업을 수행하는 것은 매우 쉽습니다 (이상한 클로저 콜백 상태에 의존하는 메시지에 대해 변경 가능한 객체 사용). MQ에서는 메시지가 항상 속도를 희생하면서 직렬화되기 때문에 문제가되지 않습니다. Akka에서는 일반적으로 그렇지 않습니다.

Akka는 또한 대부분의 MQ보다 많은 수의 소비자에게 더 잘 확장됩니다. 대부분의 MQ (JMS, AMQP) 클라이언트의 경우 모든 큐 연결에는 스레드가 필요하기 때문입니다. 따라서 많은 큐 == 영구적으로 실행중인 스레드가 많습니다. 이것은 주로 클라이언트 문제입니다. ActiveMQ Apollo에는 AMQP에 대한 문제를 해결하는 비 차단 디스패처가 있다고 생각합니다. RabbitMQ 클라이언트에는 여러 소비자를 결합 할 수있는 채널이 있지만 많은 소비자가 잠재적으로 교착 상태 또는 연결을 중단시킬 수있는 문제가 있으므로 일반적으로이 문제를 피하기 위해 더 많은 스레드가 추가됩니다.

그 존재는 말했다 Akka의 원격이 아니라 새로운 아마도 여전히 신뢰할 수있는 메시지를 보장하고 기존의 메시지 큐가 제공하는 (그러나 매일 변경되는) 것을 QoS를 제공하지 않습니다. 또한 일반적으로 피어 투 피어이지만 일반적으로 대부분의 MQ 시스템이 수행하는 (즉, 단일 실패 지점) 서버 투 피어를 지원한다고 생각하지만 피어 투 피어 (RabbitMQ는 서버- 응시하다).

마지막으로 RabbitMQ와 Akka는 실제로 좋은 쌍을 이룹니다. Akka를 RabbitMQ에 대한 래퍼로 사용할 수 있습니다. 특히 RabbitMQ는 메시지 소비를 처리하고 메시지를 로컬 (단일 JVM에서) 라우팅하는 데 도움이되지 않기 때문입니다.

Akka를 선택하는 경우

• 많은 소비자를 확보하십시오 (수백만을 생각하십시오).
• 짧은 대기 시간 필요
• Actor 동시성 모델 열기

예제 시스템 : 대화 형 실시간 채팅 시스템

MQ를 선택하는 경우

• 다양한 시스템 (예 : 비 JVM)과 통합해야 함
• 메시지 안정성이 대기 시간보다 더 중요합니다.
• 더 많은 도구와 관리 UI를 원합니다.
• 오래 실행되는 작업에 더 나은 이전 포인트 때문에
• 액터와 다른 동시성 모델을 사용하고 싶습니다.

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

관련 의견을 기반으로 편집

나는 OP가 Akka 와 Message Queues가 모두 처리 할 수있는 분산 처리와 관련이 있다고 가정했습니다 . 그것은 그가 분산 Akka 에 대해 이야기하고 있다고 가정했습니다 . 로컬 동시성에 Akka를 사용하는 것은 대부분의 메시지 대기열과 비교하여 주황색을 비교하는 것 입니다. Reactor 라이브러리와 단순 반응 모두가 수행하는 동시성 모델 (예 : 주제, 대기열, 교환)로 메시지 대기열 모델을 로컬로 적용 할 수 있기 때문에 가장 많이 말합니다 .

지연 시간이 짧은 애플리케이션에서는 올바른 동시성 모델 / 라이브러리를 선택하는 것이 매우 중요합니다. 메시지 큐와 같은 분산 처리 솔루션은 일반적으로 라우팅이 거의 항상 유선을 통해 수행되기 때문에 이상적이지 않습니다. 이는 애플리케이션 내에서보다 분명히 느리므로 Akka가 우수한 선택이 될 것입니다. 그러나 일부 독점 MQ 기술은 로컬 라우팅을 허용합니다. 또한 앞서 언급했듯이 대부분의 MQ 클라이언트는 스레딩에 대해 꽤 어리 석고 비 차단 IO에 의존하지 않고 연결 / 대기열 / 채널당 스레드를 가지고 있습니다. 실력 있는.

보시다시피 분산 프로그래밍과 동시 프로그래밍의 주제는 다소 크고 매일 변하기 때문에 원래 의도는 혼란스럽지 않고 OP가 관심을 기울인 분산 메시지 처리의 특정 영역에 집중했습니다. 동시성 측면에서 검색을 “리 액티브”프로그래밍 (RFP / 스트림)에 집중하고 싶을 수 있습니다. “리 액티브”프로그래밍 (RFP / 스트림)은 “최신”이지만 액터 모델 및 메시지 큐 모델과 유사합니다. 이러한 모델은 모두 일반적으로 결합 될 수 있습니다. 이벤트 기반입니다.

답변

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);

    }
}