Akka (3)

Actor

**

액터 모범 사례

1. 액터는 좋은 동역자와 같아야합니다. 불필요하게 다른 사람들을 괴롭 히지 않고 효율적으로 업무를 수행하고 자원을 낭비하지 않아야합니다. 프로그래밍으로 변환한다는 것은 이벤트를 처리하고 이벤트 중심 방식으로 응답 (또는 더 많은 요청)을 생성하는 것을 의미합니다. 액터는 피할 수없는 경우를 제외하고는 어떤 외부 엔티티 (잠금, 네트워크 소켓 등)에서 차단해서는 안됩니다 (즉, 스레드 점유 중에 수동적으로 대기). 후자의 경우 아래를보십시오.

액터간에 가변 객체를 전달하지 마십시오. 이를 보장하려면 불변 메시지를 선호하십시오. 액터의 캡슐화가 변경 가능 상태를 외부에 노출시킴으로써 깨지면 정상적인 Java 동시성 토지에 다시 돌아옵니다.

액터는 메시지 내에서 일상적으로 행동을 보내지 않는 수단 (Scala 클로저를 사용하여 유혹을받을 수 있음)을 수용하는 행동 및 주를위한 컨테이너로 만들어집니다. 위험 중 하나는 실수로 배우들 사이에서 가변적 인 상태를 공유하는 것이며, 배우 모델에 대한 이러한 위반은 아쉽게도 액터의 프로그래밍을 멋진 경험으로 만드는 모든 속성을 파괴합니다.

최상위 액터는 오류 커널의 가장 안쪽 부분이므로, 드물게 생성하고 진정한 계층 적 시스템을 선호합니다. 이는 장애 처리 (구성 및 성능의 세분성 모두 고려)와 관련하여 이점을 가지며 과도하게 사용되는 경합의 단일 지점 인 보호자 액터의 부담을 줄입니다.

당신이 신경 쓰지 말아야 할 것

액터 시스템은 자신이 포함하고있는 액터를 실행하기 위해 사용하도록 구성된 리소스를 관리합니다. 이러한 시스템에는 수백만 명의 행위자가있을 수 있습니다. 모든 Mantra는 인스턴스를 풍부하게보고 인스턴스 당 대략 300 바이트의 오버 헤드로 무게가 나가기 때문입니다. 당연히 메시지가 대형 시스템에서 처리되는 정확한 순서는 응용 프로그램 작성자가 제어 할 수 없지만 이는 또한 의도하지 않았습니다. 아카 (Akka)가 무거운 짐을 덜어내는 동안 한 발 뒤로 물러서서 휴식을 취하십시오.

액터 란 무엇입니까? (What is an Actor?)

액터 시스템 에 대한 이전 섹션에서는 액터가 계층 구조를 구성하는 방법을 설명했으며 애플리케이션을 빌드 할 때 가장 작은 단위였습니다. 이 섹션에서는 그러한 액터 하나를 별도로 살펴보고 구현하는 동안 만나는 개념을 설명합니다. 모든 세부 사항에 대한 더 깊은 참고 자료는 액터 를 참조하십시오 . 배우는 상태 , 행동 , 우편함 , 자식 액터 및 감독자 전략을 위한 컨테이너입니다 . 이 모든 것은 Actor Reference 뒤에 캡슐화되어 있습니다. 주목할 가치가있는 측면 중 하나는 행위자가 명확한 수명주기를 갖고 있으며 더 이상 참조되지 않을 때 자동으로 파괴되지 않는다는 점입니다. 하나를 생성 한 후에는 최종적으로 종료되도록해야하며, 또한 액터가 종료 될 때 리소스가 해제되는 방법을 제어 할 책임이 있습니다 .

액터 참조(Actor Reference)

아래에 자세히 설명 된 것처럼 액터 모델의 이점을 얻으려면 액터 오브젝트를 외부에서 차폐해야합니다. 따라서 액터는 제한없이 자유롭게 전달할 수있는 액터 reference를 사용하여 외부에 표시됩니다. 이러한 내부 및 외부 객체로의 분할은 원하는 모든 작업에 대한 투명성을 가능하게합니다. 다른 곳에서 참조를 업데이트 할 필요없이 액터를 다시 시작하고, 실제 액터 객체를 원격 호스트에 배치하고, 완전히 다른 응용 프로그램에서 액터에게 메시지를 보냅니다. 그러나 가장 중요한 측면은 액터가이 정보 자체를 비공식적으로 게시하지 않는 한 액터 내부를 들여다 보거나 외부에서 그 상태를 유지하는 것이 불가능하다는 것입니다.

상태(State)

액터 객체는 일반적으로 액터가있을 수있는 가능한 상태를 반영하는 몇 가지 변수를 포함합니다. 이는 명시 적 상태 시스템 (예 : FSM 모듈 사용)이거나 카운터, 리스너 세트, 보류중인 요청 등일 수 있습니다. 이러한 데이터 배우를 가치있는 것으로 만들고, 다른 배우들에 의한 부패로부터 보호되어야합니다. 좋은 소식은 Akka 액터는 개념적으로 각각 시스템의 나머지 부분과 완전히 차별화 된 자체 경량 스레드를 가지고 있다는 것입니다. 즉, 잠금을 사용하여 액세스를 동기화하는 대신 병행성에 대한 걱정없이 액터 코드를 작성할 수 있습니다.배후에서 Akka는 실제 스레드 세트에서 액터 세트를 실행합니다. 일반적으로 많은 액터가 하나의 스레드를 공유하며, 한 액터의 후속 호출이 다른 스레드에서 처리 될 수 있습니다. Akka는 이 구현 세부 사항이 액터의 상태를 처리하는 단일 스레드에 영향을 미치지 않도록합니다.내부 상태는 액터의 작업에 필수적이기 때문에 일관성없는 상태는 치명적입니다. 따라서 액터가 실패하고 감독자에 의해 재시작 될 때 상태는 액터를 처음 만들 때처럼 처음부터 생성됩니다. 이것은 시스템의자가 치유 능력을 가능하게하는 것입니다. 선택적으로, 액터의 상태는 수신 된 메시지를 유지하고 재시작 한 후에 재생함으로써 자동으로 재시작 전의 상태로 복구 될 수 있습니다 ( 지속성 참조 ).

행동(Behavior)

메시지가 처리 될 때마다 액터의 현재 동작과 일치합니다. 행동이란 해당 시점에 메시지에 대한 반응으로 취할 행동을 정의하는 기능을 말합니다. 예를 들어 클라이언트가 승인되면 요청을 전달하고 그렇지 않으면 거부합니다. 이 동작은 시간이 지남에 따라 변경 될 수 있습니다. 예를 들어 다른 클라이언트가 시간이 지남에 따라 권한 부여를 얻거나 액터가 “out-of-service”모드로 들어가서 나중에 다시 올 수 있기 때문입니다. 이러한 변경은 비헤이비어 로직에서 읽은 상태 변수로 인코딩하거나 런타임시 함수 자체를 스왑 아웃하여 수행 할 수 있습니다 ( become 및 unbecome operations 참조) . 그러나 액터 객체를 생성하는 동안 정의 된 초기 비헤이비어는 액터를 다시 시작하면 초기 액터로 동작을 재설정한다는 의미에서 특별합니다.**

메일함 (MailBox)

액터의 목적은 메시지의 처리이며,이 메시지는 다른 액터 (또는 액터 시스템 외부)의 액터에게 전송됩니다. 발신자와 수신자를 연결하는 부분은 액터의 메일 함입니다. **각 액터는 모든 발신자가 메시지를 큐에 넣을 정확하게 하나의 사서함을 가지고 있습니다. 대기열에 넣는 작업은 전송 작업의 시간 순서에 따라 발생합니다. 즉, 여러 액터에서 전송 된 메시지는 스레드에서 액터를 배포하는 명백한 임의성 때문에 런타임에 정의 된 순서가 없을 수 있습니다.** 반면에 동일한 액터에서 동일한 타겟에 여러 메시지를 보내는 것은 같은 순서로 큐를 대기열에 넣습니다.선택할 수있는 다양한 사서함 구현이 있으며 기본값은 FIFO입니다. 액터가 처리하는 메시지의 순서는 대기열에 있던 순서와 일치합니다. 일반적으로 좋은 기본값이지만 응용 프로그램은 다른 메시지보다 우선 순위가 필요한 메시지 일 수 있습니다. 이 경우 우선 순위 사서함은 항상 끝에 있지 않고 맨 앞에있는 메시지 우선 순위에 의해 지정된 위치에 대기열에 포함됩니다. 이러한 대기열을 사용하는 동안 처리되는 메시지의 순서는 자연히 대기열 알고리즘에 의해 정의되며 일반적으로 FIFO가 아닙니다.**Akka가 다른 액터 모델 구현과 다른 중요한 특징은 현재 동작이 항상 대기열에서 제외 된 다음 메시지를 처리해야하며 다음 일치하는 메시지를 위해 사서함을 검사하지 않는다는 것입니다. 이 동작이 무시되지 않는 한 메시지 처리 오류는 일반적으로 오류로 처리됩니다.

자식 액터(Child Actor)

각 액터는 잠재적으로 수퍼바이저입니다. 하위 작업을 위임하기위한 하위 항목을 만드는 경우 자동으로 하위 작업을 감독합니다. 자식 목록은 액터의 컨텍스트 내에서 유지되며 액터는 액터에 액세스 할 수 있습니다. 목록 수정은 children ( context.actorOf(…)) 또는 stopping ( context.stop(child))을 통해 수행되며 이러한 작업은 즉시 반영됩니다. 실제 생성 및 종료 작업은 비동기 적으로 장면 뒤에서 발생하므로 감독자를 “차단”하지 않습니다.

감독자 전략(Supervisor Strategy)

액터의 마지막 부분은 자식 액터의 잘못을 처리하는 전략입니다. 오류 처리는 Akka가 투명하게 수행하여 들어오는 각 오류에 대해 감독 및 모니터링 에 설명 된 전략 중 하나를 적용 합니다. 이 전략은 액터 시스템이 구조화되는 방법의 기본이기 때문에 일단 액터가 생성되면 변경할 수 없습니다. 각 액터에게 단 하나의 전략 만 있다는 점을 감안할 때, 액터의 다양한 자녀들에게 다른 전략을 적용한다면, 자식 액터들은 중간 감독자 아래에서 일치하는 전략으로 그룹화되어야하고, 다시 한번 액터 시스템의 구조화를 선호해야합니다. 작업을 하위 작업으로 나눕니다.

액터가 종료 될 때

액터가 종료되면, 즉 재시작에 의해 처리되지 않는 방식으로 실패하거나, 관리자가 중지하거나 관리자가 중지하면 자원을 비워 사서함의 나머지 모든 메시지를 시스템의 “dead letter mailbox”에 유출시킵니다. 그것들을 DeadLetters로서 EventStream에 전송합니다. 그런 다음 사서함은 액터 참조 내에서 시스템 사서함으로 바뀌고 모든 새 메시지를 DeadLetters로 EventStream에 리디렉션합니다. 이는 최선의 노력으로 이루어 지므로 “보장 된 전달”을 구축하기 위해 의존하지 마십시오. 메시지를 자동으로 덤핑하지 않는 이유는 dead letter가 전달되는 이벤트 버스에 TestEventListener를 등록하고 수신 된 모든 수신 문자에 대해 경고를 기록하기 때문입니다. 이는 해독에 매우 유용합니다.

실패를 더 빨리 테스트하십시오. 이 기능이 다른 용도로 사용될 수도 있습니다.

액터 레퍼런스 란 무엇입니까?

액터 참조는의 하위 유형이며 ActorRef, 액터 참조가 나타내는 액터로 메시지를 보낼 수 있도록하는 것을 가장 먼저 목적으로합니다. 각 액터는 self필드를 통해 정규 (로컬) 참조에 액세스 할 수 있습니다. 이 참조는 다른 액터로 전송 된 모든 메시지에 대해 기본적으로 보낸 사람 참조로 포함됩니다. 반대로 메시지 처리 중에 액터는 sender()메서드를 통해 현재 메시지의 보낸 사람을 나타내는 참조에 액세스 할 수 있습니다. 액터 시스템의 구성에 따라 지원되는 액터 참조에는 여러 가지 유형이 있습니다. 순수 로컬 액터 레퍼런스는 네트워크 기능을 지원하도록 구성되지 않은 액터 시스템에 의해 사용됩니다. 이러한 액터 참조는 원격 JVM에 대한 네트워크 연결을 통해 전송 된 경우에는 작동하지 않습니다. 리모팅이 가능할 때 로컬 액터 참조는 동일한 JVM 내의 액터를 나타내는 레퍼런스에 대한 네트워킹 기능을 지원하는 액터 시스템에 의해 사용됩니다. 다른 네트워크 노드로 전송 될 때 도달 할 수 있도록 이러한 참조에는 프로토콜 및 원격 주소 지정 정보가 포함됩니다. 라우터 (즉, Router특성에 혼합 된 액터)에 사용되는 로컬 액터 참조의 하위 유형이 있습니다 . 그것의 논리적 인 구조는 앞에서 언급 한 지역 참조와 동일하지만, 그들에게 메시지를 보내는 것은 직접적으로 자식들 중 한 명에게 디스패치합니다. 원격 액터 참조는 원격 통신을 사용하여 접근 할 수있는 액터를 나타냅니다. 즉, 메시지를 보내는 것은 메시지를 투명하게 직렬화하여 원격 JVM으로 보냅니다. 모든 실질적인 목적을 위해 로컬 액터 참조처럼 작동하는 몇 가지 특수한 유형의 액터 참조가 있습니다.PromiseActorRefPromise배우의 응답으로 완성 될 목적을위한 특별한 표현입니다 . akka.pattern.ask이 액터 참조를 만듭니다. DeadLetterActorRef Akka가 대상이 종료되었거나 존재하지 않는 모든 메시지를 라우팅하는 데드 레터 서비스의 기본 구현입니다. EmptyLocalActorRef존재하지 않는 로컬 액터 경로를 찾을 때 Akka가 반환하는 것입니다. a와 동일 DeadLetterActorRef하지만 Akka가 네트워크를 통해이를 전송하고 그 경로에 대한 다른 기존 액터 참조와 비교할 수 있도록 경로를 유지합니다. 배우가 죽기 전에 얻은 것일 수도 있습니다.

그리고 실제로 볼 수없는 일회성 내부 구현이 있습니다.배우를 대표하지는 않지만 루트 수호자의 의사 감독자로만 활동하는 액터 참조가 있습니다. 우리는이를 “시공간의 거품을 걷는 사람”이라고 부릅니다. 실제로 액터 생성 기능을 시작하기 전에 시작된 첫 번째 로깅 서비스는 로그 이벤트를 받아들이고이를 표준 출력으로 직접 인쇄하는 가짜 액터 참조입니다. 그렇습니다 Logging.StandardOutLogger.

액터 경로 란 무엇입니까?

액터는 엄격한 계층 적 방식으로 생성되기 때문에 액터 이름의 고유 시퀀스가 ​​있습니다.이 시퀀스는 자식과 부모가 액터 시스템의 루트를 향한 감독 링크를 반복적으로 따라 가면서 제공됩니다. 이 시퀀스는 파일 시스템에서 폴더를 둘러싸는 것으로 볼 수 있으므로 배우 계층이 파일 시스템 계층 구조와 근본적인 차이점을 가지고 있지만 “경로”라는 이름을 사용했습니다. 액터 경로는 액터 시스템을 식별하는 앵커와 루트 요소의 연결을 거쳐 루트 보호자에서 지정된 액터로 구성됩니다. path 요소는 통과 된 액터의 이름이고 슬래시로 구분됩니다.

액터 참조와 경로의 차이점은 무엇입니까?

액터 참조는 단일 액터를 지정하며 참조의 라이프 사이클은 액터의 라이프 사이클과 일치합니다. 행위자 경로는 행위자가 거주하거나 거주하지 않을 수있는 이름을 나타내며 경로 자체는 생명주기가 없으며 무효화되지 않습니다. 액터를 만들지 않고 액터 경로를 만들 수 있지만 해당 액터를 만들지 않고 액터 참조를 만들 수는 없습니다. 액터를 만들고 종료 한 다음 동일한 액터 경로로 새 액터를 만들 수 있습니다.** 새로 생성 된 액터는 액터의 새로운 액터입니다. 그것은 같은 액터가 아닙니다. 이전 되살아난 액터 참조는 새 화신에 유효하지 않습니다. 이전 액터 참조로 보낸 메시지는 동일한 경로가 있어도 새 가상화에 전달되지 않습니다.

액터 패스 앵커

각 액터 경로에는 해당 액터가 도달 할 수있는 프로토콜과 위치를 설명하는 주소 구성 요소와 루트에서 계층 구조에있는 액터 이름이 이어집니다. 예 :

“akka://my-sys/user/service-a/worker1” // purely local “akka.tcp://my-sys@host.example.com:5678/user/service-b” // remote

다음 akka.tcp은 2.4 릴리스의 기본 원격 전송입니다. 다른 전송 장치는 플러그 가능합니다. 호스트 및 포트 부분 (예 host.example.com:5678에서) 의 해석은 사용되는 전송 메커니즘에 따라 다르지만 URI 구조 규칙을 준수해야합니다.

논리 액터 경로

루트 보호자를 향한 부모 감독 링크를 따라 얻은 고유 경로를 논리적 행위자 경로라고합니다. 이 경로는 액터의 생성 조상과 정확하게 일치하므로 액터 시스템의 원격 구성 (및 경로의 주소 구성 요소)이 설정되는 즉시 완전히 결정적입니다.

실제 액터 경로

논리적 액터 경로는 하나의 액터 시스템 내의 기능 위치를 설명하지만 구성 기반의 원격 배치는 액터가 부모와 다른 네트워크 호스트, 즉 다른 액터 시스템에 생성 될 수 있음을 의미합니다. 이 경우 루트 보호자의 액터 경로를 따라가는 것은 네트워크를 가로 지르는 과정을 수반하므로 비용이 많이 드는 작업입니다. 따라서 각 액터에는 실제 액터 개체가있는 액터 시스템의 루트 보호자부터 시작하는 실제 경로가 있습니다. 다른 액터를 쿼리 할 때 이 경로를 보낸 사람 참조로 사용하면 라우팅에서 발생하는 지연을 최소화하여 액터에 직접 회신 할 수 있습니다. 한 가지 중요한 측면은 실제 액터 경로가 여러 액터 시스템이나 JVM에 걸쳐 있지 않다는 것입니다. 즉, 액터의 논리 경로 (감독 계층)와 실제 경로 (액터 전개)는 조상 중 하나가 원격으로 감독을받는 경우 발산 할 수 있습니다.

액터 경로 별칭 또는 심볼릭 링크?

실제 파일 시스템에서와 같이 액터에 대한 “path alias”또는 “심볼릭 링크”를 생각할 수 있습니다. 즉, 한 액터가 두 개 이상의 경로를 사용하여 연결할 수 있습니다. 그러나 액터 계층 구조는 파일 시스템 계층 구조와 다릅니다. 임의의 액터를 지칭하는 심볼릭 링크와 같은 액터 경로를 자유롭게 만들 수 없습니다. 위의 논리적 및 물리적 액터 경로 섹션에서 설명한 것처럼 액터 경로는 감독 계층을 나타내는 논리 경로이거나 액터 배포를 나타내는 물리적 경로 여야합니다.

Actor References는 어떻게 얻습니까?

액터 참조를 얻는 방법에는 일반적으로 두 가지 범주가 있습니다. 액터 만들기 또는 찾아보기로, 구체적인 액터 경로에서 액터 레퍼런스를 만들고 논리적 액터 계층을 쿼리하는 두 가지 기능이 있습니다.

액터 만들기

액터 시스템은 일반적으로 ActorSystem.actorOf메소드를 사용 하여 보호자 액터 아래에 ActorContext.actorOf로 액터를 생성 한 다음 생성 된 액터 내에서 액터 트리를 스폰하기 위해 시작됩니다. 이 메소드는 새로 생성 된 액터에 대한 참조를 반환합니다. 각 액터는 ActorContext 부모, 자신 및 자식에 대한 참조에 직접 액세스 할 수 있습니다 . 이러한 참조는 메시지 내에서 다른 액터로 전송 될 수 있으므로 직접 응답 할 수 있습니다.

구체적인 경로로 액터보기

또한 배우 참조는이 ActorSystem.actorSelection 방법 을 사용하여 조회 할 수 있습니다 . Actor Selection은 서로 다른 액터와 통신하기 위해 사용될 수 있고, Actor Selection에 대응하는 액터는 각 메시지를 전달할 때 검색된다. ActorRef특정 액터의 라이프 사이클에 바인딩 된 것을 획득하려면 내장 메시지와 같은 메시지를 액터로 보내고 Identify액터 sender()로부터의 응답 참조를 사용해야합니다 .

절대 경로 대 상대 경로

뿐만 아니라 ActorSystem.actorSelection이 또한 ActorContext.actorSelection같은 배우 내부 사용할 수있는, context.actorSelection. 이렇게하면 쌍둥이처럼 배우 선택을하게 ActorSystem되지만 액터 트리의 루트에서 시작하는 경로를 찾는 대신 현재 배우에서 시작합니다. 두 개의 점 ( ”..”) 으로 구성된 경로 요소 를 사용하여 상위 액터에 액세스 할 수 있습니다. 예를 들어 특정 형제에게 메시지를 보낼 수 있습니다.

context.actorSelection(“../brother”) ! msg

물론 절대 경로는 일반적인 방법 으로 상황 에 따라 조회 할 수도 있습니다.

context.actorSelection(“/user/serviceA”) ! msg

예상대로 작동합니다.

논리 액터 계층 구조 쿼리하기

액터 시스템은 계층 구조와 같은 파일 시스템을 형성하기 때문에 유닉스 셸에서 지원하는 것과 같은 방식으로 경로 일치가 가능합니다 : 경로 요소 이름의 일부를 와일드 카드 («»* 및 «?» )로 대체 할 수 있습니다. 0 개 이상의 실제 액터와 일치하는 선택을 공식화합니다. 결과는 단일 액터 참조가 아니기 때문에 다른 유형을 ActorSelection가지며 수행하는 전체 작업 집합을 지원 ActorRef하지 않습니다. 선택 사항은 ActorSystem.actorSelection및을 사용하여 공식화 될 수 있으며 ActorContext.actorSelection메시지 전송을 지원합니다.

context.actorSelection(“../*”) ! msg

현재 액터를 포함한 모든 형제 에게 msg 를 보냅니다 . actorSelection을 사용하여 얻은 참조에 대해서는 메시지 보내기를 수행하기 위해 감독 계층의 순회가 수행됩니다. 수신자에게 메시지가 전달되는 동안에도 선택 항목과 일치하는 정확한 액터 세트가 변경 될 수 있기 때문에 생기 변경에 대한 선택을 볼 수 없습니다. 이를 수행하려면 요청을 보내고 모든 대답을 수집하고 보낸 사람 참조를 추출한 다음 발견 된 모든 구체 행위자를 관찰하여 불확실성을 해결하십시오. 선택을 해결하는이 계획은 향후 릴리스에서 개선 될 수 있습니다.

actorOf vs actorSelection

actorOf 새 액터 만 생성하고이 메서드가 호출되는 컨텍스트 (즉, 액터 또는 액터 시스템 일 수 있음)의 직접적인 하위 항목으로 만듭니다. actorSelection 메시지가 전달 될 때 기존 액터를 조회합니다. 즉, 액터를 만들지 않거나 선택이 생성 될 때 액터의 존재를 확인합니다.

액터 참조 및 경로 평등

ActorRefMatch of Equality는 ActorRef타겟 액터에 해당하는 의도입니다 . 두 액터 참조는 동일한 경로를 갖고 동일한 액터를 가리킬 때 동등 비교됩니다. 종료 된 액터(죽어서 제거된 액터)를 가리키는 참조는 같은 경로를 가진 다른 (다시 생성 된) 액터를 가리키는 참조와 동일하지 않습니다. 실패로 인해 액터를 다시 시작한다는 것은 여전히 ​​동일한 액터라는 것을 의미합니다. 다시 말해서 사용자의 재시작은 보이지 않습니다 ActorRef. 콜렉션에서 액터 참조를 추적해야하고 정확한 되살아난 액터에 관심 ActorPath이 없으면 액터 경로를 비교할 때 대상 액터의 식별자가 고려되지 않기 때문에 as 키를 사용할 수 있습니다 .

액터 경로 재사용

액터가 종료되면 레퍼런스는 dead letter 메일 박스를 가리키고 DeathWatch는 최종 전환을 게시 할 것이고 일반적으로 액터 수명주기가 이것을 허용하지 않기 때문에 다시 돌아올 것으로 예상되지 않습니다. 나중에는 동일한 경로로 액터를 만들 수 있습니다. 모든 액터 세트를 사용하지 않고 반대를 시행하는 것이 불가능하기 때문에 이것은 좋은 습관이 아닙니다 actorSelection. 액터로 보낸 메시지입니다. 갑작스럽게 다시 일하기 시작했으나 이 전환과 다른 사건 사이에 질서가 보장되지 않아 새로운 거주자(새로 생성된 액터)가 이전 거주자(종료된 액터 또는 제거된 액터)를 향한 메시지를받을 수 있습니다.

매우 특정한 상황에서해야 할 일은 옳은 일이지만, 액터의 감독자에게 정확하게 다루도록 해야한다. 그 감독자가 이름의 적절한 등록 취소를 안정적으로 감지 할 수있는 유일한 배우이기 때문입니다.

테스트 주체가 특정 경로에서 인스턴스화되는 데 의존하는 테스트 중에 필요할 수도 있습니다. 이 경우 감독관을 조롱하여 종료 된 메시지를 테스트 절차의 적절한 지점으로 전달하여 후자가 이름의 적절한 등록 취소를 기다릴 수 있도록하는 것이 가장 좋습니다.

액터 경로의 최상위 범위

경로 계층의 루트에는 다른 모든 액터가있는 루트 보호자가 있습니다. 그것의 이름은이다 ”/”. 다음 레벨은 다음으로 구성됩니다. “/user”모든 사용자가 만든 최상위 액터의 수호자입니다. 사용 된 액터 ActorSystem.actorOf는이 아래에 있습니다. “/system” 액터 시스템의 시작에서 구성에 의해 자동으로 배포되는 로깅 리스너 또는 액터와 같이 시스템이 만든 모든 최상위 액터의 수호자입니다. “/deadLetters” 는 죽은 편지 액터로, 중지되었거나 존재하지 않는 액터로 보낸 모든 메시지가 다시 라우팅됩니다 (최선의 노력을 기울여 메시지가 로컬 JVM 내에서도 손실 될 수 있음). “/temp”모든 단명 한 시스템이 만든 액터의 보호자입니다 (예 : 구현에 사용되는 액터) ActorRef.ask. “/remote” 모든 액터가 상주하는 인위적인 경로이며, 상사는 원격 액터 참조입니다. 이와 같은 액터의 네임 스페이스를 구조화해야하는 필요성은 중심적이고 매우 단순한 디자인 목표에서 비롯됩니다. 계층 구조의 모든 것이 액터이고 모든 액터가 같은 방식으로 작동합니다. 따라서 생성 한 액터를 조회 할 수있을뿐만 아니라 시스템 보호자를 검색하여 메시지를 보낼 수도 있습니다 (이 경우 정식으로 삭제됩니다). 이 강력한 원리는 기억해야 할 단점이 없다는 것을 의미합니다. 전체 시스템을 더 균일하고 일관성있게 만듭니다. 배우 시스템의 최상위 구조에 대해 더 자세히 알고 싶다면 최상위 수퍼바이저를 살펴보십시오 .