Scala의 다중 액터 구현은 어떻게 다릅니 까?
Scala 2.9.0의 출시와 함께, Scala 언어와 Akka 프레임 워크를 결합한 Typesafe Stack도 발표되었습니다. 이제 Scala는 표준 라이브러리에 액터가 있지만 Akka는 자체 구현을 사용합니다. 그리고 다른 구현을 찾으면 Lift와 Scalaz에도 구현이 있음을 알 수 있습니다!
그렇다면 이러한 구현의 차이점은 무엇입니까?
이 대답은 제 것이 아닙니다. 그것은 생산 된 데이비드 폴락 (리프트 명예의), (Scalaz 명성의) 제이슨 Zaugg, 필립 할러 (스칼라 배우 명예의)의 도움으로 빅토르 클랑 (Akka의 명성)에 의해.
여기서 내가하는 일은 서식을 지정하는 것뿐입니다 (Stack Overflow가 테이블을 지원하는 경우 더 쉬울 것입니다).
나중에 시간이 더있을 때 채울 곳이 몇 군데 있습니다.
디자인 철학
Scalaz 액터
최소한의 복잡성. 최대한의 일반성, 모듈성 및 확장 성.
액터 리프트
최소한의 복잡성, 명시적인 수명주기, 다른 Scala 및 Java 프로그램과 일치하는 오류 처리 동작, 경량 / 작은 메모리 풋 프린트, 메일 박스, Scala 액터 및 Erlang 액터와 정적으로 유사한 고성능, JVM에 의한 가비지 콜렉션.
스칼라 액터
Scala에서 전체 Erlang 액터 모델, 경량 / 작은 메모리 공간을 제공합니다.
Akka 배우
간단하고 투명하게 배포 할 수 있으며 고성능, 가볍고 적응력이 뛰어납니다.
버전 관리
Scalaz 액터 리프트 액터 스칼라 액터 Akka 액터 현재 안정 버전 5 2.1 2.9.0 0.10 최소 Scala 버전 2.8 2.7.7 2.8 최소 Java 버전 1.5 1.5 1.6
배우 모델 지원
Scalaz 액터 리프트 액터 스칼라 액터 Akka 액터 새 액터 생성 예 예 예 예 배우 내부 예 예 예 예에 메시지 보내기 알려진 배우 행동 변경 액터는 예 예 : 중첩 예 : 다음 메시지 불변의 반응 / 수신이되고 / 불가 감독 제공되지 않음 아니요 배우 : 예, 예 (link / trapExit) 반응기 : 아니오
상태 격리 수준
사용자가 액터에 퍼블릭 메소드를 정의하면 외부에서 호출 할 수 있습니까?
- Scalaz 액터 : n / a. 배우는 봉인 된 특성입니다.
- 리프트 액터 : 예
- 스칼라 액터 : 예
- Akka 액터 : 아니요, 액터 인스턴스는 ActorRef 뒤에 보호됩니다.
배우 유형
- Scalaz 액터 :
Actor[A] extends A => () - 리프트 액터 :
LiftActor,SpecializeLiftActor[T] - 스칼라 액터 :
Reactor[T],Actor extends Reactor[Any] - Akka 배우 :
Actor[Any]
배우 라이프 사이클 관리
Scalaz 액터 리프트 액터 스칼라 액터 Akka 액터
수동 시작 아니오 아니오 예 예
수동 정지 아니오 아니오 아니오 예
실패시 다시 시작 해당 없음 예 예 액터 인스턴스별로 구성 가능
의미 체계 다시 시작 해당 사항 없음 액터 다시 실행 액터를 다시 할당하여 액터를 안정된 상태로 복원하고
행동은 이전 인스턴스를 버리고
구성 다시 시작 n / an / a X 회, Y 시간 내에 X 회
수명주기 후크 제공됨 수명주기는 preStart, postStop, preRestart, postRestart를 작동하지 않습니다.
메시지 전송 모드
Scalaz 액터 리프트 액터 스칼라 액터 Akka 액터
Fire-forget a! 메시지 배우! msg actor! msg actorRef! 메시지
메세지)
보내기-받기-응답 (1 참조) actor!? msg actor!? msg actorRef !! 메시지
배우 !! 메시지
송수신 미래 (2 참조) 배우 !! msg actorRef !!! 메시지
약속의 결과 (메시지) 보내기. future.onComplete (f => ~! f.result)
미래에 (배우)
배우 코마로 배우 작곡 f 아니오 아니오 아니오
기능 (3 참조)
(1) 함수 f는 다음과 같은 행위자가됩니다.
val a: Msg => Promise[Rep] = f.promise
val reply: Rep = a(msg).get
(2) Any function f becomes such an actor:
val a = f.promise
val replyFuture = a(message)
(3) Contravariant functor: actor comap f. Also Kleisli composition in Promise.
Message reply modes
TBD
Scalaz Actors Lift Actors Scala Actors Akka Actors reply-to-sender-in-message reply-to-message
Message processing
Supports nested receives?
- Scalaz Actors: --
- Lift Actors: Yes (with a little hand coding).
- Scala Actors: Yes, both thread-based receive and event-based react.
- Akka Actors: No, nesting receives can lead to memory leaks and degraded performance over time.
Message Execution Mechanism
TBD
Scalaz Actors Lift Actors Scala Actors Akka Actors Name for Execution Mechanism Execution Mechanism is configurable Execution Mechanism can be specified on a per-actor basis Lifecycle of Execution Mechanism must be explicitly managed Thread-per-actor execution mechanism Event-driven execution mechanism Mailbox type Supports transient mailboxes Supports persistent mailboxes
Distribution/Remote Actors
Scalaz Actors Lift Actors Scala Actors Akka Actors
Transparent remote n/a No Yes Yes
actors
Transport protocol n/a n/a Java Akka Remote Protocol
serialization (Protobuf on top of TCP)
on top of TCP
Dynamic clustering n/a n/a n/a In commercial offering
Howtos
TBD
Scalaz Actors Lift Actors Scala Actors Akka Actors Define an actor Create an actor instance Start an actor instance Stop an actor instance
scala.actors was the first serious attempt to implement Erlang-style concurrency in Scala that has inspired other library designers for making a better (in some cases) and more performant implementations. The biggest problem (at least for me), is that unlike Erlang processes, complemented with OTP (that allows for building fault-tolerant systems), scala.actors only offer a good foundation, a set of stable primitives that must be used for building a more high-level frameworks - at the end of the day, you’ll have to write your own supervisors, catalogs of actors, finite state machines, etc. on top of actors.
And here Akka comes to the rescue, offering a full-featured stack for actor-based development: more idiomatic actors, set of high-level abstractions for coordination (load balancers, actor pools, etc.) and building fault-tolerant systems (supervisors, ported from OTP, etc.), easily configurable schedulers (dispatchers), and so on. Sorry, if I sound rude, but I think, there will be no merge in 2.9.0+ - I’d rather expect Akka actors to gradually replace stdlib implementation.
Scalaz. Normally I have this library in the list of dependencies of all my projects, and when, for some reason, I can’t use Akka, non-blocking Scalaz Promises (with all the goodness, like
sequence) combined with the standard actors are saving the day. I never used Scalaz actors as a replacement for scala.actors or Akka, however.
Actors: Scala 2.10 vs Akka 2.3 vs Lift 2.6 vs Scalaz 7.1
Test code & results for average latency and throughput on JVM 1.8.0_x.
'programing tip' 카테고리의 다른 글
| Pandas 데이터 프레임에서 사용하는 메모리를 어떻게 해제합니까? (0) | 2020.10.17 |
|---|---|
| 메모리 매핑 파일의 장점은 무엇입니까? (0) | 2020.10.17 |
| 다음 아티팩트를 해결할 수 없습니다. javax.jms : jms : jar : 1.1 (0) | 2020.10.16 |
| scikit-learn을 사용하여 여러 범주로 분류 (0) | 2020.10.16 |
| Android 방송 수신기 대 서비스 (0) | 2020.10.16 |