Redis 캐시 문제를 해결하는 방법

LevelDB가 왔습니다!

Google에서 오픈소스로 제공하는 NOSQL 스토리지 엔진 라이브러리로, 현대 분산 스토리지 분야에서 없어서는 안될 도구입니다. 이를 기반으로 Facebook은 LevelDB의 고급 기술 아키텍처를 따르는 동시에 LevelDB의 일부 단점을 해결하는 또 다른 NOSQL 스토리지 엔진 라이브러리인 RocksDB를 개발했습니다. RocksDB를 LevelDB보다 더 강력한 수소폭탄에 비유할 수 있습니다. 많은 최신 오픈 소스 데이터베이스는 RocksDB를 기본 스토리지 엔진으로 사용하며 TiDB는 유명한 예 중 하나입니다.

그런데 왜 RocksDB 대신 LevelDB에 대해 이야기해야 할까요? 그 이유는 LevelDB 기술 아키텍처가 더 간단하고 명확하며 이해하기 쉽기 때문입니다. LevelDB를 먼저 제대로 이해한 후 RocksDB를 살펴보면 RocksDB는 LevelDB를 기반으로 한 일련의 최적화에 불과하다는 점을 이해하기가 매우 쉬울 것입니다. RocksDB 문제를 해결하면 TiDB의 원자력 우주선이 머지않아 이미 우리를 맞이할 것입니다.

Redis 캐시에 무슨 문제가 있나요?

Redis를 캐시로 사용할 때 일반적으로 전체 콜드 및 핫 데이터를 기록하는 영구 데이터베이스가 여전히 있습니다. Redis와 지속성 계층 데이터베이스 간의 데이터 일관성은 애플리케이션 자체에 의해 제어됩니다. 캐시에 데이터가 없으면 애플리케이션은 지속성 계층에서 데이터를 로드하여 캐시에 넣어야 합니다. 데이터 업데이트가 발생하면 캐시를 무효화해야 합니다.

function getUser(String userId) User {<br/>  User user = redis.get(userId);<br/>  if user == null {<br/>    user = db.get(userId);<br/>    if user != null {<br/>      redis.set(userId, user);<br/>    }<br/>  }<br/>  return user;<br/>}<br/><br/>function updateUser(String userId, User user) {<br/>  db.update(userId, user);<br/>  redis.expire(userId);<br/>}<br/>

이 분야의 개발 경험이 있는 친구들은 이러한 코드를 작성하는 것이 꽤 지루하다는 것을 알고 있습니다. 캐싱과 관련된 모든 비즈니스 코드에는 이 부분의 로직을 추가해야 합니다.

엄밀히 말하면 캐시 일관성 문제도 신중하게 고려해야 합니다. 예를 들어 updateUser 메서드에서 데이터베이스는 업데이트를 올바르게 수행하지만 네트워크 지터 및 기타 이유로 인해 캐시된 Redis가 무효화되지 않고 데이터가 무효화되지 않습니다. 캐시의 데이터가 만료됩니다. 캐시를 설정하고 영구 저장소를 업데이트하는 순서가 바뀌더라도 다른 문제가 계속 발생할 수 있다는 점을 독자는 고려할 수 있습니다.

여러 프로세스의 높은 동시성 상황은 캐시 불일치로 이어질 수도 있습니다. 예를 들어 프로세스가 특정 userId에 대해 getUser() 메서드를 호출하는 경우 해당 userId는 캐시에 없으므로 데이터베이스에서 로드해야 합니다. 결과가 방금 로드되었고 캐시를 설정하려고 합니다. 이때 메모리 fullgc 코드가 잠시 중지되고 이때 다른 프로세스가 updateUser 메소드를 호출하여 데이터베이스를 업데이트하고 캐시를 무효화합니다(in 실제로 캐시에는 캐시가 없습니다. 그러면 이전 프로세스가 마침내 fullgc를 완료하고 캐시 설정을 시작합니다. 이때 만료된 데이터가 캐시됩니다.

레벨DB는 어떻게 해결되나요?

LevelDB는 Redis 캐시와 지속성 레이어를 하나로 결합하여 캐시와 지속성 레이어를 한 번에 처리할 수 있도록 도와줍니다. LevelDB를 사용하면 코드를 다음

function getUser(String userId) User {<br/>  return leveldb.get(userId);<br/>}<br/><br/>function updateUser(String userId, User user) {<br/>  leveldb.set(userId, user);<br/>}<br/>

으로 단순화할 수 있으며 더 이상 캐시 일관성 문제에 대해 걱정할 필요가 없습니다. LevelDB의 데이터 업데이트는 성공하거나 실패하며 중간 슈뢰딩거 상태가 없습니다. LevelDB는 메모리 캐시와 지속성 레이어 디스크 파일을 내부적으로 통합하므로 사용자는 데이터 일관성의 세부 사항에 주의할 필요가 없습니다.

레벨DB가 정확히 무엇인가요?

앞서 Redis의 개념과는 다른 비관계형 스토리지 엔진이라고 말씀드렸습니다. Redis는 완전한 데이터베이스인 반면 LevelDB는 단순한 엔진입니다. 데이터베이스를 고급 스포츠카에 비유한다면 스토리지 엔진은 엔진, 즉 핵심이자 심장이다. 이 엔진을 사용하면 일련의 액세서리 및 장식과 함께 패키지하여 데이터베이스가 될 수 있습니다. 그러나 액세서리와 장식을 과소평가하지 마십시오. LevelDB를 간단하고 사용하기 쉬운 데이터베이스로 패키징하려면 너무 많은 정교한 액세서리를 추가해야 합니다. LevelDB와 RocksDB는 수년 동안 사용되어 왔지만 이를 기반으로 완전한 프로덕션 수준 데이터베이스를 구축할 수 있는 사람은 거의 없습니다.

LevelDB는 메모리 내 키-값 데이터베이스로 생각할 수 있습니다. 이는 코드에서 데이터를 읽고 쓸 수 있는 기본 Get/Set API를 제공합니다. 또한 이를 무제한 크기의 고급 HashMap으로 생각할 수도 있습니다. 디스크가 들어갈 수 있는 한 무제한의 키/값 데이터를 넣을 수 있습니다.

인메모리 데이터베이스로만 간주될 수 있기 때문에 여기에 저장된 데이터는 프로세스나 머신 간에 공유될 수 없습니다. 분산 분야에서 LevelDB는 어떻게 자신의 재능을 보여줄 수 있습니까?

이를 달성하려면 네트워크 API를 LevelDB 인메모리 데이터베이스 위에 래핑해야 합니다. 여러 프로세스가 서로 다른 시스템에 있고 리소스에 액세스하려는 경우 모두 네트워크 API 인터페이스를 통해 균일하게 액세스해야 합니다. 이는 간단한 데이터베이스를 형성합니다. Redis 프로토콜을 적용하여 네트워크 계층을 캡슐화하고 Redis 클라이언트를 사용하여 데이터베이스를 읽고 쓸 수 있습니다.

데이터베이스의 고가용성을 고려하고 싶다면 위의 독립형 데이터베이스에 마스터-슬레이브 복제 기능을 추가하여 마스터-슬레이브 구조의 분산형 NOSQL 데이터베이스로 변환할 수 있습니다. 마스터-슬레이브 데이터베이스 앞에 전달 프록시(LVS, F5 등과 같은 로드 밸런서) 계층을 추가하면 마스터-슬레이브 데이터베이스의 실시간 전환이 가능합니다.

필요한 데이터 용량이 너무 커서 단일 머신의 하드 디스크가 이를 수용할 수 없는 경우 전체 데이터베이스 데이터를 여러 머신에 분산시키기 위해 데이터 샤딩 메커니즘이 필요합니다. 각 머신은 데이터베이스의 일부를 읽고 쓰는 작업만 담당합니다. 자료. . 데이터 샤딩에는 다양한 옵션이 있습니다. Codis와 같은 전달 프록시를 통해 샤딩할 수도 있고, Redis-Cluster와 같은 클라이언트 전달 메커니즘을 사용하여 샤딩할 수도 있습니다. TiDB의 Raft 분산 일관성 알고리즘을 사용하여 그룹화하고 관리할 수도 있습니다. 가장 간단하고 이해하기 쉬운 것은 Codis의 정방향 프록시 샤딩입니다.

데이터 양이 계속 증가하고 새 노드가 필요할 때 기존 노드의 데이터를 새 노드로 부분적으로 마이그레이션해야 합니다. 데이터의 균형과 마이그레이션을 관리하는 것은 새로운 고급 액세서리인 데이터 밸런서입니다.

위 내용은 Redis 캐시 문제를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!