redis 문제

리드는 어떤 일을 하나요?

왜 이렇게 빠른가요?

사용 시나리오는 어떻게 되나요?

1. 데이터 캐싱 2. 카운터 3. 시간 제한 4. 흐름 제한 5. 분산 잠금 6. 대기열 7. 구독 게시

redis의 데이터 구조는 무엇인가요?

공통

• 문자열 문자열, 정수 및 부동 소수점 쌍입니다.
• list 연결된 목록 , 문자열
• 환원 불가능한 집합 집합, 교집합, 합집합, 차이 집합
• 해시 주문되지 않은 해시
• zset 중복되지 않은 분수 주문 랭킹 스페셜
• 기본 통계 하이퍼로그
• 비트맵
• geo

redis의 기본 데이터 구조는 무엇인가요?

• sds 동적 문자열
• quicklist
• ziplist
• inset
• dict
• skiplist

왜 디자인 SDS인가?

• 문자열 길이를 얻기 위한 일정한 복잡성
• 버퍼 오버플로 제거, 길이 먼저 판단하기
• 메모리 할당 횟수, 사전 할당, 비활성 여유 공간 감소
• 호환 가능한 부분 C 함수
• 이진 보안 , 그림 , 빈 문자 , 특수 기호 저장 , 판단 종료

문자열은 얼마나 크게 저장되나요?

• 512m

stream

디자인 스트림이 필요한 이유

redis는 게시-구독 기능을 지원하지만 다음과 같은 단점이 있습니다.

• 목록 및 제트, 지속성 지원, 앵커, 멀티캐스트 미지원

스트림 소비자 메시지 손실

• 그룹 소비자가 메시지를 소비하려면 이제 읽기 위치를 기록하고, 소비하고, 응답하고, 메시지를 다시 기록하고, 소비자가 다운되면 쿼리 펭귄 목록을 호출하고, 읽지 않은 메시지를 읽지 못한 메시지를 읽을 수 있습니다.

스트림 메시지 비공개 메시지 문제

• 반복적으로 실패하는 메시지의 경우 redis가 실패 횟수를 기록하고 특정 실패 횟수에 도달하면 메시지에 표시가 되며, 소비자는 이 표시를 조회하여 메시지를 삭제할지 또는 처리 방법을 결정할 수 있습니다.

내구성 있는 메커니즘

REDIS 지속성 메커니즘, 장단점, 사용 방법

두 가지 주요 접근 방식이 사용됩니다.

• DB 지속성을 사용하는 스톡 복제는 이미 존재하는 대량의 데이터를 빠르고 메모리 집약적으로 스냅샷으로 만듭니다.
• 증분 복제, rdb만 사용하는 경우, 쓸 때마다 데이터를 redis하면 실시간 지속성이 필요하므로 적합하지 않으므로 aof log를 사용하면 텍스트 방식을 통해 명령을 redis하여 파일에 실시간으로 추가 할 수 있습니다.
• redis 4.0은 rdb가 타이머로 실행되고 명령이 aof를 사용하여 추가되는 하이브리드 모드를 사용하여 포크 하위 프로세스가 메모리에 미치는 영향을 피하고 모든 명령을 기록합니다.

그렇다면 DB는 어떻게 트리거할까요?

• 수동으로 트리거
• 마스터 프로세스에서 실행되는 저장 명령은 클라이언트를 차단하므로 프로덕션 환경에서는 금지됩니다.
• 새 버전의 redis에 도입된 bgsave 명령은 자식 프로세스를 포크하여 백그라운드에서 실행하므로 포크 단계에서만 차단이 발생하지만 나머지는 정상적으로 작동합니다.
• 자동으로 트리거됨
• 구성 파일 구성 저장 시간 m초 n회
• 마스터-슬레이브 복제, 슬레이브 노드 전체 복제를 수행할 때
• aof를 켜지 않은 상태에서 종료 명령을 실행하면 다음을 수행합니다.
• 디버그 재로드 명령을 실행하여 redis를 다시 로드하면

DB 기간 동안 메모리가 매우 큰 경우 쓰기 작업이 있는 경우 데이터 일관성을 보장하는 방법

• rdb는 하위 프로세스를 포크하여 복사-온-쓰기를 사용하고, t0redis가 t1을 시작한다고 가정하고, rdb는 먼저 마스터 프로세스를 포크하여 t0-t1 기간의 데이터를 백업하고, 백업 완료 시간 t2를 가정하고, t1-t2 기간의 데이터를 어떻게 해야 하나요?
• rdb 기간 동안 redis는 복사본을 복사하는 동안 메모리 버퍼인 t1-t2를 제공하고, 이 버퍼에 쓰고, 동기화가 끝난 후 다시 rdb를 사용하여

마스터 프로세스 포크 하위 프로세스가 데이터를 복사하는 방법

• 포크 명령은 운영 체제에서 제공하며 메모리 복사본을 복사하지 않고 가상 페이지 테이블 대응만 복사하여 CPU 리소스를 소비합니다.
• 클라이언트가 데이터를 읽을 때, 메인 프로세스 데이터를 직접 읽습니다.
• 클라이언트가 데이터를 쓰면 복사본이 만들어집니다.

그렇다면 rdb 중에 서비스가 충돌하면 어떻게 될까요?

• rdb는 시간이 정해져 있고, redis는 가장 최근의 rdb 스냅샷을 저장하며, 최신 스냅샷이 충돌하면 성공으로 간주되지 않으므로 redis를 다시 시작하면 마지막으로 성공한 rdb 스냅샷을 사용하여 복구합니다.
• 데이터가 손실되면 매초마다 복구할 수 있나요?
• 리소스를 낭비하는 행위이므로 적극 권장하지 않습니다.
• 포크 하위 프로세스는 CPU와 메모리를 소모하고 bgsave를 여러 번 실행하여 메인 프로세스를 차단합니다.
• 디스크를 많이 사용하는 여러 개의 백업하기
• aof와 rdb의 조합을 권장합니다.

그렇다면 AOF는 어떻게 작동할까요?

• aof 로그는 모든 redis 쓰기 명령에 대한 기록입니다. redis 명령이 성공적으로 쓰여질 때마다 aof_buf 버퍼로 전송되며, 이 버퍼는 redis가 파일을 읽고 쓰는 역할을 합니다.
• 파일 쓰기 및 추가 시간 , aof_buf는 언제 aof 파일에 기록되나요?

재정의란 무엇인가요?

aof가 계속 추가되면 오랜 시간이 지나면 파일이 매우 커집니다. redis는 이 문제를 최적화하기 위해 aof 재작성을 도입했습니다.

• redis는 새 파일을 생성하고, 명령을 사용하여 redis 데이터베이스의 데이터를 aof 파일에 다시 쓴 다음 대체 aof 파일을 작성합니다.
• 이렇게 하면 여러 개의 추가/삭제 명령이 필요하지 않으므로 용량이 줄어듭니다.

aof가 다시 작성되면 메인 스레드에서 차단되는 것은 무엇인가요?

• 하위 프로세스를 포크하려면 가상 페이지 테이블을 복사해야 합니다.
• 큰 키로 쓰면 사본이 필요합니다.
• aof가 쓰기를 마친 후 마스터 프로세스가 aof 버퍼 데이터를 추가할 때 aof는 어떻게 트리거되나요?
• 2
• auto-aof-rewrite-min-size: AOF 다시 쓰기를 실행할 때 파일의 최소 크기를 나타내며, 기본값은 64MB입니다.
• auto-aof-rewrite-percentage: 이 값은 현재 aof 파일 크기와 마지막 다시 쓰기 후의 aof 파일 크기 간의 차이를 마지막 다시 쓰기 후의 aof 파일 크기로 나눈 값으로 계산됩니다. 즉, 마지막 다시 쓰기 후의 aof 파일과 비교한 현재 aof 파일의 증분 크기와 마지막 다시 쓰기 후의 aof 파일 크기의 비율입니다.

다시 쓰면 새 데이터가 쓰여지는데 어떻게 해야 하나요?

• 요약하면, 하나의 복사본과 두 개의 로그가 있으며 재설정 시 하위 프로세스는 포크되고 마스터 프로세스는 명령을 두 개의 aof 버퍼에 기록합니다.
• bgrewriteaof가 다시 완료되면 마스터 프로세스에 알리고, 마스터 프로세스는 aof 버퍼 명령을 새 aof 로그 파일에 추가합니다.
• 완료, 이름 바꾸기를 사용하여

마스터-슬레이브 모드

redis 마스터-슬레이브란 무엇이며 왜 필요한가요?

• 일반적으로 레디스는 단 하나의 노드, 즉 하나의 레디스만 서비스를 제공하는데, 마스터-슬레이브는 가장 간단하게 말하면 두 개의 레디스 서버 중 하나는 마스터 서버로, 다른 하나는 슬레이브 서버로 마스터 서버의 모든 데이터를 동기화할 수 있는 슬레이브 서버로 사용하는 방식입니다.
• 제공 가능
  • 데이터 이중화: 데이터 사본을 하나 더 보관하세요.
  • 장애 복구: 두 시스템에 모두 데이터가 있고 한 시스템에 문제가 발생하면 다른 시스템으로 전환하여 서비스를 제공할 수 있습니다.
  • 부하 분산: 한 대의 컴퓨터는 읽기 및 쓰기를 제공하고, 슬레이브 서버는 °를 제공하여 마스터 서버의 부담을 줄입니다.
  • 고가용성의 기초: 자동 마스터-슬레이브 전환 기능이 있는 Sentinel 모드와 redis 클러터에는 모두 마스터-슬레이브 기반이 필요합니다.

마스터 서버에서 슬레이브 서버로 데이터를 복제하는 방법과 전체 복제란 무엇인가요?

복제에는 2가지 유형이 있습니다. 2.8 전체 복제

전체 복제 프로세스

1. 연결이 설정되고, 서버에서 psync ? 1 명령을 실행하고, 마스터의 런아이디와 자체 복제 오프셋 진행률이 포함되어 있으며, 둘 중 어느 것도 처음에 알려지지 않은 상태에서 ? 및 -를 전달합니다.
2. 마스터 라이브러리가 이를 수신하면 전체 동기화 런아이디 오프셋으로 응답하여 해당 런아이디와 복제 진행 상황을 알려줍니다.
3. 마스터는 bgsave를 시작하여 rdb 파일을 생성하고, 이를 슬레이브로 전송한 다음, 명령을 repl 버퍼에 저장합니다.
4. 라이브러리에서 rdb를 수신하고, 자체 데이터의 라이브러리를 지운 다음 rdb를 로드합니다.
5. 요청하지 않은 회신 버퍼 전송, 슬레이브 실행, 완료됨

증분 복제를 추가해야 하는 이유

2.8 증분 복제가 증가한 후 마스터-슬레이브 네트워크가 안정적이지 않기 때문에 연결을 끊을 때마다 전체 양의 복제를 수행하여 성능을 소비하고 실제로 일부 단계는 다시 수행 할 필요가 없으며 증분 복제 기능에서 수행해야하는 단계를 다시 추출하고 분석합니다.

그림을 보면 복제 버퍼와 repl_backlog_buffer라는 두 가지 매개 변수가 있습니다.

• repl_backlog_buffer: 슬레이브 연결이 끊어진 후 마스터-슬레이브 차이 데이터를 찾도록 설계된 링 버퍼로, 전체 복제로 인한 성능 오버헤드를 피할 수 있습니다. 슬레이브의 연결이 너무 오래 끊겨서 마스터의 쓰기 명령으로 repl_backlog_buffer 링 버퍼를 덮어쓰면 슬레이브는 마스터에 연결한 후에야 전체 복제를 수행할 수 있으므로 마스터-슬레이브 연결 해제 후 전체 복제 확률을 줄이기 위해 repl_backlog_buffer를 최대한 크게 구성합니다. 그렇다면 repl_backlog_buffer에서 마스터-슬레이브 차이를 찾은 후 데이터를 슬레이브로 전송하는 방법은 무엇일까요? 이것은 복제 버퍼를 사용합니다.
• 복제 버퍼 : Redis와 클라이언트 통신, 라이브러리 통신에서 Redis는 데이터 상호 작용을 위해 인 메모리 버퍼를 할당해야하며 클라이언트는 클라이언트이고 라이브러리에서도 클라이언트이며 각 클라이언트는 Redis에 연결되고 Redis는 클라이언트 버퍼를 할당하고 모든 데이터 상호 작용은이 버퍼를 통해 수행됩니다 : 먼저이 버퍼에 데이터를 쓴 다음 버퍼의 데이터를 클라이언트 소켓에 보낸 다음 버퍼를 통해 전송합니다. 각 클라이언트가 Redis에 연결되면 Redis는 클라이언트 버퍼를 할당하고 모든 데이터 상호 작용은 이 버퍼를 통해 수행됩니다. Redis는 먼저 이 버퍼에 데이터를 쓴 다음 버퍼에 있는 데이터를 클라이언트 소켓으로 보낸 다음 네트워크를 통해 전송하여 데이터 상호 작용을 완료합니다. 따라서 마스터와 슬레이브가 점진적으로 동기화될 때 클라이언트로서 슬레이브도 버퍼를 할당하지만, 이 버퍼는 사용자의 쓰기 명령을 슬레이브로 전파하는 데만 사용되어 마스터와 슬레이브 데이터가 일관성을 유지하며 일반적으로 복제 버퍼라고 불립니다.

repl_backlog_buffer 링 버퍼가 가득 찼을 때 수행할 작업

1. 연결 해제 시간이 너무 길면 마스터에 있는 슬레이브의 repl_backlog_buffer 및 slave_repl_offset을 덮어쓰고 전체 볼륨으로만 다시 복제할 수 있습니다.
2. 슬레이브_repl_offset은 슬레이브마다 다르며, 마스터는 전체 복제가 필요한지 여부를 자동으로 결정합니다.