저장소 패턴에 대한 질문이 있습니다. 데이터가 메모리에 보관되지만 데이터의 내구성을위한 데이터베이스가있는 분산 프로젝트에서 작업하고 있습니다. 시스템의 규모를 조정하기 위해 데이터는 여러 앱 인스턴스에 분할됩니다. 이러한 이유로 노드 중 하나에 문제가 발생할 때마다 데이터가 데이터베이스에서 다시로드되고 분산 대기열을 사용하여 다시 공유됩니다.저장소 인터페이스가 구현의 캐시를 지우는 clear() 메소드를 노출해야합니까?
우리는 데이터를 처리하기 위해 도메인과 대화 할 수 있도록 저장소 인터페이스를 만들었습니다. 이 인터페이스의 구현은 맵을 내부 캐시로 사용하고 Hibernate를 사용하여 데이터베이스와 통신한다.
resharding을 시작하기 위해 응용 프로그램의 인스턴스를 만들거나 삭제할 때마다 캐시를 지워야하기 때문에이 방법에 대한 repo 메서드가 공개되었습니다. 이것이 올바른 방법일까요? 이 인터페이스가 구현 내부와 관련된 메소드를 노출하도록하지 않습니까? 또 다른 솔루션은 캐시를 새로 고침을 트리거하는 서비스에 삽입하는 것이지만 이는 지속성 계층 구현에 대한 정보 누설을 의미합니다.
아이디어가 있으십니까?
감사합니다.
편집
응용 프로그램에 대한 자세한 약간. 샤딩을 적용한 이유는 데이터가 커질 경우 앱을 확장 할 수 있기 때문입니다. 이 채널은 최대 수천 개까지 될 수 있지만 초당 최대 2 개의 메시지를 보내는 여러 채널을 구독해야합니다. 수신 된 모든 메시지에 대해 모든 데이터를 검토하고 메시지의 정보와 일치하는 메시지를 찾은 다음 모든 메시지에 대한 알림을 보내야합니다. 이를 확장 할 수 있도록 데이터는 순간마다 2 개씩 나누어 지므로 각 인스턴스가 보유한 데이터를 처리합니다.
데이터가 사용자에 의해 작성되었으므로이를 위해 작성된 일부 REST 엔드 포인트가 있습니다. 이러한 의미에서 클라이언트는 생성 된 데이터를 생성, 업데이트, 삭제 및 가져올 수있는 간단한 응용 프로그램으로 작동합니다. 저장소는 특정 정보를 기반으로 쿼리하기 위해 일반적인 CRUD 작업 및 메소드를 제공하며 구현은 캐시 및 데이터베이스에 데이터를 추가하고 요청에 따라 데이터를 가져 오거나 처리합니다. 캐시 미스의 경우 데이터베이스에서 데이터를 가져 와서 캐시에 넣을 수 없으므로 앱에 더 복잡한 점이 있습니다. 데이터가 없으면 다른 것이 있어야합니다. 자체 캐시에 데이터가 들어있는 클러스터의 인스턴스 이를 처리하기 위해 요청을 리디렉션하는 데 사용하는 대기열과 주제가 있습니다.
이러한 이유로 우리는 캐시를 삭제해야합니다. 클러스터의 토폴로지가 변경 될 때마다 새로운 노드가 있거나 캐시 중 하나가 데이터베이스에서 데이터를 다시 가져와야하는 경우 캐시의 데이터를 다시 균형을 맞추어야한다는 의미입니다. 내려 갔다. 누락 된 데이터가 정확히 무엇인지 모르기 때문에 캐시를 지우고 데이터베이스에서 다시 채우고 하나의 노드를 데이터 로더로 사용하고 분산 된 대기열을 사용하여 데이터를 분할합니다. 이 작업은 꽤 빠르기 때문에이 시간 동안 클라이언트의 요청을 거부합니다. 앱에 클라이언트의 많은 동시 요청이 없으므로 문제는 계속 유지해야하는 구독 채널에 있습니다.
왜 'clear()'를해야하는지, 캐시에있는 데이터가 다시 요청되지 않았습니까? 그 시간 동안 응용 프로그램과 그 성능은 어떻게됩니까? 저장소 내부가 실제로 샤딩과 관련이 있는지 자세히 설명해 주시겠습니까? – cruftex
방금 추가 질문을 편집했습니다. 나는 그것이 당신의 질문에 대답하기를 바랍니다. – Kilian