Redis 단일 데이터 다중 소스 초고동시성 솔루션

Redis는 현재 가장 인기 있는 KV 캐시 데이터베이스로, 사용이 간편하고 안전하며 안정적이며 인터넷 업계에서 매우 광범위한 응용 프로그램을 보유하고 있습니다.

이 글에서는 단일 데이터와 다중 소스의 초고동시 액세스 환경에서 Redis의 솔루션과 솔루션을 주로 공유합니다.

머리말

Redis는 주로 두 가지 문제를 해결합니다.

수천만 명의 일일 사용자와 수백만 명의 온라인 사용자가 동시에 있는 비즈니스 시나리오에 직면할 때 프런트 엔드 액세스가 백에 직접 로드되는 경우 -데이터베이스를 종료하면 기본 데이터베이스가 압도되어 비즈니스가 종료될 수 있습니다. 또는 쿼리 조건의 수가 늘어나고 조합 조건이 복잡해지면 쿼리 결과에 대한 응답 시간을 보장할 수 없어 사용자 경험이 저하되고 사용자 손실이 발생하는 경우가 있습니다. 높은 동시성 및 낮은 지연 시간의 비즈니스 시나리오를 해결하기 위해 Redis가 탄생했습니다.

두 가지 시나리오를 살펴보겠습니다

온라인 주택 구하기의 비즈니스 시나리오입니다. 쿼리 조건이 너무 많아서 백엔드가 복잡한 쿼리 SQL이어야 합니다. 이 시나리오에 Redis가 필요합니까?

답은 '아니요'입니다. 온라인 주택 검색 비즈니스의 낮은 동시성으로 인해 고객은 비즈니스 응답 시간을 그다지 요구하지 않습니다. 대부분의 요청은 동적 SQL을 통해 일시적으로 직접 쿼리할 수 있습니다. 물론 사용자 경험을 향상시키기 위해 일부 핫 쿼리 결과를 Redis에 사전 캐시하여 사용자 경험을 향상시킬 수 있습니다.

이 시나리오를 다시 살펴보겠습니다

비디오 애플리케이션의 필름 확인 시스템은 주택 검색 시스템과 거의 동일한 비즈니스 시나리오이지만 동시성이 몇 배 더 높습니다. 이 시나리오는 매우 적합합니다. 캐시 개선을 위해 Redis를 사용합니다. 동시 액세스, 응답 시간 단축, 수십만 또는 수백만 개의 동시 액세스 요구 사항을 충족합니다. Redis 사용 여부를 결정하는 기본 요소는 동시성 및 대기 시간 요구 사항임을 알 수 있습니다.

Redis가 극단적인 인터넷 시나리오에서 동시 액세스 요구 사항을 어떻게 해결하는지 살펴보겠습니다.

초고동시 액세스 캐싱 솔루션

일반적인 미디어 캐시 아키텍처 다이어그램입니다. 퍼블리싱 시스템은 수시로 미디어 라이브러리를 업데이트하고, 분산 캐시 서비스를 통해 각각의 최신 기사를 Redis 캐시에 동기화합니다. , front-end 애플리케이션은 라우팅 계층을 통해 해당 데이터 소스 액세스를 찾습니다. 각 캐시 서비스의 데이터가 동기화되지 않았습니다. 핫스팟 이벤트가 발생하면 라우팅 계층이 접근할 수 없는 영역에서 핫스팟 데이터가 있는 캐시 서버로 액세스를 라우팅할 수 있으며, 이로 인해 순간적인 트래픽 급증이 발생할 수 있으며, 극단적인 경우 서버 다운타임 및 비즈니스 피해를 초래할 수 있습니다. 그렇다면 이 불규칙한 트래픽 폭증 시나리오를 어떻게 해결할까요?

다음은 몇 가지 아이디어입니다.

핫 데이터 복제를 달성하기 위해 접두어로 핫스팟 키를 분리합니다.

라우팅 레이어에 로컬 캐시를 추가하여 다단계 캐싱을 통해 캐싱 기능을 향상합니다.

캐시 레이어는 데이터 복사본을 제공합니다. 동시성 액세스 기능 향상

첫 번째 솔루션은 열 데이터를 효과적으로 소멸시킬 수 있지만 핫 이벤트가 무작위적이고 불규칙적으로 발생하여 운영 및 유지 관리 부담이 높고 비용도 많이 듭니다. 이는 골치 아픈 문제를 해결하는 솔루션일 뿐입니다. .

두 번째 솔루션은 로컬 캐시를 추가하여 캐싱 기능을 향상시킬 수 있지만 로컬 캐시를 얼마나 크게 설정해야 하는지, 새로 고침 빈도를 얼마나 높게 설정해야 하는지, 비즈니스에서 더티 읽기를 허용할 수 있는지 여부는 모두 피할 수 없는 문제입니다.

세 번째 솔루션은 읽기 전용 복제본을 추가하여 데이터 복제를 달성할 수 있지만, 이는 또한 메인 데이터베이스에 높은 비용과 높은 부하를 초래합니다.

위의 아키텍처 다이어그램은 기본 라이브러리를 통해 여러 읽기 전용 슬레이브 라이브러리에서 분기를 가져오고 다양한 요청 소스에 대해 독립적인 캐시 서비스를 분할하는 최적화된 솔루션입니다. 예를 들어 모바일 애플리케이션은 APP 데이터 리소스 그룹으로 고정적으로 라우팅되고 WEB 액세스는 WEB 데이터 리소스 그룹 등으로 라우팅되며 각 리소스 그룹은 N개의 읽기 전용 복사본을 제공하여 동일 출처에서 동시 액세스 기능을 향상시킬 수 있습니다. 입장. 이 아키텍처는 다양한 액세스 소스의 리소스 격리 기능을 향상시키고 다중 소스 액세스에서 서비스의 안정성과 가용성을 향상시킬 수 있습니다.

이 솔루션의 문제점도 명백합니다.

기본 데이터베이스의 읽기 및 쓰기 성능이 좋지 않습니다.

읽기 전용 복제본이 많고 비용이 높습니다.

읽기 전용 링크가 너무 길어 관리 및 유지 관리가 어렵습니다. 어렵고, 운영 및 유지 관리 비용이 높습니다

저희 고객 가장 과장된 예는 유사한 비즈니스 시나리오를 충족하기 위해 1-마스터-40-읽기 전용 아키텍처를 사용하는 것입니다.

Alibaba Cloud Redis는 이 초고속 동시 액세스 문제를 어떻게 해결합니까?

Alibaba Cloud는 네트워크 IO의 동시 처리 기능을 개선하여 단일 Redis 노드의 읽기 및 쓰기 성능을 크게 향상시키는 성능이 향상된 Redis 버전을 출시했습니다. .커뮤니티 버전에 비해 성능이 3배 향상되었습니다. 단일 Worker 처리 모드를 유지하므로 Redis 프로토콜과 100% 호환됩니다. 위의 100만 QPS 단일 데이터 액세스 기능은 쉽게 달성할 수 있습니다. 본 기사에 소개된 미디어 시나리오는 성능이 향상된 버전 1 마스터 5 읽기 전용 인스턴스를 활성화하여 단일 데이터에 대해 200만 이상의 QPS를 달성할 수 있으며 갑작스러운 핫 이벤트, 초고속 동시 액세스 및 기타 산업으로 인한 트래픽 급증을 효과적으로 완화할 수 있습니다. 고통 포인트. 1개의 마스터와 40개의 읽기가 있는 자체 구축 커뮤니티 버전과 비교하여 동일한 성능 표준을 갖춘 Alibaba Cloud Redis 성능 강화 버전은 1개의 마스터와 5개의 읽기 전용 아키텍처를 갖추고 있어 더 안정적이고 관리가 더 편리합니다. 사용하기 편리합니다.

위 내용은 Redis 단일 데이터 다중 소스 초고동시성 솔루션의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!