Redis 원리 및 구현 분석

다음 칼럼에서는 Redis 튜토리얼Redis 원리 및 구현 분석을 소개하겠습니다. 도움이 필요한 친구들에게 도움이 되길 바랍니다! 1 redis란 무엇입니까

redis는 nosql(또한 거대한 맵) 단일 스레드이지만 1초에 100,000개의 동시성을 처리할 수 있습니다(데이터는 모두 메모리에 있음)

Java를 사용하여 Redis를 작동하는 것은 jdbc 인터페이스와 유사합니다 mysql의 표준에는 이를 구현하는 다양한 구현 클래스가 있습니다. 우리가 일반적으로 사용하는 것은 druid입니다.

redis의 경우 일반적으로 Jedis를 사용합니다(연결 풀 JedisPool도 제공합니다)

redis에서 키는 byte[]입니다. (string)

redis의 데이터 구조(값):

String, list, set, orderset, hash

2 redis의 사용

먼저 Redis를 설치한 다음 실행하고 pom 파일에 종속성을 도입하고 redis 캐시를 사용하려는 클래스에 종속성을 추가합니다. mapper.xml 파일은 redis의 정규화된 이름을 구성합니다. redis의 redis.properties 파일을 소개합니다(구성을 변경하려는 경우 사용할 수 있습니다)

응용 시나리오:

String:

1은 json 유형 개체, 2개의 카운터, 3개의 Youku 비디오 좋아요 등을 저장합니다.

list(double 연결된 목록)
1개를 사용할 수 있습니다. Redis의 목록은 큐, 힙, 스택을 시뮬레이션합니다.

2개의 Moments 좋아요(1개의 Moments 콘텐츠 문, 여러 개의 likes 문)

규정: Moments 콘텐츠 형식:

1, 콘텐츠: 사용자:x: post:x 저장할 콘텐츠

2, like: post:x:저장할 좋은 목록(해당 아바타를 꺼내서 표시)

hash(해시맵)

1 개체 저장

2 그룹

3 문자열과 해시 데이터의 차이

네트워크를 통해 전송할 때는 직렬화를 거쳐야 네트워크를 통해 전송할 수 있습니다. 그런 다음 문자열 형식을 사용할 때는 직렬화를 해야 하며 해시도 필요합니다. 저장 시에는 해시를 더 풍부하게 저장할 수 있지만, 역직렬화 시 문자열의 역직렬화는 상대적으로 낮고, 해시의 직렬화 및 역직렬화는 해시 클래스에 상대적입니다. 더 복잡하므로 비즈니스 시나리오에 따라 데이터가 자주 수정되는 경우 성능을 위해 문자열을 사용할 수 있습니다. 데이터가 자주 변경되지 않는 경우 해시를 사용하면 데이터 저장이 풍부하므로 다양하게 저장할 수 있습니다. 데이터 유형

4 Redis 지속성 방법:

메모리의 데이터를 하드 디스크에 비동기식으로 쓸 수 있습니다. 두 가지 방법: RDB(기본값) 및 AOF

RDB 지속성 원칙: bgsave 명령에 의해 트리거된 다음 상위 프로세스는 포크 작업을 수행하여 하위 프로세스를 생성하고, 하위 프로세스는 RDB 파일을 생성하고, 상위 프로세스의 메모리를 기반으로 임시 스냅샷 파일을 생성하고, 완료 후 원본 파일의 원자적 교체를 수행합니다. 복사본을 생성하여 하드 디스크에 저장하는 시간)

장점: Redis는 RDB를 로드하여 AOF보다 훨씬 빠르게 데이터를 복구합니다.

단점: 매번 RDB를 생성하는 큰 오버헤드와 비실시간 지속성으로 인해

AOF 지속성 원칙: 전원이 켜진 후 Redis가 데이터를 수정하는 명령을 실행할 때마다 이 명령을 AOF 파일.

장점: 실시간 지속성.

단점: 따라서 AOF 파일 크기가 점차 커지며, 파일 크기를 줄이기 위해 정기적으로 다시 쓰기 작업을 수행해야 합니다. 로딩이 느립니다.

5 Redis 단일 스레드가 왜 이렇게 빠른가요

　Redis는 단일입니다. -스레드인데 왜 여전히 그렇게 빠른가요?

이유 1: 단일 스레드, 스레드 간 경쟁 방지

이유 2: 메모리에 있으며 메모리를 사용하므로 디스크 io를 줄일 수 있음

이유 3: 멀티플렉싱 모델 , 버퍼를 사용하여 개념을 구현합니다.

6 마스터가 다운되었을 때 Redis를 작동하는 방법

Redis는 마스터가 다운되면 다른 사람을 선택하여 이를 교체할 수 있는 모드를 제공합니다. 센티넬 모드는 세 가지 예정된 작업을 모니터링하는 것입니다.

　6.1 10초마다 각 S 노드(센티넬 노드)는 최신 토폴로지 구조를 얻기 위해 마스터 노드와 슬레이브 노드에 info 명령을 보냅니다.

　6.2 2초마다 각 S 노드는 S 노드의 정보를 특정 채널로 보냅니다. 마스터 노드의 판단과 현재 Sl 노드의 정보,

　동시에 각 Sentinel 노드도 이 채널을 구독하여 다른 S 노드와 그들의 판단에 대해 알아봅니다.

　6.3 1초마다 각 S 노드는 하트비트 감지(하트비트 감지 메커니즘)를 위해 마스터 노드, 슬레이브 노드 및 기타 S 노드에 ping 명령을 보내 여부를 확인합니다. 이 노드는 현재 도달 가능합니다



3번의 하트비트 감지 후 투표를 하고, 절반 이상의 투표를 받으면 해당 노드는 마스터로 간주됩니다.

7 redis 클러스터

Redis 클러스터는 Ruby를 제공합니다. 3.0 이후 구성용 스크립트, 거칠기 개념 소개,

　Redis 클러스터의 노드는 ping/pong 메시지를 통해 노드 통신을 실현합니다. 메시지는 노드 슬롯 정보를 전파할 뿐만 아니라 마스터-슬레이브 상태, 노드 실패 등과 같은 다른 상태도 전파할 수 있습니다. 따라서 오류 검색은 메시지 전파 메커니즘을 통해 실현됩니다. 주요 링크에는 주관적 오프라인(pfail)과 객관적인 오프라인(fail)이 포함됩니다. 주관적 오프라인:

주관적 오프라인: 클러스터의 각 노드는 정기적으로 다른 노드에 보고합니다. 노드 ping 메시지가 전송되고 수신 노드는 이에 대한 응답으로 pong 메시지로 응답합니다. 통신이 계속 실패하면 송신 노드는 수신 노드를 주관적으로 오프라인(pfail)으로 표시합니다.

　목표 오프라인: 노드의 절반 이상이면 마스터 노드는 객관적으로 오프라인이 됩니다.

　마스터 노드는 특정 마스터 노드를 장애 조치용 리더로 선출합니다.

　 Failover(슬레이브 노드를 새 마스터 노드로 선택)

8 메모리 제거 전략

Redis의 메모리 제거 전략은 Redis의 캐싱을 위한 메모리가 부족할 때 새로운 쓰기를 처리하는 방법과 추가 리소스를 적용해야 하는 필요성을 나타냅니다. 공간 데이터.

noeviction: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 새 쓰기 작업에서 오류가 보고됩니다.

allkeys-lru: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 키 공간에서 가장 최근에 사용된 키를 제거합니다.

allkeys-random: 메모리가 새로 작성된 데이터를 수용하기에 충분하지 않으면 키 공간에서 키가 무작위로 제거됩니다.

휘발성-lru: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 만료 시간이 설정된 키 공간에서 가장 최근에 사용된 키를 제거합니다.

휘발성-랜덤: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 만료 시간이 설정된 키 공간에서 키가 무작위로 제거됩니다.

휘발성-ttl: 새로 작성된 데이터를 수용할 만큼 메모리가 충분하지 않은 경우 만료 시간이 설정된 키 공간에서 만료 시간이 더 빠른 키가 먼저 제거됩니다.

9 캐시 고장 해결 방법:

이유: 다른 사람이 데이터를 요청할 때 캐시에 있는 많은 데이터를 쿼리할 수 없습니다. 데이터 쿼리를 직접 입력하세요.

해결 방법: 해당 데이터만 쿼리할 수 있습니다. 특별한 데이터베이스 쿼리인 경우

Bloom 필터를 사용하여 쿼리할 수도 있습니다.

10 캐시 눈사태 해결 방법:

캐시 눈사태의 원인: 한 번에 너무 많은 데이터가 캐시에 추가되어 메모리가 너무 부족해집니다. 높음, 이는 메모리 사용에 영향을 미치고 서비스 다운타임을 유발합니다

　해결책:

　1 Redis 클러스터, 클러스터링을 통해 데이터 배치

　2 백엔드 서비스 저하 및 전류 제한: 인터페이스에 요청이 너무 많으면 데이터가 너무 많습니다. 문제 발생을 줄이기 위해 서비스 흐름을 제한하고 액세스 횟수를 제한할 수 있습니다

위 내용은 Redis 원리 및 구현 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!