Java 분산 캐시 시스템이 해결해야 할 4가지 주요 문제는 무엇입니까?

분산 캐시 시스템은 3단계 아키텍처에서 없어서는 안 될 부분으로, 전체 프로젝트의 동시성과 응답 속도를 크게 향상시키지만, 해결해야 할 새로운 문제도 발생합니다. 즉, 캐시 침투, 캐싱 혁신, 캐시 눈사태 및 캐시 일관성 문제.

캐시 침투

첫 번째 큰 문제는 캐시 침투입니다. 이 개념은 이해하기 쉽고 적중률과 관련이 있습니다. 적중률이 낮으면 데이터베이스 지속성 계층에 압력이 집중됩니다.

관련 데이터를 찾으면 캐시할 수 있습니다. 하지만 문제는 이 요청이 캐시나 지속성 계층에 도달하지 못했다는 것입니다. 이러한 상황을 캐시 침투라고 합니다.

예를 들어 위 그림과 같이 로그인 시스템에 외부 공격이 있는데 존재하지 않는 사용자를 이용해 계속 로그인을 시도하고 있는데, 이러한 사용자는 가상이기 때문에 효과적으로 캐시할 수 없습니다. 데이터베이스에서 한 번만 쿼리하면 결국 서비스 성능이 저하됩니다.

이 문제에 대한 해결 방법은 여러 가지가 있는데, 간단히 소개해 보겠습니다.

첫 번째 방법은 빈 개체를 캐시하는 것입니다. 영속성 레이어가 데이터를 찾을 수 없는 것 아닌가요? 그런 다음 이 요청의 결과를 null로 설정하고 캐시에 넣을 수 있습니다. 합리적인 만료 시간을 설정함으로써 백엔드 데이터베이스의 보안을 보장할 수 있습니다.

빈 객체를 캐싱하면 추가 캐시 공간을 차지하게 되고 데이터 불일치에 대한 시간 창이 있으므로 두 번째 방법은 Bloom 필터를 사용하여 대량의 일반 키 값을 처리하는 것입니다.

레코드의 유무는 Bool 값으로, 1비트만으로 저장할 수 있습니다. Bloom 필터는 이러한 yes 및 no 연산을 데이터 구조로 압축할 수 있습니다. 예를 들어 휴대폰 번호, 사용자 성별 등의 데이터는 Bloom 필터를 사용하기에 매우 적합합니다.

캐시 고장

캐시 고장은 사용자 요청이 데이터베이스에 떨어지는 상황을 의미하기도 합니다. 대부분의 경우 캐시 시간의 일괄 만료로 인해 발생합니다.

우리는 일반적으로 캐시에 있는 데이터에 만료 시간을 설정합니다. 특정 시간에 데이터베이스에서 많은 양의 데이터를 가져오고 동일한 만료 시간을 설정하면 동시에 만료되어 캐시 중단이 발생합니다.

핫 데이터의 경우 만료되지 않도록 설정하거나 액세스할 때 만료 시간을 업데이트할 수 있습니다. 동시에 만료를 방지하기 위해 일괄적으로 저장된 캐시 항목도 상대적으로 평균 만료 시간을 할당해야 합니다.

캐시 눈사태

눈사태라는 단어가 무섭게 보이지만 실제 상황은 더 심각합니다. 캐싱은 시스템을 가속화하는 데 사용되며 백엔드 데이터베이스는 고가용성 대안이 아닌 데이터 백업일 뿐입니다.

캐시 시스템에 장애가 발생하면 트래픽이 즉시 백엔드 데이터베이스로 전송됩니다. 머지않아 데이터베이스는 과도한 트래픽으로 인해 과부하 상태가 되어 중단될 것입니다. 이러한 연속적인 서비스 장애는 눈사태라고 할 수 있습니다.

캐시의 고가용성 구축은 매우 중요합니다. Redis는 마스터-슬레이브 및 클러스터 모드를 제공하며 클러스터 모드는 사용이 간편하며 각 샤드는 독립적으로 마스터-슬레이브 역할을 할 수 있어 매우 높은 가용성을 보장합니다.

또한 데이터베이스의 성능 병목 현상에 대한 일반적인 평가도 있습니다. 캐시 시스템이 충돌하는 경우 현재 제한 구성 요소를 사용하여 데이터베이스로 흐르는 요청을 차단할 수 있습니다.

캐시 일관성

캐시 구성 요소가 도입된 후 또 다른 어려운 문제는 캐시 일관성입니다.

먼저 문제가 어떻게 발생하는지 살펴보겠습니다. 캐시 항목에는 쓰기, 업데이트, 읽기, 삭제라는 네 가지 일반적으로 사용되는 작업이 있습니다.

• 쓰기: 캐시와 데이터베이스는 서로 다른 두 가지 구성 요소입니다. 이중 쓰기가 포함되는 한 쓰기 중 하나만 성공하여 데이터 불일치가 발생할 가능성이 있습니다.

• 업데이트: 업데이트 상황은 비슷합니다. 두 가지 구성 요소를 업데이트해야 합니다.

• 읽기: 읽기는 캐시에서 읽은 정보가 최신이고 데이터베이스의 정보와 일치하는지 확인해야 합니다.

• 삭제: 데이터베이스 기록을 삭제할 때 캐시에 있는 데이터는 어떻게 삭제하나요?

대부분의 경우 비즈니스 로직이 상대적으로 복잡하기 때문입니다. 예를 들어, 사용자의 잔액은 일련의 자산을 계산하여 계산되는 숫자입니다. 이러한 관련 자산이 변경될 때마다 캐시를 ​​새로 고쳐야 한다면 코드 구조가 매우 혼란스럽고 유지 관리가 불가능합니다.

트리거된 캐시 일관성 방법을 사용하는 것이 좋습니다. 지연 로딩 방법을 사용하면 캐시 동기화가 매우 간단해집니다.

• 캐시를 읽을 때 캐시에 관련 데이터가 없으면 관련 데이터가 실행됩니다. , 캐시 데이터를 구성하고 캐시 시스템에 저장합니다.

• 캐시 아이템과 관련된 리소스가 변경되면 해당 캐시 아이템이 먼저 삭제되고, 그 후 데이터베이스에 리소스가 업데이트되고, 최종적으로 해당 캐시 아이템이 삭제됩니다.

간단한 프로그래밍 모델 외에도 이 작업에는 분명한 이점이 있습니다. 저는 이 캐시를 사용할 때만 캐시 시스템에 로드합니다. 수정이 이루어질 때마다 리소스가 생성되고 업데이트되면 캐시 시스템에 콜드 데이터가 많이 남게 됩니다. 이는 실제로 필요에 따라 데이터 스토리지에서 캐시로 데이터를 로드하는 Cache-Aside 패턴을 구현합니다. 가장 큰 효과는 성능을 향상시키고 불필요한 쿼리를 줄이는 것입니다.

그러나 여기에는 여전히 문제가 있습니다. 다음에 소개할 시나리오도 인터뷰에서 자주 묻는 질문이다.

위에서 언급한 데이터베이스 업데이트 작업과 캐시 삭제 작업은 분명히 동일한 트랜잭션에 있지 않습니다. 이로 인해 업데이트 프로세스 중에 데이터베이스 콘텐츠와 캐시 콘텐츠가 일치하지 않을 수 있습니다.

면접에서 이 질문만 지적하면 면접관이 엄지손가락을 치켜세울 것입니다.

분산 잠금을 사용하면 이 문제를 해결할 수 있습니다. 잠금을 사용하면 데이터베이스 작업과 캐시 작업을 다른 캐시 읽기 작업과 격리할 수 있습니다. 일반적으로 읽기 작업은 잠글 필요가 없습니다. 잠금이 발생하면 다시 시도하고 시간이 초과될 때까지 기다립니다.

위 내용은 Java 분산 캐시 시스템이 해결해야 할 4가지 주요 문제는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!