Akka가 동시성에 적합한 이유는 무엇입니까?

나는 Akka와 배우 프레임 워크를 처음 사용합니다-분명한 것이 빠져 있다고 확신합니다. 사전에 사과하십시오.

Akka를 선택하는 주요 요점 중 하나가 동시성을 관리하는 방법이라는 것을 계속 읽습니다.

Akka가 왜 그렇게 특별한 지 분명하지 않습니다. 나는 매우 가볍고 빠른 많은 배우들이 있다는 것을 알고 있습니다. 그러나 두 명의 사용자가 동시에 양식을 저장할 때 어떻게 도움이됩니까?

여전히 일종의 동시성 잠금 (비관적 / 낙관적 인 등)이 필요하지 않습니까?

행위자 및 에이전트와 같은 메시지 처리 모델의 장점 중 하나는 기존의 동시성 문제 (주로 공유 상태 동기화)가 더 이상 문제가되지 않는다는 것입니다. 액터는 비공개 상태를 유지하고 잠금없이 자유롭게 업데이트 할 수 있습니다. 액터 프레임 워크는 한 번에 하나의 메시지 만 처리되도록합니다. 직렬화 된 처리를 사용하면 잠금없는 방식으로 코드를 작성할 수 있습니다.

액터가 각 양식의 일부 데이터 목록을 유지한다고 가정하면 양식을 저장하는 사용자의 예에서 프레임 워크는 한 번에 하나의 양식 만 처리되도록 보장하므로 잠금없이 목록을 업데이트 할 수 있습니다. 일반적으로 목록 액세스를 잠 그거나 동시 목록을 사용해야합니다.

동시성 전략은 약간 다른 문제이며 여전히 가장 일반적인 전략은 없습니다. 예제를 약간 변경하기 위해 두 사용자가 동시에 SAME 양식 인스턴스를 업데이트하려고한다고 가정합니다. 동시성 전략이 없으면 변경 사항이 다른 변경 사항을 덮어 씁니다 (아마 마지막 승리). 괜찮습니다. 그러나 변경 사항을 덮어 쓴 사용자에게는 예기치 않은 동작이 발생합니다. 그들이 방금 변경 한 양식을 보면 다른 사용자의 예상치 못한 값을 갖게됩니다. 최악의 경우 (양식 업데이트에 대해서만 이야기하는 것이 아니라 배송 주문과 같은 경우) 다양한 종류 (시간, 수익 등)가 손실 될 수 있습니다.

동시성 전략을 사용하면 이러한 사례를 식별하고 비즈니스 규칙을 기반으로 사례를 해결할 수 있습니다. 예를 들어 낙관적 동시성은 사용자가 업데이트중인 양식의 버전을 보내도록합니다. 액터가 변경을 처리하면, 두 번째 사용자는 첫 번째 사용자의 업데이트로 인해 양식이 실제로 버전 6 일 때 버전 5를 업데이트한다고 생각합니다. 이제 적어도 두 번째 사용자에게 양식을 편집 한 후 양식이 이미 변경되었음을 알릴 수 있습니다. 또는 비즈니스가 적용하려는 규칙이 무엇이든.

양식을 업데이트하는 경우 동시성에 대해 크게 신경 쓰지 않을 것입니다 (종종에 따라 다릅니다). 그러나 다른 경우에는 위반 사항을 확인하고 처리하는 것이 매우 중요 할 수 있습니다. 사용자가 다른 섹션을 변경 한 경우 (양식 비유를 계속하기 위해)와 같은 동시성 위반을 무시할 수도 있습니다. 또는 변경이 비즈니스에 큰 영향을 미치는 경우 (큰 주문) 나중에 변경을 수락하고 사소한 충돌을 해결하려고합니다 (예 : 연간 연락처 정보 업데이트가 완료되지 않은 경우).

나는 Akka가 devops에게 중요한 고려 사항 인 실패, 감독자 등을 처리하는 방법과 같은 여러 가지 다른 차원을 가지고 있다고 생각합니다.

고전 잠금 기반 동시성 및 깔끔한 트랜잭션 메모리와 같은 다른 동시성 모델과 비교하여 일반적으로 액터 모델 (Akka뿐만 아니라)에 대해 쓸 것입니다.

장점

1. 이해하고 사용하기 쉬운 개념

   • 잠금 기반 동시성은 어렵습니다. 특히 잠금, 세마포어, 스레드, 동기화, 상호 배제, 메모리 장벽 등과 같이 정확하고 효율적으로 이해하고 사용하는 많은 개념이 있기 때문에 올바르게 이해하기가 매우 어렵습니다.

   • 반면에 액터는 더 추상적 인 개념입니다. 메시지를주고받는 행위자가 있습니다. 메모리 장벽과 같은 저수준 개념을 파악하고 사용할 필요가 없습니다.

2. 불변성을 강화합니다

   • 변경 가능성은 프로그래밍, 특히 멀티 스레드 응용 프로그램에서 많은 오류와 버그의 원인입니다. 액터 모델은 불변성을 적용하여이 문제를 해결합니다.

3. 오류가 적은 경향

   • 위의 두 가지 이유 때문에

4. 실력 있는

   • 우수한 쓰기 잠금 기반만큼 효율적이지 않지만 일반적으로 소프트웨어 트랜잭션 메모리보다 효율적입니다.

5. 쉽게 확장 가능

   • 이론적으로 최소한 작업을 수행하기 위해 더 많은 액터를 추가하여 응용 프로그램을 확장해야합니다. 잠금 기반으로는 확장하기가 매우 어렵습니다.

단점

1. 모든 언어가 쉽게 불변성을 강요하는 것은 아닙니다.

   • 액터를 처음 대중화 한 언어 인 Erlang은 그 핵심에는 불변성을 가지고 있지만 Java와 Scala (실제로는 JVM)는 불변성을 강요하지 않습니다.

2. 여전히 꽤 복잡

   • 액터는 모든 시나리오에서 간단하고 모델링하기 쉬운 비동기 프로그래밍 모델을 기반으로합니다. 오류 및 실패 시나리오를 처리하기가 특히 어렵습니다.

3. 교착 상태 또는 기아를 방지하지 않습니다

   • 두 명의 액터가 서로 메시지를 기다리는 상태에있을 수 있습니다. 따라서 디버깅하기가 훨씬 쉽지만 잠금과 마찬가지로 교착 상태가 있습니다. 그러나 트랜잭션 메모리를 사용하면 교착 상태가 발생하지 않습니다.

4. 그렇게 효율적이지 않다

   • 불변성이 강제되고 많은 액터가 동일한 스레드 액터를 사용하여 전환해야하기 때문에 잠금 기반 동시성만큼 효율적이지 않습니다.

결론

잠금 기반 동시성이 가장 효율적이지만 프로그래밍 및 오류가 발생하기 어렵습니다. 소프트웨어 트랜잭션 메모리는 가장 명확하고 프로그래밍이 쉽고 오류가 적은 경향이 있지만 가장 효율적이지 않습니다. 액터는 프로그래밍, 효율성 및 오류 발생 가능성 등 모든 측면에서이 두 모델 사이에 있습니다.