기술나눔

7.11 일일 학습 체크인——초보자용 학습 Redis(6)

2024-07-12

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

7.11 일일 연구 체크인

목차:

여기에 이미지 설명을 삽입하세요.

1. 레디스 트랜잭션

트랜잭션의 개념과 ACID 속성

여기에 이미지 설명을 삽입하세요.
데이터베이스 수준 트랜잭션

데이터베이스 수준에서 트랜잭션은 모두 성공적으로 실행되거나 아무 것도 실행되지 않는 작업 집합입니다.

데이터베이스 트랜잭션의 네 가지 주요 특징

  • A: 원자성, 원자성은 모든 SQL을 원자 작업 단위로 실행합니다. 모두 실행되거나 아무것도 실행되지 않습니다.
  • C: 일관성, 거래가 완료된 후 모든 데이터의 상태는 일관성이 있습니다. 즉, 계정 A에서 100을 빼면 계정 B에 100이 추가됩니다.
  • I: 격리(Isolation), 여러 트랜잭션이 동시에 실행되는 경우 각 트랜잭션의 수정 사항은 다른 트랜잭션과 격리되어야 합니다.
  • D: 기간, 지속성, 즉 트랜잭션이 완료된 후 데이터베이스 데이터에 대한 수정 사항이 지속적으로 저장됩니다.

Redis 트랜잭션

Redis 트랜잭션은 명령 집합입니다. 트랜잭션의 모든 명령은 직렬화되고 일련의 명령은 일회성, 순차적, 배타적 방식으로 실행됩니다.

여기에 이미지 설명을 삽입하세요.

Redis 트랜잭션의 세 가지 주요 특징

  • 별도의 검역 운영 : 트랜잭션의 모든 명령이 직렬화되어 순서대로 실행됩니다. 트랜잭션이 실행되는 동안 다른 클라이언트가 보낸 명령 요청으로 인해 중단되지 않습니다.
  • 격리 수준 개념 없음: 대기열에 있는 명령은 제출될 때까지 실제로 실행되지 않습니다. 왜냐하면 트랜잭션이 제출되기 전에 실제로 명령이 실행되지 않기 때문입니다. 따라서 트랜잭션 내에서 업데이트를 확인하기 위한 "쿼리"가 없고 트랜잭션 외부에서 쿼리가 없습니다. 거래 "볼 수 없습니다".
  • 원자성을 보장하지 않음: 동일한 redis 트랜잭션에서 명령 실행에 실패하면 후속 명령은 롤백 없이 계속 실행됩니다.

Redis 트랜잭션 실행의 3단계

여기에 이미지 설명을 삽입하세요.

  • 켜다:에 의해MULTI거래를 시작하세요.
  • 팀에 합류하세요: 여러 명령을 트랜잭션에 대기열에 추가합니다. 이러한 명령은 명령을 받은 후 즉시 실행되지 않고 실행을 기다리는 트랜잭션 대기열에 배치됩니다.
  • 구현하다:의지하다EXEC이 명령은 트랜잭션을 트리거합니다.

Redis 트랜잭션의 기본 작업

여기에 이미지 설명을 삽입하세요.
멀티、실행、삭제

거래 입력Multi명령이 시작되면 입력된 명령은 명령 버퍼 대기열에 하나씩 푸시되고 다음이 완료될 때까지 실행되지 않습니다.Exec 그 후 Redis는 이전 명령 버퍼 대기열의 명령을 순서대로 실행합니다.팀 구성 과정에서 합격할 수 있습니다.discard와서 팀을 포기하세요.

예

127.0.0.1:6379> set t1 1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set id 12
QUEUED
127.0.0.1:6379(TX)> get id
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> get t1
QUEUED
127.0.0.1:6379(TX)> EXEC
1) OK
2) "12"
3) (integer) 2
4) (integer) 3
5) "3"

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20

거래 포기

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set name z3
QUEUED
127.0.0.1:6379(TX)> set age 29
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> DISCARD
OK

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

모두 함께 앉아

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set name z3
QUEUED
127.0.0.1:6379(TX)> get name
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> get t1
QUEUED
127.0.0.1:6379(TX)> set email
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379(TX)> exec
(error) EXECABORT Transaction discarded because of previous errors.

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

알아채다：
명령 세트에 잘못된 지침이 포함되어 있습니다(구문 오류입니다). 모두 연결되어 있고 모두 실패합니다.

모든 불의에는 주인이 있고, 모든 빚에는 주인이 있습니다.

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set age 11
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> set email [email protected]
QUEUED
127.0.0.1:6379(TX)> incr email
QUEUED
127.0.0.1:6379(TX)> get age
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) (integer) 5
3) OK
4) (error) ERR value is not an integer or out of range
5) "11"

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18

알아채다：
런타임 오류, 즉 비문법적 오류의 경우 올바른 명령이 실행되고 잘못된 명령은 오류를 반환합니다.

2. 레디스 클러스터

마스터-슬레이브 복제

여기에 이미지 설명을 삽입하세요.
개요
기존 기업 중 80%의 기업이 대부분 Redis 독립형 서비스를 사용하고 있습니다. 실제 시나리오에서 단일 노드의 Redis는 위험에 노출되기 쉽습니다.

문제에 직면하다:

  • 기계 오작동. Redis 서버에 배포하면 머신 오류가 발생하면 다른 서버로 마이그레이션하여 데이터가 동기화되는지 확인해야 합니다.
  • 용량 병목 현상. Redis 메모리를 16G 메모리에서 64G로 확장해야 할 때 단일 시스템으로는 이를 만족시킬 수 없습니다. 물론 새로운 128G 머신을 구입할 수도 있습니다.

해결책

분산 데이터베이스의 더 큰 저장 용량을 달성하고 높은 동시 액세스를 견딜 수 있도록 원래 중앙 집중식 데이터베이스의 데이터를 여러 다른 네트워크 노드에 저장합니다.

알아채다：
이 단일 노드 문제를 해결하기 위해 Redis는 Redis의 고가용성을 달성하기 위해 복제를 위해 여러 데이터 복사본을 다른 노드에 배포하고 데이터의 중복 백업을 통해 데이터 및 서비스의 고가용성을 보장합니다.

마스터-슬레이브 복제란 무엇입니까?

마스터-슬레이브 복제는 하나의 Redis 서버에서 다른 Redis 서버로 데이터를 복사하는 것을 의미합니다. 전자를 마스터 노드, 후자를 슬레이브 노드라고 합니다. 데이터 복제는 단방향이며 마스터 노드에서 슬레이브 노드로만 가능합니다.

여기에 이미지 설명을 삽입하세요.
마스터-슬레이브 복제의 역할

  • 데이터 중복성: 마스터-슬레이브 복제는 지속성 외에 데이터 이중화 방식인 데이터의 핫 백업을 구현합니다.
  • 회복: 마스터 노드에 문제가 발생하면 슬레이브 노드는 신속한 장애 복구를 위해 서비스를 제공할 수 있습니다. 이는 실제로 일종의 서비스 중복입니다.
  • 로드 밸런싱: 마스터-슬레이브 복제를 기반으로 읽기와 쓰기가 분리되어 마스터 노드는 쓰기 서비스를 제공하고 슬레이브 노드는 읽기 서비스를 제공할 수 있습니다(즉, Redis 데이터를 쓸 때 애플리케이션은 마스터 노드에 연결되어야 함) 그리고 Redis 데이터를 읽을 때 애플리케이션은 슬레이브 노드에 연결해야 합니다. 특히 쓰기가 적고 읽기가 많은 시나리오에서 여러 슬레이브 노드를 통해 읽기 로드를 공유하면 Redis 서버의 동시성이 크게 증가할 수 있습니다. .
  • 고가용성 초석: 위의 기능 외에도 마스터-슬레이브 복제는 센티널 및 클러스터 구현의 기반이기도 합니다. 따라서 마스터-슬레이브 복제는 Redis 고가용성을 위한 기반입니다.

마스터-슬레이브 복제 환경 설정

여기에 이미지 설명을 삽입하세요.
구성 파일 쓰기
새로운 redis6379.conf 생성

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb

  • 1
  • 2
  • 3
  • 4

새로운 redis6380.conf 생성

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb

  • 1
  • 2
  • 3
  • 4

새로운 redis6381.conf 생성

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb

  • 1
  • 2
  • 3
  • 4

세 개의 Redis 서버 시작

./redis-server ../redis6379.conf
./redis-server ../redis6380.conf
./redis-server ../redis6381.conf

  • 1
  • 2
  • 3

시스템 프로세스 보기

[root@localhost src]# ps -ef |grep redis
root    40737    1  0 22:05 ?     00:00:00 ./redis-server *:6379
root    40743    1  0 22:05 ?     00:00:00 ./redis-server *:6380
root    40750    1  0 22:05 ?     00:00:00 ./redis-server *:6381
root    40758  40631  0 22:05 pts/0   00:00:00 grep --color=auto redis

  • 1
  • 2
  • 3
  • 4
  • 5

세 호스트의 실행 상태 확인

#打印主从复制的相关信息
./redis-cli -p 6379
./redis-cli -p 6380
./redis-cli -p 6381
127.0.0.1:6379> info replication
127.0.0.1:6380> info replication
127.0.0.1:6381> info replication

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

슬레이브 데이터베이스는 장착되어 있지만 마스터 데이터베이스는 장착되어 있지 않습니다.

구문 형식:

slaveof  <ip> <port>

  • 1

예:

6380 및 6381에서 실행됩니다.

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK

  • 1
  • 2

호스트에 쓰고 슬레이브에서 데이터를 읽습니다.

set k1 v1

  • 1

마스터-슬레이브 복제 원리 분석

여기에 이미지 설명을 삽입하세요.
마스터-슬레이브 복제는 3단계로 나눌 수 있습니다.

  • 연결 설정 단계(즉, 준비 단계)
  • 데이터 동기화 단계
  • 명령 전파 단계

복사 과정은 대략 6가지 과정으로 나누어집니다.

여기에 이미지 설명을 삽입하세요.

  1. 마스터 노드(마스터) 정보를 저장합니다.
    Slaveof 실행 후 상태 정보 보기
info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  1. 슬레이브 노드(slave)는 1초마다 실행되는 예약된 작업을 통해 복제 관련 로직을 유지합니다. 예약된 작업이 새로운 마스터 노드가 있음을 발견하면 해당 노드와 네트워크 연결을 시도합니다.
    여기에 이미지 설명을 삽입하세요.
  2. 슬레이브 노드와 마스터 노드 간의 네트워크 연결 설정
    슬레이브 노드는 소켓을 설정합니다. 슬레이브 노드는 특히 마스터 노드가 보낸 복제 명령을 수락하는 데 사용되는 포트 51234를 사용하여 소켓을 설정합니다.

여기에 이미지 설명을 삽입하세요.
4. ping 명령 보내기

연결이 성공적으로 설정된 후 슬레이브 노드는 첫 번째 통신에 대한 ping 요청을 보냅니다.

여기에 이미지 설명을 삽입하세요.

효과:

  • 마스터와 슬레이브 사이의 네트워크 소켓이 사용 가능한지 여부를 감지합니다.
  • 마스터 노드가 현재 명령을 수락할 수 있는지 여부를 감지합니다.

  1. ASD.
    requirepass 매개변수가 마스터 노드에 설정된 경우, 슬레이브 노드는 비밀번호가 마스터 노드와 동일한지 확인하기 위해 비밀번호 확인이 필요합니다. 확인에 실패하면 복제가 수행됩니다. 종료되고 슬레이브 노드는 복제 프로세스를 다시 시작합니다.

  2. 데이터세트를 동기화합니다.
    마스터-슬레이브 복제 연결이 정상적으로 통신된 후 처음으로 복제가 설정되면 마스터 노드는 보유하고 있는 모든 데이터를 슬레이브 노드로 전송합니다. 이 부분은 작업 중 가장 긴 단계입니다.
    여기에 이미지 설명을 삽입하세요.

마스터-슬레이브 동기화 전략

마스터와 슬레이브가 방금 연결된 경우에는 전체 동기화가 완료된 후 증분 동기화가 수행됩니다. 물론, 필요한 경우 슬레이브는 언제든지 전체 동기화를 시작할 수 있습니다. Redis 전략은 무슨 일이 있어도 증분 동기화를 먼저 시도하고, 실패할 경우 슬레이브 머신에서 전체 동기화를 수행해야 한다는 것입니다.

예를 들어

캐시를 저장하다

set name jjy

  • 1

녹음 명령은

$3 r n
set r n
$4 r n
name r n
$5  r n
jjy r n

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
오프셋100010011002100310041005100610071008
바이트 값$3아르 자형N$4Nㅏ중

7. 명령이 계속해서 복사됩니다.
마스터 노드가 현재 데이터를 슬레이브 노드에 동기화하면 복제 설정 과정이 완료됩니다. 다음으로, 마스터 노드는 마스터-슬레이브 데이터 일관성을 보장하기 위해 슬레이브 노드에 지속적으로 쓰기 명령을 보냅니다.

센티넬 모니터링

여기에 이미지 설명을 삽입하세요.
Redis 마스터-슬레이브 복제의 단점

호스트 마스터가 다운되면 스위치를 수동으로 해결해야 합니다.

여기에 이미지 설명을 삽입하세요.

노출 문제:
마스터 노드가 다운되어 쓰기 서비스를 사용할 수 없게 되면 수동으로 전환하여 마스터 노드를 다시 선택하고 마스터-슬레이브 관계를 수동으로 설정해야 합니다.

마스터-슬레이브 스위칭 기술

마스터 서버가 다운되면 슬레이브 서버를 마스터 서버로 수동 전환해야 하는데, 이는 수동 개입이 필요하고 시간이 많이 걸리고 노동 집약적이며 일정 기간 동안 서비스를 사용할 수 없게 됩니다.이는 권장되는 접근 방식이 아니며 더 자주 다음 사항에 우선순위를 둡니다.감시 모드。

센티넬 개요

Sentinel 모드는 특별한 모드입니다. 먼저 Redis는 sentinel 명령을 제공하며 독립적인 프로세스입니다. 원칙은 센티널이 명령을 보내고 Redis 서버의 응답을 기다리는 방식으로 실행 중인 여러 Redis 인스턴스를 모니터링한다는 것입니다.

여기에 이미지 설명을 삽입하세요.
센티넬 역할

  • 클러스터 모니터링: Redis 마스터와 슬레이브 프로세스가 제대로 작동하는지 모니터링하는 역할을 담당합니다.
  • 공고: Redis 인스턴스가 실패하면 Sentinel은 관리자에게 경보 알림 메시지를 보내는 역할을 담당합니다.
  • 장애 조치: 마스터 노드가 끊기면 자동으로 슬레이브 노드로 전환됩니다.
  • 구성 센터: 장애 조치가 발생하면 클라이언트에 새 마스터 주소를 알립니다.

Sentinel 모니터링 환경 구축

여기에 이미지 설명을 삽입하세요.

새 sentinel-26379.conf 파일을 생성합니다.

#端口
port 26379
#守护进程运行
daemonize yes
#日志文件
logfile "26379.log"
sentinel monitor mymaster localhost 6379 2

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

매개변수:
sentinel monitor mymaster 192.168.92.128 6379 2 구성의 의미는 sentinel 노드가 마스터 노드 192.168.92.128:6379를 모니터링한다는 것입니다. 마스터 노드의 이름은 mymaster입니다. 마스터 노드: 최소 2개가 필요합니다. 두 개의 센티넬 노드가 동의한 경우에만 마스터 노드의 장애를 판단하고 장애 조치를 수행할 수 있습니다.

새로운 sentinel-26380.conf 파일을 생성합니다.

#端口
port 26380
#守护进程运行
daemonize yes
#日志文件
logfile "26380.log"
sentinel monitor mymaster localhost 6379 2

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

새 sentinel-26381.conf 파일을 생성합니다.

#端口
port 26381
#守护进程运行
daemonize yes
#日志文件
logfile "26381.log"
sentinel monitor mymaster localhost 6379 2

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

센티넬 노드 시작

redis-sentinel sentinel-26379.conf

  • 1

센티넬 노드 상태 보기

[root@localhost src]# ./redis-cli -p 26379
127.0.0.1:26379> 
127.0.0.1:26379> 
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.66.100:6379,slaves=2,sentinels=3

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

Sentinel의 작동 원리 분석

여기에 이미지 설명을 삽입하세요.
모니터링 단계
여기에 이미지 설명을 삽입하세요.

알아채다:

  • sentinel(sentinel 1)------&gt;마스터(master)와 슬레이브(slave)에 정보를 시작하고 전체 정보를 얻습니다.
  • 센티넬(sentinel 2)------&gt;마스터(master)에 정보를 시작하면 기존 센티넬(sentinel 1)의 정보를 알고 슬레이브(slave)에 연결하게 됩니다.
  • sentinel (sentinel 2) -----&gt; sentinel (sentinel 1) 구독을 시작합니다.

알림 단계

Sentinel은 정보를 수집하기 위해 마스터와 슬레이브에 지속적으로 알림을 보냅니다.

장애 조치 단계

알림 단계에서 센티널이 보낸 알림이 마스터로부터 응답을 받지 못하면 마스터를 SRI_S_DOWN으로 표시하고 마스터의 상태를 각 센티널에 보냅니다. 저도 확인해서 보내겠습니다. 결과는 각 센티널과 공유됩니다. 센티널 중 절반이 마스터가 다운되었다고 생각하면 마스터를 SRI_0_DOWN으로 표시합니다.
여기에 이미지 설명을 삽입하세요.
질문은 다음과 같습니다.

이때 마스터는 누가 교체되어야 할까요?

투표 방법

방법:

내가 먼저 선거 통지를 받은 파수꾼이 누구에게든 투표할 것입니다.

일부 사례를 제거합니다.

  • 온라인이 아님
  • 느린 응답
  • 오랫동안 원래 마스터와의 연결이 끊어졌습니다.
  • 우선 원칙

장애 조치

여기에 이미지 설명을 삽입하세요.
개요
마스터 노드 장애 시 Sentinel의 모니터링 및 자동 장애 조치 기능을 보여줍니다.

장애 조치 시연
kill 명령을 사용하여 마스터 노드를 종료합니다.

ps aux |grep redis
kill -9 pid

  • 1
  • 2

센티넬 노드 정보 보기

Sentinel 노드에서 info Sentinel 명령을 사용하여 즉시 확인하면 됩니다.

[root@localhost src]# ./redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6381,slaves=5,sentinels=3

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

알아채다：
센티넬이 마스터 노드의 장애를 감지하고 이를 전송하는 데 시간이 걸리기 때문에 마스터 노드가 전환되지 않은 것을 알 수 있습니다.

노드 6379 다시 시작

[root@localhost src]# ./redis-cli info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:down

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

구성 파일이 다시 작성됩니다.
장애 조치 단계에서는 센티널 및 마스터-슬레이브 노드의 구성 파일이 다시 작성됩니다.

include /usr/local/redis/redis.conf
pidfile "/var/run/redis_6379.pid"
port 6379
dbfilename "dump6379.rdb"
# Generated by CONFIG REWRITE
daemonize yes
protected-mode no
appendonly yes
slowlog-max-len 1200
slowlog-log-slower-than 1000
save 5 1
user default on nopass ~* &* +@all
dir "/usr/local/redis"
replicaof 127.0.0.1 6381

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

결론적으로

  • Sentinel 시스템의 마스터-슬레이브 노드는 일반 마스터-슬레이브 노드와 다르지 않으며 오류 발견 및 전송은 Sentinel에 의해 제어되고 완료됩니다.
  • Sentinel 노드는 기본적으로 Redis 노드입니다.
  • 각 센티널 노드는 다른 센티널 노드와 슬레이브 노드를 자동으로 검색하도록 모니터링 마스터 노드만 구성하면 됩니다.
  • Sentinel 노드 시작 및 장애 조치 단계 중에 각 노드의 구성 파일이 다시 작성됩니다(config rewrite).

클러스터 모드

Redis에는 세 가지 클러스터 모드가 있습니다.

  • 마스터-슬레이브 모드
  • 센티넬 모드
  • 클러스터 모드

센트리 모드의 단점
여기에 이미지 설명을 삽입하세요.
결점：

  • 마스터가 전화를 끊으면 Sentinel은 마스터를 선출합니다. 선출 중에는 Redis에 액세스할 수 없으며 액세스가 일시적으로 중단됩니다.
  • 센트리 모드에서는 마스터 노드만 외부에서 쓸 수 있고, 슬레이브 노드는 읽기에만 사용할 수 있습니다. 단일 Redis 노드는 최대 10W QPS를 지원하지만 전자 상거래 프로모션 중에 데이터 쓰기에 대한 모든 부담은 마스터에 있습니다.
  • Redis의 단일 노드 메모리는 너무 크게 설정할 수 없습니다. 데이터가 너무 크면 노드가 시작될 때 마스터-슬레이브 동기화가 매우 느려지고 시간이 오래 걸립니다.

클러스터 모드 개요
여기에 이미지 설명을 삽입하세요.
Redis 클러스터는 여러 개의 마스터-슬레이브 노드 그룹으로 구성된 분산 서비스 클러스터로 복제, 고가용성 및 샤딩 기능을 갖추고 있습니다.

Redis 클러스터의 장점

  • Redis 클러스터에는 일시적인 액세스 문제의 영향을 줄일 수 있는 여러 마스터가 있습니다.
  • Redis 클러스터에는 더 높은 동시성을 제공할 수 있는 여러 마스터가 있습니다.
  • 더 많은 데이터를 저장할 수 있도록 Redis 클러스터를 샤드에 저장할 수 있습니다.

클러스터 모드 구축

Redis 클러스터를 구성하려면 최소 3개의 마스터 노드가 필요합니다. 여기에는 각각 슬레이브 노드가 포함되어 총 6개의 Redis 노드가 있습니다.
여기에 이미지 설명을 삽입하세요.
클러스터 구축

각각 포트 번호 6379, 6380, 6381, 6382, 6383 및 6384를 사용하여 6개의 서로 다른 Redis 노드를 만듭니다.

알아채다: dump.rdb,appendonly.aof 파일을 삭제한 후 복사해야 합니다.

1. 새 구성 파일 생성
redis6379.config, redis6380.config, redis6381.config, redis6382.config, redis6383.config, redis6384.config 파일을 생성합니다. 구성 파일의 포트 번호가 파일 포트 번호와 일치하도록 수정합니다.

daemonize yes
dir /usr/local/redis-7.2.4/redis-cluster/6382/
bind 192.168.47.100
port 6382
dbfilename dump6382.rdb
cluster-enabled yes
cluster-config-file nodes-6382.conf
cluster-node-timeout 5000
appendonly yes
protected-mode no

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

매개변수：

  • Cluster-config-file: 위에서 구성한 dir 디렉터리에 다른 노드의 상태, 지속성 변수 등이 포함된 클러스터 지속성 구성 파일이 자동으로 생성됩니다. 각 노드는 작동 중에 클러스터 구성 파일을 유지합니다. 클러스터 정보가 변경될 때마다(예: 노드 추가 또는 제거) 클러스터의 모든 노드는 노드가 다시 시작될 때 구성 파일에 대한 최신 정보를 업데이트합니다. 구성 파일을 사용하여 클러스터 정보를 얻으면 쉽게 클러스터에 다시 참여할 수 있습니다. 클러스터 구성 파일은 Redis에 의해 유지 관리되며 수동 수정이 필요하지 않습니다.
  • Cluster-enabled: 클러스터를 활성화합니다.

폴더 생성

mkdir -p /usr/local/redis-7.2.4/redis-cluster/6379/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6380/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6381/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6382/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6383/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6384/

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

6개 노드 시작

[root@bogon src]# ./redis-server ../redis6379.config
[root@bogon src]# ./redis-server ../redis6380.config
[root@bogon src]# ./redis-server ../redis6381.config
[root@bogon src]# ./redis-server ../redis6382.config
[root@bogon src]# ./redis-server ../redis6383.config
[root@bogon src]# ./redis-server ../redis6384.config

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

각 노드가 성공적으로 시작되는지 확인

[root@bogon src]# ps -ef | grep redis
root    3889    1 0 09:56 ?    00:00:03 ./redis-server 0.0.0.0:6379 [cluster]
root    3895    1 0 09:56 ?    00:00:03 ./redis-server 0.0.0.0:6380 [cluster]
root    3901    1 0 09:57 ?    00:00:03 ./redis-server 0.0.0.0:6381 [cluster]
root    3907    1 0 09:57 ?    00:00:02 ./redis-server *:6382 [cluster]
root    3913    1 0 09:57 ?    00:00:02 ./redis-server 0.0.0.0:6383 [cluster]
root    3919    1 0 09:57 ?    00:00:02 ./redis-server 0.0.0.0:6384 [cluster]
root    4247  2418 0 10:22 pts/0  00:00:00 grep --color=auto redis

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

클러스터 구성

명령 형식: --cluster-replicas 1은 각 마스터에 대한 슬레이브 노드를 생성하는 것을 의미합니다.

알아채다: 여기서 IP는 각 노드가 위치한 머신의 실제 IP입니다.

[root@localhost src]# ./redis-cli --cluster create 192.168.47.100:6379 192.168.47.100:6380 192.168.47.100:6381 192.168.47.100:6382 192.168.47.100:6383 192.168.47.100:6384 --cluster-replicas 1

  • 1

여기에 이미지 설명을 삽입하세요.

클러스터 확인

모든 클라이언트에 연결

./redis-cli -h 192.168.47.100  -p 6379 -c

  • 1

매개변수:

‐h : 호스트 주소
-p : 포트 번호
‐c: 클러스터 모드를 나타냅니다.

데이터 쓰기 테스트

[root@bogon src]# ./redis-cli -p 6379 -c
127.0.0.1:6379> set name zhangsan
-> Redirected to slot [5798] located at 192.168.47.100:6380
OK
192.168.47.100:6380> get name
"zhangsan"
192.168.47.100:6380>
[root@bogon src]# ./redis-cli -p 6383 -c
127.0.0.1:6383> get name
-> Redirected to slot [5798] located at 192.168.47.100:6380
"zhangsan"
192.168.47.100:6380>
[root@bogon src]# ./redis-cli -p 6383 -c
127.0.0.1:6383> readonly
OK
127.0.0.1:6383> get name
"zhangsan"
127.0.0.1:6383>

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18

클러스터 패턴 원리 분석

레디스 클러스터 모든 데이터는 16384개의 슬롯(slot)으로 나누어지며, 각 노드는 슬롯의 일부를 담당합니다. 슬롯 정보는 각 노드에 저장됩니다. 마스터 노드에만 슬롯이 할당되고, 슬레이브 노드에는 슬롯이 할당되지 않습니다.

여기에 이미지 설명을 삽입하세요.

슬롯 포지셔닝 알고리즘： k1 = 127001

기본적으로 클러스터는 crc16 알고리즘을 사용하여 키 값을 해시하여 정수 값을 얻은 다음 이 정수 값을 모듈로 16384로 사용하여 특정 슬롯을 얻습니다.

해시 슬롯 = CRC16(키) % 16384

회복
노드 보기

192.168.66.103:8001> cluster nodes

  • 1

마스터 노드를 죽여라

lsof -i:8001
kill -9 pid

  • 1
  • 2

노드 정보 관찰

여기에 이미지 설명을 삽입하세요.

Java 운영 Redis 클러스터

여기에 이미지 설명을 삽입하세요.
구성 파일 수정

spring.data.redis.cluster.nodes=192.168.47.100:6381,192.168.47.100:6383,192.168.47.100:6380

  • 1

알아채다
1. Redis 클러스터에는 고가용성을 보장하기 위해 최소 3개의 노드가 필요합니다.
2. Redis 클러스터가 실행되는 동안에는 노드를 추가하거나 삭제하지 않도록 해야 합니다. 이로 인해 데이터 마이그레이션이 발생하여 Redis 클러스터의 전체 성능에 영향을 미칠 수 있기 때문입니다.

Java로 작성된 코드

@SpringBootTest
public class CluseterTest {

  @Autowired
  private RedisTemplate<String,Object> redisTemplate;

  @Test
  void string() {
    //  保存字符串
    redisTemplate.opsForValue().set("itbaizhan","itbaizhan123");

    System.out.println(redisTemplate.opsForValue().get("itbaizhan"));

   }
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15

제 내용이 도움이 되셨다면 좋아요 부탁드립니다좋아요, 댓글, 즐겨찾기 .만들기는 쉽지 않은데, 모두의 응원이 나를 지탱해주는 힘이에요
여기에 이미지 설명을 삽입하세요.

개인 프로필

그는 30년 이상 기술 연구에 전념해 왔으며, java, linux, javascript, php, css 등 다양한 언어에 능숙하며, 오픈 소스 분야에 많은 공헌을 했습니다. 나중에 참조할 수 있도록 기술 개발의 일부 문제를 공유하는 개발자 문서 스테이션입니다.

내 연락처 정보

우편