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

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

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

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

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

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

답변