Redis 차단 문제 해결

Redis는 단일 스레드 아키텍처이며 모든 작업이 메인 스레드에서 완료됩니다. 따라서 Redis가 차단되면 악몽이 될 것입니다. 다음으로 Redis의 차단 문제를 살펴보겠습니다. 문제를 해결하고 해결하는 방법.

Redis 데이터 구조나 API의 부당한 사용

대형 개체에 대해 복잡하고 높은 수준의 명령이 수행됩니다.

1 수천만 개의 요소가 포함된 해시에 대해 hgetall 작업을 수행합니다. 또는 del 작업을 수행하면 Redis가 차단됩니다. 2. 이러한 대규모 개체의 경우 redis-cli -h {host} -p {port} bigkeys를 사용하여 볼 수 있습니다. 그러나 이 명령은 특정 유형에서 가장 큰 키만 쿼리할 수 있습니다. 여러 개를 쿼리하려는 경우. redis-cli 소스 코드를 수정할 수 있습니다(Redis의 소스 코드는 C입니다). 소스 코드를 수정하고 싶지 않은 경우 스캔을 사용하여 완료할 수도 있습니다.

스캔 명령에 주의하세요. 이 명령은 단일 Redis의 데이터만 스캔할 수 있습니다. 클러스터인 경우 각 머신에서 한 번씩 실행해야 합니다. 그러나 오픈 소스 클라이언트(예: Java의 Lettuce 클라이언트)를 사용하는 경우 전체 클러스터를 스캔하는 스캔 명령을 구현하는 데 이미 도움이 될 것입니다.

3. 그런 다음 큰 개체를 분할합니다. 구체적인 분할은 비즈니스에 따라 다릅니다.

Redis의 CPU 사용량은 100%에 가깝습니다

1. 슬레이브가 호스트 데이터를 동기화합니다. 슬레이브 머신은 rdb 파일을 수신한 후 디스크

2에서 데이터를 로드합니다. 마스터-슬레이브는 데이터를 유지합니다.

3. CPU 사용량이 100%에 도달하면 실제 비즈니스 방문 횟수가 정말 많을 수도 있습니다. 단일 Redis는 초당 60,000개 이상의 요청을 처리할 수 있습니다. 이때는 수평 확장만 할 수 있습니다

4. 초당 Redis 작업 수가 수백 또는 수천에 불과하고 CPU 사용량이 여전히 매우 높으면 알고리즘 복잡도가 높은 명령을 사용할 수 있습니다. 예를 들어 hgetall. 또 다른 가능성은 메모리가 과도하게 최적화되어 있다는 것입니다. 이러한 상황은 아직 발생하지 않았지만 고려되고 있습니다.

Cpu ​​경쟁

1. Redis는 CPU 집약적인 애플리케이션이므로 다른 CPU 집약적인 서비스와 함께 배포하는 데 적합하지 않습니다.

2. 프로덕션 환경에서 당사 서버 중 하나의 구성은 32코어 논리 CPU와 256GB 메모리입니다. 각 머신에 하나의 Redis만 배포하는 것은 낭비입니다. 따라서 하나의 머신에 여러 Redis를 배포할 수 있습니다. Redis 프로세스는 일반적으로 CPU에 바인딩됩니다. 그러나 RDB 파일이나 AOF 지속성을 생성하면 하위 프로세스가 생성됩니다. 이런 방식으로 하위 프로세스와 상위 프로세스가 CPU를 두고 경쟁하게 됩니다. 따라서 지속성 또는 마스터 노드를 켤 때. CPU를 바인딩하는 것은 권장하지 않습니다

메모리 교환

Redis는 인메모리 데이터베이스이며 모든 데이터는 메모리에 저장됩니다. 따라서 메모리 교환을 활성화하지 않는 것이 좋습니다

네트워크 문제

마스터-슬레이브 동기화 네트워크 지연이 크면 슬레이브 시스템의 연결이 끊어졌다가 다시 연결되는 경우가 많습니다. 오랫동안 연결이 끊어진 경우. 결과적으로 슬레이브 머신이 마스터 머신에 다시 연결되면 완전히 동기화됩니다. 이때 마스터 머신과 슬레이브 머신 모두 영향을 받게 됩니다.

더 많은 Redis 지식을 보려면

redis 소개에 주의하세요. 튜토리얼

칼럼.

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