많은 메시지를받는 영구 액터가 있습니다. 주먹 메시지는 CREATE (사례 클래스)이고 다음 메시지는 UPDATE (사례 클래스)입니다. 따라서 CREATE를 받으면 저장소가이 액터에 대해 비어 있기 때문에 복구를 실행하기 위해 지속성 모드로 넘어 가지 않아야합니다. 그것은 나의 관점에서 낭비하는 성과입니다.처음 메시지 이후에 복구 켜기
특정 입력 메시지 (CREATE의 첫 번째 메시지)에 대해 복구를 호출하지 않을 가능성이 있습니까?
영속 액터는 이전에 존재했는지 여부를 알 수있는 다른 방법이 없기 때문에 항상 데이터베이스에 도달해야합니다. 중지되었거나 생성되었을 수있는 이전 응용 프로그램 인스턴스에서 생성되었을 수 있습니다 클러스터의 다른 노드에서.
일반적으로 퍼포먼스의 좋은 패턴은 배우가 가능한 한 빠른 응답을 허용하기 때문에 처음으로 히트 한 후 메모리에 유지하는 것입니다. 이 작업을 수행하는 가장 일반적인 방법은 클러스터 샤딩을 사용하는 것입니다. 여기서는 문서에서 더 자세히 읽을 수 있습니다 : https://doc.akka.io/docs/akka/current/cluster-sharding.html?language=scala#cluster-sharding
퍼시스턴스 문제로 비어있는 영구 액터의 히트를 본 사람은 누구도 들어 본 적이 없습니다. 그런 일반적인 문제를 해결할 수 있는지 확신 할 수 없으므로 그러한 문제가 있고 어떻게 든 배우가 생성되지 않았다는 것을 알 수 있습니다. Akka Persistence로 그 일을 할 수는 없지만 그 자체를위한 특별한 솔루션을 만들어야합니다.
의견을 보내 주셔서 감사합니다. 나는 샤딩을 사용하고 그것을 기억하고있다. 그리고 특정 액터 퍼스펙티브에서 비어 있습니다 (예 : 지속성 ID가 123 인 액터는 첫 번째 메시지의 저장 공간에 아무것도 없습니다). –
내 프로젝트가 BigData이고 모든 밀리 초를 저장하려고합니다. 이것이 내 생각으로는 더 합리적이다. 저장 용량이 비어 있다는 것을 알고있는 1TB의 영구 저장소와 약 3K 명의 새 액터가 있다고 가정합니다 (저장소의 첫 번째 쿼리에서 결과가 반환되지 않습니다. 처음 만든 CREATE 메시지의 경우). 처음 저장소를 묻는 데 시간을 낭비하게됩니다. 주먹 배우의 메시지입니다. 어쨌든 많은 것을 감사드립니다. –
복구의 성능에 미치는 영향은 무엇입니까? 얼마나 오래 걸리나요? 왜 낭비입니까? 여러 의견을 말했지만 사실은 제공하지 않았습니다. –
질문을 이해하지 못합니다. 당신은'akka.persistence.Persisten '을 확장 한 배우가 있습니까? tActor'는 몇 가지 CREATE 및 UPDATE 메시지를 수신합니까? – gtosto
** 복구 성능에 미치는 영향은 무엇입니까? ** 매우 빠른 작업입니다 (복구 중 하나임) ** 얼마나 자주 발생합니까? ** 초당 1K - 3K 회 발생합니다. ** 왜 낭비입니까? ** 쿼리 저장소가 필요하지 않습니다. CREATE 메시지에 저장소가 비어 있음을 알고 있습니다. 쿼리가 불필요하므로 낭비입니다. –