Redis 최적화 가이드: 네트워크, 메모리, 디스크, 차단 지점

Redis는 메모리 기반 작업이므로 CPU는 성능 병목 현상이 발생하지 않습니다. 반대로 서버의 메모리 활용도, 네트워크 IO, 디스크 읽기 및 쓰기는 Redis 성능에 중요한 역할을 합니다.

그래서 우리는 네트워크, 메모리, 디스크, 차단점 등의 측면에서 최적화에 중점을 둘 것입니다. 용어가 불명확한 경우 이전 호의 Redis 내용을 참조하거나 관련 정보를 참조하는 것이 좋습니다.

네트워크 최적화

클라이언트가 서버에 요청하는 경우, 즉 "요청-응답" 모드에서 최대한 일괄 처리를 사용하여 네트워크 IO 오버헤드를 줄입니다.

일괄 처리 기술: 원자 m 일괄 처리 지침, 파이프라인 기술, redis, 트랜잭션, lua 스크립트.

일괄 처리로 네트워크 IO 오버헤드 감소

Atomic m 일괄 처리 지침: 문자열 유형, get/set 대신 mget/mset를 사용하는 것이 좋습니다. hget/hset 대신 hmget/hmset를 사용하는 것이 좋습니다.

Pipline 기술: list, set, zset을 사용할 때 배치 작업이 있을 때 파이프라인 기술을 사용할 수 있습니다.

Redis 트랜잭션: 특별한 비즈니스 요구 사항에 여러 지침이 필요한 경우 권장됩니다.

lua 스크립트: 여러 명령의 원자성을 보장해야 하는 경우에는 lua 스크립트를 사용하는 것이 좋습니다. 구체적인 예로는 분산 잠금 해제, 플래시 판매 및 재고 감소가 있습니다.

노드 간 네트워크 최적화

동일한 LAN에 클러스터를 구축하세요.

분할 클러스터의 노드 수를 제어합니다. Redis 인스턴스에 할당된 해시 슬롯은 서로 다른 인스턴스 간에 전송되어야 하며, 부채 밸런싱 인스턴스가 삭제되면 데이터가 서로 다른 인스턴스 간에 전송됩니다. 하지만 해시 슬롯 정보가 크지 않고 데이터 마이그레이션이 점진적이지만 주요 문제는 아닙니다.

메모리 최적화

키 길이 조절: 키가 간단하고 명확하도록 개발 전에 사양을 정의하고, 업무에 맞게 키를 최대한 단축하는 것이 좋습니다.

큰 키 피하기: 문자열 유형의 권장 크기는 20KB 이내입니다. hash, list, set, zset의 임계값을 조절하는 것이 좋으며, 5000 이내로 조절하는 것이 좋습니다.

키 설정 만료: 메모리를 최대한 활용하세요.

올바른 데이터 구조를 선택하세요

문자열 유형의 경우 정수 유형을 사용하는 것이 좋습니다. 기본 인코딩은 메모리 오버헤드가 낮은 정수 인코딩을 선택합니다.

해시 유형의 경우 요소 임계값을 제어하는 ​​것이 좋습니다. 요소가 적을 경우 하위 계층은 메모리 오버헤드가 낮은 압축 목록 데이터 구조를 사용하며 요소 임계값을 제어하는 ​​것이 좋습니다. 요소 수가 적고 하위 레이어는 메모리 오버헤드가 낮은 압축 목록 데이터 구조를 사용하며 정수 유형을 저장하는 것이 좋습니다. 기본 인코딩은 정수 인코딩을 선택하며 메모리 오버헤드가 작습니다.

zset 유형에서는 요소 임계값을 제어하는 ​​것이 좋습니다. 요소 수가 적을 때 맨 아래 계층은 메모리 오버헤드가 낮은 압축 목록 데이터 구조를 사용합니다.

데이터 압축: 클라이언트는 메모리 사용량을 줄이기 위해 snappy 및 gzip과 같은 압축 알고리즘을 사용하여 데이터를 압축한 후 메모리 사용량을 줄일 수 있습니다.

메모리 제거 전략 활성화

기본적인 메모리 제거 전략을 끝내십시오. 메모리 활용도를 높이기 위해 실제 비즈니스에 맞는 적절한 제거 전략을 선택하십시오.

LRU: 액세스 횟수에 중점을 두고, 최근에 가장 적게 사용된 키를 제거하고, 다양한 사용 시나리오를 갖습니다. Redis의 LRU는 LRU와 유사한 알고리즘을 사용하여 마지막 액세스의 타임스탬프인 키에 24비트 길이의 추가 필드를 추가합니다. 게으른 처리 방법을 채택합니다. 쓰기 작업을 수행할 때 최대 메모리를 초과하면 LRU 제거 알고리즘이 한 번 실행되고 5개(설정 가능) 키가 무작위로 샘플링되고 가장 오래된 키가 제거됩니다. 제거 후에도 최대 메모리가 초과되면 제거가 계속됩니다.

LFU: 액세스 빈도에 중점을 두고 캐시 오염을 처리할 때 권장됩니다.

메모리 조각화 최적화 문제

이유: 하나는 메모리 할당자의 할당 전략으로 인해 발생합니다. 메모리 할당자는 실제 요청된 크기가 아닌 고정된 크기에 따라 할당합니다. 예를 들어 요청된 바이트가 요청된 바이트 내에 있는 경우 32바이트입니다. 실제로 할당되고, 다른 하나는 redis로 인해 발생합니다. 키-값 쌍이 삭제되면 공간 일부로 인한 메모리 조각화가 해제됩니다.

포지셔닝: INFO 메모리 명령을 통해 men_fragmentation_ratio 지표를 관찰합니다. 지표가 1-1.5 사이이면 정상이고, 지표가 1.5보다 크면 메모리 조각화 비율이 50%를 초과한 것이므로 메모리 조각화가 필요합니다.

처리됨

해결 방법: redis 인스턴스를 다시 시작하세요.

redis 자동 메모리 조각화 정리 기능을 활성화합니다.

디스크 최적화

Redis 서비스를 물리적으로 구축: 지속 시 Redis는 하위 프로세스(운영 체제의 포크 시스템을 호출함)를 생성하는 방법을 사용하며, 가상 머신 환경은 물리적 머신보다 포크를 실행하는 데 더 오랜 시간이 걸립니다.

지속성 최적화 메커니즘

지속성을 활성화하지 마세요. redis는 캐싱에만 사용되므로 디스크 오버헤드를 줄이기 위해 지속성을 활성화할 필요가 없습니다.

AOF 최적화: 백그라운드에서 AOF를 처리하고, 데이터 지속성 브러시 작업을 백그라운드 스레드에 넣어 실행하도록 apenfsync Everyec를 구성하고, 디스크에 Redis 쓰기가 성능에 미치는 영향을 줄이려고 노력합니다.

고빈도 AOF 지속성을 구축하지 마세요. AOF 지속성의 기본 빈도는 최대 1초 동안 데이터가 손실된다는 것을 보장하므로 수정하지 않는 것이 좋습니다.

하이브리드 지속성을 활성화합니다. redis4.0은 하이브리드 지속성 RDB + 증분 AOF를 지원합니다.

멀티 스레딩 구성을 활성화합니다. Redis 6.0 이전에는 기본 스레드 포크 하위 프로세스를 통해 지속성이 처리되었지만 6.0 이후에는 지속성 작업을 처리하기 위해 여러 프로세스가 지원됩니다.

클러스터 최적화

슬레이브는 지속성 최적화를 수행합니다. 마스터는 지속성을 수행하지 않고 마스터 디스크 IO의 압력을 최대한 공유합니다. 마스터-슬레이브 최적화: 증분 모드, 마스터-슬레이브 동기화 방법이 증분 모드로 지정되고 전체 RDB 모드 전체 모드는 하나의 마스터에 여러 슬레이브가 있는 경우 여러 슬레이브가 마스터로 와서 데이터를 동기화하므로 캐스케이드 동기화 모드를 사용하면 성능이 매우 저하됩니다.

이 문제에 대해 Redis는 계단식 동기화를 지원합니다. 즉, 마스터는 하나의 슬레이브에만 데이터를 동기화한 다음 이 슬레이브에서 다른 슬레이브의 데이터를 동기화하여 마스터에 대한 부담을 완화합니다.

실제 크기는 6G를 넘지 않는 것을 권장합니다. 인스턴스가 너무 크면 마스터-슬레이브 동기화가 중단되고 심각한 경우 마스터가 다운됩니다.

비정상 재시작 시 AOF가 재생됩니다. 인스턴스가 너무 크면 데이터 복구가 비정상적으로 느려집니다.

초크 포인트 최적화

분석: Redis는 요청 및 명령 처리 시 단일 스레드이므로 성능 병목 현상은 동기화 차단 문제입니다.

큰 문제

위험: bigkey를 읽고 쓰면 시간 초과가 발생할 수 있으며, redis는 단일 스레드에서 데이터를 작동하므로 전체 redis 서비스가 심각하게 차단될 수 있습니다. 게다가 키는 하나의 노드로만 분할되므로 스케치의 부담을 공유할 수 없습니다. Bigkey 감지: bredis-cli-bigkeys 명령과 함께 제공됩니다. Redis에는 다섯 가지 데이터 유형 중에서 가장 큰 키만 찾을 수 있는 지침이 제공되는데, 이는 그다지 유용하지도 않고 적극 권장되지도 않습니다. 파이썬 스캐닝 스크립트. 특정 키를 찾을 수 있지만 정확도가 높지 않아 권장되지 않습니다.

rdb_bigkeys 도구. Go로 작성된 도구로 빠르고 정확하며 쉽게 보고 추천할 수 있도록 CSV 파일로 직접 내보낼 수도 있습니다.

최적화: 문자열 유형이 아닌 bigkey의 경우 요소 세트를 여러 개로 분할할 수 있습니다. 예를 들어 bigkey가 1000개의 키로 분할되면 키의 접미사는 모듈로 1000으로 해시됩니다.

로컬 캐시를 사용하세요. 예를 들어 Redis에 비즈니스 ID + 버전 번호를 저장하고, 특정 콘텐츠를 로컬 캐시에 넣고, 각 쿼리에 대해 먼저 Redis 캐시를 확인한 다음, 로컬 캐시로 버전 번호를 확인하세요.

bigkey 최적화는 일반적으로 힘든 작업입니다. bigkey 문제를 방지하려면 개발 중에 사양을 정의하는 것이 좋습니다.

만료 정책

예약 삭제: 만료된 각 키에는 예약된 작업이 부여되며, 만료되면 바로 삭제됩니다. 메모리 사용량과 CPU 사용량이 높습니다. 지연 삭제: 키를 쿼리할 때 키가 만료되었는지 여부를 판단합니다. 만료된 경우에는 삭제됩니다. 이로 인해 CPU 사용량이 낮아지고 메모리 사용량이 높아집니다. 주기적 삭제: 가끔씩 검사하고 만료된 키는 직접 삭제하며 CPU 및 메모리 사용률은 평균입니다.

1. 탐욕스러운 전략. Redis는 만료된 키를 별도의 사전에 설정합니다.

2. 스캔 과정. 만료된 사전에서 20개의 키를 선택하고, 20개의 키 중에서 만료된 키를 삭제합니다. 삭제된 키의 비율이 1/4을 초과하는 경우 1단계를 반복합니다.

위 논리를 기반으로 과도한 루핑으로 인한 스레드 중단 문제를 해결하기 위해 알고리즘에 시간 초과 메커니즘이 추가되었습니다. 기본 시간은 25ms입니다.

3. 스캔 빈도: redis의 기본값은 초당 10번의 만료 스캔입니다.

Redis는 기본적으로 지연 삭제 + 일반 삭제를 활성화합니다.

최적화: 지연 없는 기능을 켜면 시간이 많이 소요되는 메모리 해제 작업이 redis4.0+에서 지원되는 백그라운드 스레드에서 실행됩니다.

멀티스레딩 모드 활성화. redis6.0 이전에는 만료 정책이 메인 스레드의 동기 작업이었습니다. Redis 6.0 이후에는 처리에 멀티스레딩이 사용되었습니다.

매우 복잡한 지침

일괄적으로 쿼리하려면 스캔을 사용하는 것이 좋으며 키를 사용하지 않는 것이 좋습니다. 집계 작업에는 적용할 수 없습니다. Redis는 단일 스레드 모델을 사용하여 요청을 처리합니다. 너무 복잡한 명령을 실행하면(더 많은 CPU 리소스 소비) SINTER, SINTERSTORW, ZUNIONSTORE, ZINTERSTORE와 같은 후속 요청이 대기열에 추가되어 지연이 발생합니다. 등. 컬렉션의 요소를 일괄적으로 찾고 클라이언트에서 집계 계산을 수행하려면 스캔을 사용하는 것이 좋습니다.

컨테이너형 데이터 작업: 컨테이너형 요소가 너무 많은 경우 직접 쿼리하면 네트워크로 인해 지연이 발생하므로 일괄적으로 쿼리하는 것이 좋습니다.

컨테이너 요소가 너무 많은 경우 키를 직접 삭제하면 Redis가 정지될 수 있으므로 일괄 삭제하는 것이 좋습니다.

위 내용은 Redis 최적화 가이드: 네트워크, 메모리, 디스크, 차단 지점의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!