머리말
나는 이전에 Youzan TMC 프레임워크의 다단계 캐시 구현을 보았고 기사를 썼습니다: Youzan TMC 프레임워크의 원칙을 참조하여 간단히 다단계 캐시를 구현하십시오 . 아직 일부 핵심을 배우지 못했습니다. 오늘 , 나는 Ali의 오픈 소스 JetCache의 도움으로 그것에 대해 더 많이 배울 것입니다.
다단계 캐시란?
gpt에 대해 알려주세요~ 이 개발 구성은 좋은 조수입니다. 많은 블로그를 직접 버리는 어느 정도의 엔진과 달리 콘텐츠를 더 신중하게 필터링합니다. 많은 블로그가 여전히 모호하고 핵심은 광고입니다, 하하 ~
그 분석은 매우 상세하다. 메모리 유형의 속도는 매우 빠르지만 리소스를 공유할 수 없다. 분산 캐시의 속도는 이전보다 느리지만 분산 환경의 데이터 일관성을 보장할 수 있다. 지속성은 일반적으로 mysql의 관계형이며 그 특성은 용량이 크지만 동시성이 200을 초과하면 성능이 떨어지는 단점이 있다.
다단계 캐시 애플리케이션 시나리오
우리는 일반적으로 응용 프로그램에서 분산 캐시 redis를 사용합니다.그 단점은 무엇입니까?또한 취약합니다.일반적인 인터뷰 질문:캐시 고장,캐시 침투,이러한 시나리오는 또한 시스템을 충돌시키고 핫키도 특정에 큰 압력을 가합니다. Redis 읽기 성능에 영향을 미치므로 다중 수준 캐싱이 작동합니다.
다단계 캐시 아이디어
논리 읽기 및 쓰기
데이터 스토리지 로직
다중 레벨 캐시
값은 루프에 삽입됩니다. 최상위 레이어는 로컬 캐시이고 그 다음이 분산 캐시입니다. 그 사이에는 CompletableFuture가 있으며 이는 thenCombine에 의해 규제됩니다. 예를 들어 로컬 캐시가 분산 캐시와 일치하지 않는 경우 예외 메시지 반환됩니다.
데이터 읽기 논리
주문은 여전히 로컬에서 분산으로 읽혀집니다.
checkResultAndFillUpperCache(key, i, holder);
复制代码이 코드는 내부의 TTL을 강제로 새로 고치는 것으로, 내부 캐시가 ttl 시간 내에 일관성이 있는지 확인하는 것입니다.
일관성 보장
여기서 일관성에는 여러 측면이 있습니다. 다단계 캐시 일관성, 다른 노드의 일관성
다중 레벨 캐싱은 어떻게 일관성을 보장합니까? 답변을 위해 gpt 학생들에게 오세요
읽기-쓰기 업데이트 전략은 무엇입니까? 우회 업데이트 전략은 redis와 동일합니다. 즉, get을 얻었을 때 다중 수준 캐시가 없으면 db에서 읽은 후 업데이트된 다중 수준 캐시가 첫 번째 문제인 다중 수준 캐시 일관성을 해결합니다.
두 번째 문제: 다른 노드의 일관성은 실제로 redis 게시 및 구독에 의해 해결됩니다. 즉, 캐시 키 넣기 및 제거 작업이 redis 파이프라인을 통해 통지된 다음 다른 노드가 동기화됩니다. 게이트웨이 지연이 발생하면 어떻게 해야 할까요? 다시 시도해보세요~
캐시 고장
다시 질문에 답하기 위해 gpt 학생들에게 오십시오.
인공 지능은 정말 똑똑하고 많은 포인트를 나열한 다음 원하는 것을 인위적으로 걸러냅니다.
첫 번째 항목에서 캐시 고장을 방지하기 위해 분산 잠금을 사용할 것이라고 언급했습니다.그게 무슨 뜻인가요?예를 들어 노드가 2개이고 동시성이 1w이면 다중 레벨 캐시에 데이터가 없습니다.이 때, 노드 1은 분산 잠금 업데이트 데이터를 가져오고 다른 요청은 먼저 중단되며 업데이트가 완료된 후 노드 2가 자체 데이터를 업데이트하므로 동시성이 높더라도 실제로 2개의 요청만 데이터베이스에 도달합니다.
다른 요청을 기다리는 방법은 무엇입니까? Fence Count다운로드 를 참조하십시오 .
핫스팟 키를 모니터링하는 방법
gpt 학생:
public class HotKeyMonitor<K> implements CacheMonitor<K, Integer> {
private static final Logger logger = LoggerFactory.getLogger(HotKeyMonitor.class);
private final Map<K, AtomicInteger> counterMap = new ConcurrentHashMap<>();
private final Set<K> hotKeySet = new HashSet<>();
private final int threshold;
public HotKeyMonitor(int threshold) {
this.threshold = threshold;
}
@Override
public void onGet(String cacheName, K key, Integer value) {
if (value == null) {
return;
}
AtomicInteger counter = counterMap.computeIfAbsent(key, k -> new AtomicInteger());
if (counter.incrementAndGet() >= threshold) {
synchronized (hotKeySet) {
if (!hotKeySet.contains(key)) {
hotKeySet.add(key);
![]()logger.info("Hot key detected, cache: {}, key: {}, count: {}", cacheName, key, counter.get());
}
}
}
}
@Override
public void onPut(String cacheName, K key, Integer value) {
counterMap.remove(key);
synchronized (hotKeySet) {
hotKeySet.remove(key);
}
}
public Set<K> getHotKeySet() {
synchronized (hotKeySet) {
return new HashSet<>(hotKeySet);
}
}
}
复制代码이 값은 어떻게 업데이트됩니까?
이 모니터링이 클러스터에서 동기화됩니까?
어떤 방식으로 모니터링합니까?
onGet 요청이 누적되고 onPut은 이벤트를 통해 비동기식으로 핫키를 삭제합니다.
핫스팟 키를 모니터링한 후 실제로 이를 적중하려면 로컬 캐시에 배치해야 합니다. 이는 가장 효율적이고 Redis 네트워크 요청, 특히 큰 키 문제를 방지합니다 .
요약하다
여기서 우리는 다단계 캐시의 개념부터 시작하여 왜 다단계 캐시를 사용하는지, 그리고 읽기 및 쓰기 논리, 일관성 보장, 캐시 고장, 핫키 모니터링에서 다단계 캐시 I에 대한 포괄적인 이해를 가지고 있습니다. chatgpt님의 답변 덕분에 이해하고 해당 소스코드도 읽어보았으니 독자들에게 도움이 되었으면 좋겠습니다~
이 글은 인공지능 크리에이터 지원 프로그램에 참여하고 있습니다.