Redis 관련 문제를 해결하는 방법

Redis 지속성 메커니즘

Redis는 지속성을 지원하는 인메모리 데이터베이스입니다. 지속성 메커니즘을 통해 메모리의 데이터를 하드 디스크 파일과 동기화하여 데이터 지속성을 보장합니다. Redis가 다시 시작되면 하드 디스크 파일을 메모리에 다시 로드하여 데이터를 복원할 수 있습니다.
구현: 별도의 fork() 하위 프로세스를 생성하고 현재 상위 프로세스의 데이터베이스 데이터를 하위 프로세스의 메모리에 복사한 후 하위 프로세스가 임시 파일에 씁니다. 이 임시 파일을 사용하면 마지막 스냅샷 파일이 삭제되고 하위 프로세스가 종료되고 메모리가 해제됩니다.

RDB은 Redis의 기본 지속성 방법입니다. 특정 기간 전략에 따라 메모리 데이터는 스냅샷 형식으로 하드 디스크의 바이너리 파일에 저장됩니다. 즉, 스냅샷 스냅샷 스토리지, 해당 생성 데이터 파일은 dump.rdb이며 스냅샷 주기는 구성 파일의 save 매개변수를 통해 정의됩니다. (스냅샷은 그것이 나타내는 데이터의 복사본이거나 데이터의 복사본일 수 있습니다.)
AOF: Redis는 MySQL binlog와 유사한 Write 함수를 통해 수신된 각 쓰기 명령을 파일 끝에 추가합니다. Redis가 다시 시작되면 파일에 저장된 쓰기 명령을 다시 실행하여 전체 데이터베이스의 내용을 메모리에 재구축합니다.
두 가지 방법을 동시에 활성화하면 데이터 복구 Redis는 AOF 복구에 우선 순위를 부여합니다.

캐시 사태, 캐시 침투, 캐시 예열, 캐시 업데이트, 캐시 다운그레이드 및 기타 문제

캐시 사태우리는 이를 다음과 같이 간단하게 이해할 수 있습니다. 원래 캐시가 무효화되어 새 캐시가 아직 만료되지 않았습니다(예: 예: 캐싱에 동일한 만료 시간이 사용되며 캐시의 넓은 영역이 동시에 만료됩니다.) 원래 캐시에 액세스해야 하는 모든 요청은 데이터베이스를 쿼리하게 되며 이는 데이터베이스에 큰 부담을 줍니다. 데이터베이스 CPU 및 메모리에 영향을 미쳐 데이터베이스 가동 중지 시간을 심각하게 초래할 수 있습니다. 이로 인해 일련의 연쇄 반응이 발생하여 전체 시스템이 붕괴됩니다.

Solution:대부분의 시스템 설계자는 한 번에 데이터베이스를 읽고 쓰는 스레드 수가 많지 않도록 잠금(가장 일반적인 솔루션) 또는 큐 사용을 고려합니다. 실패 이벤트 요청이 기본 스토리지 시스템으로 전달됩니다. 또 다른 간단한 해결책은 캐시 만료 시간을 분산시키는 것입니다.

캐시 침투캐시 침투는 사용자 쿼리 데이터를 의미하며, 이는 데이터베이스에서 찾을 수 없으며 당연히 캐시에서도 찾을 수 없습니다. 이로 인해 사용자는 쿼리할 때 캐시에서 해당 항목을 찾을 수 없게 되고, 매번 다시 쿼리하기 위해 데이터베이스로 이동해야 하며 그런 다음 빈 값을 반환해야 합니다(두 개의 쓸모 없는 쿼리와 동일). 이런 방식으로 요청이 캐시를 우회하고 데이터베이스를 직접 확인하는 방식이기도 합니다. 이 역시 자주 제기되는 캐시 적중률 문제입니다.

해결책;가장 일반적인 방법은
Bloom 필터를 사용하여 가능한 모든 데이터를 충분히 큰 비트맵으로 해시하는 것입니다. 확실히 존재하지 않는 데이터는 이 비트맵에 의해 차단되므로 기본 저장소에 대한 쿼리 부담을 피할 수 있습니다. 체계.더
간단하고 조악한 방법도 있습니다. 쿼리에서 반환된 데이터가 비어 있는 경우(데이터가 존재하지 않거나 시스템이 실패하더라도) 빈 결과를 캐시하지만 만료 시간은 매우 길어집니다. 짧습니다. 5분 이내입니다. 직접 설정된 기본값은 캐시에 저장되므로 데이터베이스에 계속 액세스하지 않고 두 번째로 캐시에서 값을 가져오는 방법이 가장 간단하고 조잡합니다.5TB 하드 드라이브에 데이터가 가득 차 있습니다. 데이터 중복을 제거하는 알고리즘을 작성해 주세요. 데이터가 32비트 크기인 경우 이 문제를 어떻게 해결합니까? 64비트라면 어떨까요?

비트맵: 대표적인 것이 해시 테이블입니다
단점은 비트맵이 각 요소에 대해 1비트의 정보만 기록할 수 있다는 점입니다. 추가 기능을 완성하려면 더 많은 공간과 시간을 희생해야만 할 수 있습니다.

Bloom 필터(권장)
는 k(k>1)k(k>1) 상호 독립적인 해시 함수를 도입하여 요소 가중치 결정이 주어진 공간 및 오판 비율 내에서 완료되도록 합니다.
일반적인 알고리즘에 비해 공간 효율성과 쿼리 시간이 훨씬 높다는 장점이 있고, 오인식률이 일정하고 삭제 어려움이 있다는 단점이 있습니다.
Bloom-Filter 알고리즘의핵심 아이디어는 여러 가지 해시 함수를 사용하여 "충돌"을 해결하는 것입니다.
해시에 충돌(충돌) 문제가 있습니다. 동일한 해시를 사용하여 얻은 두 URL의 값이 동일할 수 있습니다. 충돌을 줄이기 위해 해시를 여러 개 더 도입할 수 있습니다. 해시 값 중 하나를 통해 요소가 집합에 없다고 결론을 내리면 해당 요소는 확실히 집합에 없습니다. 모든 해시 함수가 해당 요소가 집합에 있음을 알려주는 경우에만 해당 요소가 집합에 존재하는지 확인할 수 있습니다. 이것이 Bloom-Filter의 기본 아이디어입니다.
Bloom-Filter는 일반적으로 대규모 데이터 세트에 요소가 존재하는지 확인하는 데 사용됩니다.
알림으로 추가됨: 캐시 침투와 캐시 고장의 차이
캐시 고장: 매우 뜨거운 키를 말하며, 현재 이 키에 액세스하는 데 대규모 동시성이 집중됩니다. 여전히 크기가 계속 큽니다. 동시 액세스는 캐시를 뚫고 데이터베이스를 직접 요청합니다.
해결 방법: 키에 액세스하기 전에 SETNX(존재하지 않는 경우 설정)를 사용하여 다른 단기 키를 설정하여 현재 키에 대한 액세스를 잠그고 액세스가 완료된 후 단기 키를 삭제하세요.

3.캐시 예열
캐시 예열은 비교적 일반적인 개념이어야 합니다. 캐시 예열은 시스템이 온라인 상태가 된 후 관련 캐시 데이터가 캐싱 시스템에 직접 로드된다는 의미입니다. 이런 방식으로 먼저 데이터베이스를 쿼리한 다음 사용자가 요청할 때 데이터를 캐싱하는 문제를 피할 수 있습니다! 예열된 캐시 데이터를 사용자가 직접 쿼리!
솔루션 아이디어:
1. 캐시 새로 고침 페이지를 직접 작성하고 온라인에 접속할 때 수동으로 수행합니다.
2. 데이터 양이 크지 않으며 프로젝트 시작 시 자동으로 로드할 수 있습니다.
3. 캐시를 정기적으로 새로 고칩니다.

캐시 업데이트캐시 서버와 함께 제공되는 캐시 무효화 전략(Redis에는 기본적으로 선택할 수 있는 6가지 전략이 있음) 외에도 특정 비즈니스 요구에 따라 캐시 제거를 사용자 정의할 수 있습니다. :
(1) 만료된 캐시를 정기적으로 정리합니다.
(2) 사용자가 요청하면 이 요청에 사용된 캐시가 만료되었는지 확인합니다. 만료된 경우 기본 시스템으로 이동하여 새 데이터를 얻고 캐시를 업데이트합니다.
둘 다 장단점이 있습니다. 첫 번째의 단점은 캐시된 키를 많이 유지하는 것이 더 번거롭다는 것입니다. 두 번째의 단점은 사용자가 요청할 때마다 캐시를 판단해야 한다는 것입니다. 유효하지 않으며 논리가 상대적으로 복잡합니다! 구체적으로 사용할 솔루션은 자체 애플리케이션 시나리오에 따라 평가될 수 있습니다.
5.
캐시 다운그레이드방문 횟수가 급격하게 증가하거나, 서비스 문제(응답 시간이 느리거나 응답이 없는 등)가 발생하거나, 비핵심 서비스가 핵심 프로세스의 성능에 영향을 미치는 경우에도 여전히 확인이 필요합니다. 서비스가 손상되더라도 서비스는 계속 이용 가능합니다. 시스템은 일부 주요 데이터를 기반으로 자동으로 다운그레이드하거나 스위치를 구성하여 수동으로 다운그레이드할 수 있습니다.
다운그레이드의 궁극적인 목표는 손실이 발생하더라도 핵심 서비스를 사용할 수 있도록 하는 것입니다. 그리고 일부 서비스(장바구니에 추가, 결제 등)는 다운그레이드할 수 없습니다.
참조 로그 수준에 따라 계획을 설정하세요.
(1) 일반: 예를 들어 일부 서비스는 네트워크 지터로 인해 때때로 시간이 초과되거나 서비스가 온라인 상태가 되어 자동으로 다운그레이드될 수 있습니다. 일정 기간(예: 95~100% 사이)에 걸쳐 성공률이 변동하는 경우 자동으로 다운그레이드하거나 수동으로 다운그레이드하고 알람을 보낼 수 있습니다.
(3) 오류: 예를 들어 가용성 비율이 90%보다 낮습니다. 또는 데이터베이스 연결 풀이 소진되거나 방문 횟수가 갑자기 시스템이 견딜 수 있는 최대 임계값으로 증가합니다. 이때 상황에 따라 자동으로 다운그레이드되거나 수동으로 다운그레이드될 수 있습니다.
(4) 심각한 오류의 경우; 예를 들어, 특별한 사유로 인해 데이터가 잘못된 경우 긴급 수동 다운그레이드가 필요합니다.

서비스 다운그레이드의 목적은 Redis 서비스 실패로 인해 데이터베이스 사태 문제가 발생하는 것을 방지하는 것입니다. 따라서 중요하지 않은 캐시 데이터의 경우 서비스 다운그레이드 전략을 채택할 수 있습니다. 예를 들어 Redis에 문제가 있으면 데이터베이스를 쿼리하는 대신 기본값을 사용자에게 직접 반환하는 것이 일반적인 접근 방식입니다.

핫 데이터와 콜드 데이터는 무엇인가요?

핫 데이터, 캐시는 가치가 있습니다
콜드 데이터의 경우 대부분의 데이터가 다시 액세스되기 전에 메모리에서 압착되어 메모리를 차지할 뿐만 아니라 데이터가 거의 없습니다. 값. 수정이 잦은 데이터의 경우 상황에 따라 캐시 활용을 고려해보세요. 위 두 예시의 경우, 장수 목록과 내비게이션 정보 모두 정보 수정 빈도가 높지 않고 읽기 속도도 보통이라는 특징이 있습니다. 매우 높습니다.
IM 제품 중 하나, 생일 인사말 모듈, 오늘의 생일 목록 등 핫 데이터의 경우 캐시를 수십만 번 읽을 수 있습니다. 또 다른 예로 내비게이션 제품에서는 내비게이션 정보를 캐시하고 향후 수백만 번 읽을 수도 있습니다.
**캐시는 업데이트하기 전에 데이터를 두 번 이상 읽는 경우에만 의미가 있습니다. 이것이 가장 기본적인 전략입니다. 캐시가 적용되기 전에 실패하면 별 가치가 없습니다.
캐시가 존재하지 않고 수정 빈도가 매우 높지만 캐싱을 고려해야 하는 시나리오는 어떻습니까? 가지다! 예를 들어, 이 읽기 인터페이스는 데이터베이스에 많은 부담을 주지만 동시에 핫 데이터이기도 합니다. 이때 좋아요 수, 컬렉션 수 등 데이터베이스에 대한 부담을 줄이기 위한 캐싱 방법을 고려해야 합니다. 이는 매우 일반적인 핫 데이터이지만 계속 변경됩니다. 이때 데이터는 데이터베이스에 대한 부담을 줄이기 위해 동기식으로 Redis 캐시에 저장되어야 합니다.

2) 데이터 지원 유형 memcached의 모든 값은 이를 대체하기 위해 더 풍부한 데이터 유형을 지원하고 list, set, Storage를 제공합니다. zset 및 hash와 같은 데이터 구조
3) 사용되는 기본 모델이 다르며 클라이언트와의 통신을 위한 기본 구현 방법 및 애플리케이션 프로토콜도 다릅니다. Redis는 자체 VM 메커니즘을 직접 구축했습니다. 일반 시스템이 시스템 기능을 호출하면 이동 및 요청에 일정 시간이 낭비되기 때문입니다.
4) 값 값 크기는 다릅니다. Redis는 최대 512M에 도달할 수 있습니다.
5) Redis의 속도는 memcached보다 훨씬 빠릅니다.
6) Redis는 데이터 백업, 즉 마스터-슬레이브 모드에서의 데이터 백업을 지원합니다.

(2) 단일 스레드 작업, 잦은 컨텍스트 전환 방지
(3) 비차단 I/O 다중화 메커니즘 사용

(1) String
이에 대해 실제로 말할 것은 없습니다. 가장 일반적인 설정/가져오기 작업은 값이 문자열이거나 문자열일 수 있습니다. 숫자. 일반적으로 일부 복잡한 계산 기능이 캐시됩니다.
(2) Hash
여기서 값은 구조화된 객체를 저장하며, 그 안에 특정 필드를 조작하는 것이 더 편리합니다. 블로거는 Single Sign-On을 수행할 때 이 데이터 구조를 사용하여 사용자 정보를 저장하고, cookieId를 키로 사용하고, 캐시 만료 시간을 30분으로 설정하므로 세션과 유사한 효과를 매우 잘 시뮬레이션할 수 있습니다.
(3) list
List의 데이터 구조를 이용하면 간단한 메시지 큐 기능을 수행할 수 있습니다. 또 다른 점은 lrange 명령을 사용하여 redis 기반 페이징 기능을 구현할 수 있다는 것인데, 이는 뛰어난 성능과 좋은 사용자 경험을 제공합니다. 나는 또한 시장 정보를 얻는 매우 적합한 시나리오를 사용합니다. 생산자와 소비자의 현장이기도 하다. LIST는 큐잉 및 선입선출 원칙을 매우 잘 구현할 수 있습니다.
(4) 집합
집합은 고유한 값의 집합이기 때문입니다. 따라서 전역 중복 제거 기능을 구현할 수 있습니다. 중복 제거를 위해 JVM과 함께 제공되는 세트를 사용하는 것은 어떻습니까? 우리 시스템은 일반적으로 클러스터로 배포되기 때문에 JVM과 함께 제공되는 Set을 사용하는 것이 번거롭습니다. 단지 전역 중복 제거를 수행하기 위해 공용 서비스를 설정하는 것이 너무 번거롭습니까?
또한 교집합, 합집합, 차이 등의 연산을 이용하여 공통 선호도, 모든 선호도, 나만의 고유 선호도 등을 계산할 수 있습니다.
(5) sorted set
sorted set에는 추가 가중치 매개변수 점수가 있으며, 세트의 요소는 점수에 따라 배열될 수 있습니다. 순위신청을 하고 TOP N 연산을 수행할 수 있습니다.

• dict는 본질적으로 알고리즘(Searching)에서 검색 문제를 해결하기 위한 것입니다. 이는 많은 언어의 Map 또는 Dictionary와 유사하게 키와 값 사이의 매핑 관계를 유지하는 데 사용되는 데이터 구조입니다. 본질적으로 알고리즘의 검색 문제(Searching)를 해결하는 것입니다.

• sds sds는 char *와 동일합니다. 모든 바이너리 데이터를 저장할 수 있으며 C 언어 문자열과 같은 문자로 표현할 수 없습니다.

redis의 만료 전략 및 메모리 제거 메커니즘

redis는정기 삭제 + 지연 삭제 전략을 채택합니다.
예약 삭제 전략을 사용하면 어떨까요?
예약 삭제는 타이머를 사용하여 키를 모니터링하며 만료되면 자동으로 삭제됩니다. 메모리는 제때 해제되지만 CPU 리소스를 많이 소모합니다. 대규모 동시 요청의 경우 CPU는 키를 삭제하는 대신 요청을 처리하는 데 시간을 사용해야 하므로 이 전략은 채택되지 않습니다.
일반 삭제 + 지연 삭제는 어떻게 작동하나요?
일반 삭제, redis의 기본값은 각각 100ms입니다. 확인 만료된 키가 있는지 확인하고, 만료된 키가 있으면 삭제합니다. Redis는 100ms마다 모든 키를 확인하지 않지만 검사를 위해 무작위로 선택한다는 점에 유의해야 합니다(모든 키를 100ms마다 확인하면 Redis가 중단되지 않습니까?). 따라서 일반 삭제 전략만 채택하면 그 때까지 많은 키가 삭제되지 않습니다.
그래서 게으른 삭제가 유용합니다. 즉, 키를 얻을 때 Redis는 만료 시간이 설정되어 있으면 키가 만료되었는지 여부를 확인합니다. 만료되면 이때 삭제됩니다.
정기삭제 + 지연삭제를 하면 다른 문제는 없나요?
아니요, 정기적으로 삭제해도 키가 삭제되지 않는다면요. 그런 다음 키를 즉시 요청하지 않았으므로 지연 삭제가 적용되지 않았습니다. 이런 식으로 Redis의 메모리는 점점 더 높아질 것입니다. 그런 다음 메모리 제거 메커니즘을 채택해야 합니다.
redis.conf에 구성 줄이 있습니다

maxmemory-policy volatile-lru

이 구성은 메모리 제거 전략으로 구성됩니다(뭐, 구성하지 않았나요? 스스로 생각해 보세요)

휘발성-lru: 다음을 사용하여 설정된 데이터에서 만료 시간 설정(server.db[i].expires에서 가장 최근에 사용된 데이터 선택)을 제거하고
휘발성-ttl: 데이터 세트(server.db[i])에서 만료 예정인 데이터를 선택합니다. .expires)를 제거하기 위한 만료 시간 설정
휘발성-random: 만료 시간이 설정된 데이터 세트(server.db[i].expires)에서 제거할 데이터를 무작위로 선택
allkeys-lru: 데이터 세트 (server.db[i].dict) 제거를 위해 가장 최근에 사용된 데이터 선택
allkeys-random: 제거를 위해 데이터 세트(server.db[i].dict)에서 임의로 데이터를 선택
no- enviction(제거): 데이터 제거 비활성화, 새 쓰기 작업 오류가 보고됩니다
ps: 만료 키가 설정되지 않고 전제 조건이 충족되지 않으면 휘발성-lru, 휘발성-랜덤 및 휘발성-의 동작이 수행됩니다. ttl 전략은 기본적으로 noeviction(삭제되지 않음)과 동일합니다.

Redis가 단일 스레드인 이유

공식 FAQ에는 Redis가 메모리 기반 작업이므로 CPU가 Redis의 병목 현상이 아니라고 명시되어 있습니다. Redis의 병목 현상은 머신 메모리나 네트워크의 크기일 가능성이 높습니다. 대역폭. 싱글 스레딩은 구현하기 쉽고 CPU에 병목 현상이 발생하지 않으므로 싱글 스레드 솔루션을 채택하는 것이 논리적입니다(결국 멀티 스레딩을 사용하면 많은 문제가 발생합니다!) Redis는 대기열 기술을 사용하여 직렬 액세스에 대한 동시 액세스
1) 물론 대부분의 요청은 순수한 메모리 작업입니다(매우 빠름) 2) 단일 스레드, 불필요한 컨텍스트 전환 및 경쟁 조건 방지
3) 비차단 IO 이점:
1. 데이터가 저장되므로 빠릅니다. 메모리에서는 HashMap과 마찬가지로 검색 및 연산의 시간 복잡도가 O(1)이라는 장점이 있습니다
2. 풍부한 데이터 유형을 지원하고 string, list, set, sorted set, hash를 지원합니다
3. 트랜잭션을 지원하고, 작업은 원자적입니다. 소위 원자성이란 데이터에 대한 모든 변경 사항이 실행되거나 전혀 실행되지 않음을 의미합니다.
4. 풍부한 기능: 캐싱, 메시징 및 키별 만료 시간 설정에 사용할 수 있습니다. 자동으로 삭제됩니다. 만료 후 Redis에서 동시 키 경쟁 문제를 해결하는 방법

동시에 키를 설정하는 여러 하위 시스템이 있습니다. 이때 우리가 주의해야 할 점은 무엇입니까? Redis의 트랜잭션 메커니즘을 사용하는 것은 권장되지 않습니다. 우리 프로덕션 환경은 기본적으로 Redis 클러스터 환경이므로 데이터 샤딩 작업이 수행됩니다. 트랜잭션에 여러 키 작업이 포함된 경우 이러한 여러 키가 반드시 동일한 redis 서버에 저장될 필요는 없습니다. 따라서 Redis의 트랜잭션 메커니즘은 매우 쓸모가 없습니다.
(1) 이 열쇠를 조작할 경우에는 순서가 필요하지 않습니다. 분산형 자물쇠를 준비하여 모두가 자물쇠를 잡고, 자물쇠를 잡은 후 설정된 조작만 하면 됩니다
(2) 이 열쇠를 조작하면 명령이 필요하지 않습니다. 필수 사항: 분산 잠금 + 타임스탬프. 시스템 B가 먼저 잠금을 잡고 key1을 {valueB 3:05}로 설정한다고 가정합니다. 다음으로, 시스템 A는 잠금을 획득하고 값 A의 타임스탬프가 캐시의 타임스탬프보다 이전임을 확인하므로 설정 작업을 수행하지 않습니다. 등등.
(3) 큐를 사용하여 설정 방법을 직렬 액세스로 전환하면 Redis가 키 읽기 및 쓰기의 일관성이 보장되는 경우에도 도움이 될 수 있습니다.
Redis의 모든 작업은 원자적이고 스레드로부터 안전할 수 있습니다. 동시성 문제를 고려하기 위해 Redis는 이미 내부적으로 동시성 문제를 처리했습니다.

Redis 클러스터 솔루션으로 무엇을 해야 합니까? 계획은 무엇입니까?

1.twemproxy는 일반적인 개념은 프록시 방식과 비슷하다는 점인데, 사용하게 되면 redis가 연결되어야 하는 곳이 twemproxy로 연결되도록 변경되어 요청을 프록시로 받아 일관된 해시를 사용하게 됩니다. 요청을 전송하는 알고리즘입니다. 특정 redis를 수신하고 결과를 twemproxy로 반환합니다.
단점: twemproxy 자체의 단일 포트 인스턴스의 압박으로 인해 일관된 해싱을 사용한 후 Redis 노드 수가 변경되면 계산된 값이 변경되고 데이터를 새 노드로 자동 이동할 수 없습니다.

2.codis 현재 가장 많이 사용되는 클러스터 솔루션은 기본적으로 twemproxy와 동일한 효과를 가지지만, 노드 수가 변경되면 오래된 노드 데이터를 새로운 해시 노드로 복구하는 기능을 지원합니다

3.redis는 Cluster3와 함께 제공됩니다. .0 클러스터의 특징은 분산 알고리즘이 일관된 해싱이 아닌 해시 슬롯 개념이며, 슬레이브 노드 설정을 지원한다는 점입니다. 자세한 내용은 공식 문서를 참조하세요.

여러 머신에 Redis를 배포해 보셨나요? 데이터 일관성을 보장하는 방법은 무엇입니까?

마스터-슬레이브 복제, 읽기와 쓰기의 분리
하나는 마스터 데이터베이스(master)이고 다른 하나는 슬레이브 데이터베이스(slave)입니다. 마스터 데이터베이스는 쓰기 작업이 발생하면 데이터를 읽고 쓸 수 있습니다. 슬레이브 데이터베이스는 일반적으로 읽기 전용이며 마스터 데이터베이스에서 동기화된 데이터를 수신합니다. 마스터 데이터베이스는 여러 개의 슬레이브 데이터베이스를 가질 수 있지만 슬레이브 데이터베이스는 하나의 마스터 데이터베이스만 가질 수 있습니다.

많은 수의 요청을 처리하는 방법

redis는 단일 스레드 프로그램이므로 동시에 하나의 클라이언트 요청만 처리할 수 있습니다.
redis는 IO 다중화(선택, epoll, kqueue에 따라 다름)를 사용합니다. 상황) 플랫폼, 다양한 구현 채택) 여러 클라이언트 요청을 처리하기 위해

Redis의 일반적인 성능 문제 및 솔루션은 무엇입니까?

(1) 마스터는 RDB 메모리 스냅샷, AOF 로그 파일 등의 지속성 작업을 하지 않는 것이 가장 좋습니다
(2) 데이터가 중요한 경우 슬레이브는 AOF 백업 데이터를 활성화하고 정책은 1회씩 동기화하도록 설정됩니다. second
(3) 마스터-슬레이브 복제 속도와 연결 안정성을 위해서는 마스터와 슬레이브가 동일한 LAN에 있는 것이 가장 좋습니다
(4) 마스터 라이브러리에 슬레이브 라이브러리를 추가하지 마세요. 큰 압박감
(5) 마스터-슬레이브 복제 구조에 그림을 사용하지 마세요. 단방향 연결 리스트 구조, 즉 Master Slave3..를 사용하는 것이 더 안정적입니다. .

Redis 스레드 모델 설명

파일 이벤트 프로세서에는소켓, I/O 멀티플렉서, 파일 이벤트 디스패처(디스패처) 및 이벤트 핸들러가 포함됩니다. I/O 멀티플렉서를 사용하여 동시에 여러 소켓을 수신하고 현재 수행 중인 작업을 기반으로 다양한 이벤트 핸들러를 소켓과 연결합니다. 모니터링되는 소켓이 연결 응답(accept), 읽기(read), 쓰기(write), 닫기(close) 등의 작업을 수행할 준비가 되면 해당 작업에 해당하는 파일 이벤트가 생성됩니다. 파일 이벤트 핸들러는 이전에 소켓과 연관된 이벤트 핸들러를 호출하여 이러한 이벤트를 처리합니다.
I/O 멀티플렉서는 여러 소켓을 수신하고 이벤트를 생성한 소켓을 파일 이벤트 디스패처에 전달하는 역할을 합니다.
작동 원리:
1) I/O 멀티플렉서는 여러 소켓을 수신하고 이벤트를 생성한 소켓을 파일 이벤트 디스패처로 전송하는 역할을 합니다.
여러 파일 이벤트가 동시에 발생할 수 있지만 I/O 멀티플렉서는 항상 모든 이벤트 생성 소켓을 대기열에 넣은 다음 이 대기열을 순서대로(순차적으로) 통과하여 동기적으로 소켓을 파일 이벤트 디스패처에 하나의 소켓으로 전송합니다. 한 번에: 이전 소켓에서 생성된 이벤트가 처리된 후(소켓은 이벤트와 연결된 이벤트 핸들러입니다. I/O 멀티플렉서는 I/O 멀티플렉서가 완료될 때까지 계속해서 다음 소켓을 파일 이벤트 디스패처에 전달합니다. 실행). 소켓이 읽기 및 쓰기 가능하다면 서버는 먼저 소켓을 읽은 다음 소켓을 씁니다.

Redis 작업이 원자성인 이유와 원자성을 보장하는 방법은 무엇입니까?

Redis의 경우 명령의 원자성은 작업을 세분화할 수 없으며 작업이 실행되거나 실행되지 않음을 의미합니다.
Redis 작업이 원자적인 이유는 Redis가 단일 스레드이기 때문입니다.
Redis 자체에서 제공하는 모든 API는 원자성 작업입니다. Redis의 트랜잭션은 실제로 배치 작업의 원자성을 보장합니다.
여러 명령이 동시에 원자적으로 실행되나요?
반드시 그런 것은 아닙니다. get 및 set을 단일 명령 작업으로 변경하세요. Redis 트랜잭션을 사용하거나 Redis+Lua==를 사용하여 구현하세요.

Redis transaction

Redis 트랜잭션 기능은 MULTI, EXEC, DISCARD 및 WATCH의 네 가지 기본 요소를 통해 구현됩니다.
Redis는 트랜잭션의 모든 명령을 직렬화한 후 순서대로 실행합니다.
1. redis는 롤백을 지원하지 않습니다. "Redis는 트랜잭션이 실패해도 롤백하지 않고 나머지 명령을 계속 실행합니다." 따라서 Redis의 내부는 간단하고 빠르게 유지될 수 있습니다.
2. 트랜잭션의명령에 오류가 발생하면모든 명령이 실행되지 않습니다.
3. 트랜잭션에서실행 오류가 발생하면올바른 명령이 실행됩니다.
참고: Redis를 삭제하면 이 트랜잭션만 종료되며 올바른 명령의 영향은 여전히 존재합니다.

1) MULTI 명령은 트랜잭션을 시작하는 데 사용되며 항상 OK를 반환합니다. MULTI가 실행된 후 클라이언트는 원하는 만큼의 명령을 서버에 계속 보낼 수 있습니다. 이러한 명령은 즉시 실행되지 않지만 EXEC 명령이 호출되면 대기열에 있는 모든 명령이 실행됩니다. .
2) EXEC: 모든 트랜잭션 블록 내에서 명령을 실행합니다. 명령 실행 순서대로 정렬되어 트랜잭션 블록 내의 모든 명령의 반환 값을 반환합니다. 작업이 중단되면 빈 값 nil이 반환됩니다.
3) DISCARD를 호출하면 클라이언트는 트랜잭션 대기열을 지우고 트랜잭션 실행을 포기할 수 있으며 클라이언트는 트랜잭션 상태를 종료합니다.
4) WATCH 명령은 Redis 트랜잭션에 대한 확인 및 설정(CAS) 동작을 제공할 수 있습니다. 하나 이상의 키를 모니터링할 수 있습니다. 키 중 하나가 수정(또는 삭제)되면 후속 트랜잭션은 실행되지 않으며 EXEC 명령이 실행될 때까지 모니터링이 계속됩니다.

Redis는 분산 잠금을 구현합니다.

Redis는 단일 프로세스 단일 스레드 모드로 동시 액세스를 직렬 액세스로 전환하며 SETNX 명령을 사용할 수 있습니다. Redis 스타일 잠금으로 배포를 달성합니다.
키가 존재하지 않는 경우에만 키 값을 value로 설정하세요. 주어진 키가 이미 존재하면 SETNX는 아무런 조치도 취하지 않습니다

잠금 해제: del key 명령을 사용하여 잠금을 해제합니다.
교착 상태 해결:
1) Redis에서 만료()를 통해 잠금의 최대 유지 시간을 설정합니다. , 초과하는 경우 Redis가 잠금 해제를 도와줄 것입니다.
2) 이는 setnx 키 "현재 시스템 시간 + 잠금 유지 시간"과 getset 키 "현재 시스템 시간 + 잠금 유지 시간"의 명령 조합을 사용하여 달성할 수 있습니다.

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