팀의 같은 반 친구가 프로젝트에서 Redis를 캐시로 사용하고 Redis에 핫스팟 데이터를 저장했습니다. 성능 향상을 위해 Redis를 작성할 때 파이프라인 방식을 사용합니다. 정상적으로 사용하면 Redis의 성능과 리소스 사용량이 프로젝트 요구 사항을 충족할 수 있지만 방문 횟수가 증가하면 Redis의 QPS는 여전히 요구 사항을 충족할 수 있습니다. 그러나 CPU 사용량은 90% 이상이며 일반적으로 30% 이상입니다. 우리 모두 알고 있듯이 Redis는 단일 프로세스이며 CPU 코어가 가득 차면 100%가 됩니다. CPU가 100%에 도달하면 필연적으로 성능 병목 현상이 발생합니다. 어떻게 해결하나요?
권장: "Redis 비디오 튜토리얼"
옵션 1:
가장 먼저 떠오르는 것은 Redis 서버 수를 늘리고 클라이언트에 저장된 키에 대해 해시 작업을 수행하는 것입니다. Redis 서버에서는 읽을 때 동일한 해시 작업을 수행하여 해당 Redis 서버를 찾아 문제를 해결할 수 있지만 단점은 다음과 같습니다.
먼저 클라이언트가 코드를 변경해야 합니다. ;
두 번째, 클라이언트가 필요합니다. 모든 Redis 서버의 주소를 기억하세요.
이 솔루션을 사용할 수 있지만 코드를 변경하지 않고 확장할 수 있나요?
옵션 2:
클러스터를 구축합니다. Redis 서버에서 사용하는 버전이 3.0보다 낮고 클러스터를 지원하지 않기 때문에 유명한 Redis 프록시 twemproxy를 사용하는 것이 유일한 방법입니다.
twemproxy의 성능도 매우 좋습니다. 프록시임에도 불구하고 Redis 작성자도 권장하는 수준입니다.
twemproxy는 사용하기 쉽습니다. 초보자도 한 시간 안에 사용법을 익힐 수 있으며, 핵심은 거의 모든 Redis 명령과 파이프라인 작업을 변경할 필요가 없다는 것입니다. 클라이언트 구성 파일의 구성을 변경합니다. Redis의 IP 및 PORT가 원래 Redis의 IP 및 포트에서 twemproxy 서비스의 IP 및 PORT로 변경됩니다.
클라이언트는 해시 문제를 고려할 필요가 없으며 twemproxy가 이를 수행하며 클라이언트는 Redis를 운영하는 것과 같습니다.
"keys *"와 같은 일부 명령이 지원되지 않기 때문에 위에서 "거의"라는 단어가 사용되었습니다.
우리는 twemproxy와 다음 4개의 Redis 머신을 신속하게 배포한 결과 스트레스 테스트를 통해 다음 4개의 Redis 머신의 CPU 사용량이 삭제되었지만 새로운 문제가 발생했습니다. twemproxy도 단일 프로세스입니다! 성능 병목 현상이 twemproxy에 다시 발생합니다!
옵션 3:
Redis에 대한 액세스는 생산자와 소비자와 마찬가지로 쓰기와 읽기로 구분됩니다. 주의 깊게 분석한 결과 쓰기가 적고 읽기가 상대적으로 더 많은 것으로 나타났습니다. 읽기와 쓰기의 분리는 구성 정보를 변경하여 쉽게 달성할 수 있는 상황입니다. 이는 기본 Redis 압력을 분산시킵니다.
여기서는 Redis에 대한 액세스 압력이 개선되었지만 장기적인 해결책은 아닙니다. 예를 들어 이벤트가 개최되고 데이터 양이 증가하면 여전히 성능 위험이 있습니다.
최종 채택 방법은 아래 그림과 같은 종합 솔루션 2와 3입니다. 
이 방법은 기존 서비스에 대한 변경을 최소화하고 Redis 압력 문제를 효과적으로 완화할 수 있습니다.
twemproxy 사용 생산자 측과 소비자 측 해시 알고리즘은 일관성이 있어야 합니다. 그렇지 않으면 키를 찾을 수 없습니다.
플랜 1도 추가되면 더 복잡해져서 당분간 사용하지 않을 예정입니다.
위 내용은 Redis를 확장하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!