내 연락처 정보
우편메소피아@프로톤메일.com
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
데이터베이스 수준 트랜잭션
데이터베이스 수준에서 트랜잭션은 모두 성공적으로 실행되거나 아무 것도 실행되지 않는 작업 집합입니다.
데이터베이스 트랜잭션의 네 가지 주요 특징
Redis 트랜잭션
Redis 트랜잭션은 명령 집합입니다. 트랜잭션의 모든 명령은 직렬화되고 일련의 명령은 일회성, 순차적, 배타적 방식으로 실행됩니다.
MULTI
거래를 시작하세요.EXEC
이 명령은 트랜잭션을 트리거합니다.
멀티、실행、삭제
거래 입력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"
거래 포기
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
모두 함께 앉아
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.
알아채다:
명령 세트에 잘못된 지침이 포함되어 있습니다(구문 오류입니다). 모두 연결되어 있고 모두 실패합니다.
모든 불의에는 주인이 있고, 모든 빚에는 주인이 있습니다.
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"
알아채다:
런타임 오류, 즉 비문법적 오류의 경우 올바른 명령이 실행되고 잘못된 명령은 오류를 반환합니다.
개요
기존 기업 중 80%의 기업이 대부분 Redis 독립형 서비스를 사용하고 있습니다. 실제 시나리오에서 단일 노드의 Redis는 위험에 노출되기 쉽습니다.
문제에 직면하다:
- 기계 오작동. Redis 서버에 배포하면 머신 오류가 발생하면 다른 서버로 마이그레이션하여 데이터가 동기화되는지 확인해야 합니다.
- 용량 병목 현상. Redis 메모리를 16G 메모리에서 64G로 확장해야 할 때 단일 시스템으로는 이를 만족시킬 수 없습니다. 물론 새로운 128G 머신을 구입할 수도 있습니다.
해결책
분산 데이터베이스의 더 큰 저장 용량을 달성하고 높은 동시 액세스를 견딜 수 있도록 원래 중앙 집중식 데이터베이스의 데이터를 여러 다른 네트워크 노드에 저장합니다.
알아채다:
이 단일 노드 문제를 해결하기 위해 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
새로운 redis6380.conf 생성
include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
새로운 redis6381.conf 생성
include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb
세 개의 Redis 서버 시작
./redis-server ../redis6379.conf
./redis-server ../redis6380.conf
./redis-server ../redis6381.conf
시스템 프로세스 보기
[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
세 호스트의 실행 상태 확인
#打印主从复制的相关信息
./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
슬레이브 데이터베이스는 장착되어 있지만 마스터 데이터베이스는 장착되어 있지 않습니다.
구문 형식:
slaveof <ip> <port>
예:
6380 및 6381에서 실행됩니다.
127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
호스트에 쓰고 슬레이브에서 데이터를 읽습니다.
set k1 v1
마스터-슬레이브 복제는 3단계로 나눌 수 있습니다.
복사 과정은 대략 6가지 과정으로 나누어집니다.
info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
4. ping 명령 보내기
연결이 성공적으로 설정된 후 슬레이브 노드는 첫 번째 통신에 대한 ping 요청을 보냅니다.
효과:
- 마스터와 슬레이브 사이의 네트워크 소켓이 사용 가능한지 여부를 감지합니다.
- 마스터 노드가 현재 명령을 수락할 수 있는지 여부를 감지합니다.
ASD.
requirepass 매개변수가 마스터 노드에 설정된 경우, 슬레이브 노드는 비밀번호가 마스터 노드와 동일한지 확인하기 위해 비밀번호 확인이 필요합니다. 확인에 실패하면 복제가 수행됩니다. 종료되고 슬레이브 노드는 복제 프로세스를 다시 시작합니다.
데이터세트를 동기화합니다.
마스터-슬레이브 복제 연결이 정상적으로 통신된 후 처음으로 복제가 설정되면 마스터 노드는 보유하고 있는 모든 데이터를 슬레이브 노드로 전송합니다. 이 부분은 작업 중 가장 긴 단계입니다.
마스터-슬레이브 동기화 전략
마스터와 슬레이브가 방금 연결된 경우에는 전체 동기화가 완료된 후 증분 동기화가 수행됩니다. 물론, 필요한 경우 슬레이브는 언제든지 전체 동기화를 시작할 수 있습니다. Redis 전략은 무슨 일이 있어도 증분 동기화를 먼저 시도하고, 실패할 경우 슬레이브 머신에서 전체 동기화를 수행해야 한다는 것입니다.
예를 들어
캐시를 저장하다
set name jjy
녹음 명령은
$3 r n
set r n
$4 r n
name r n
$5 r n
jjy r n
오프셋 | 1000 | 1001 | 1002 | 1003 | 1004 | 1005 | 1006 | 1007 | 1008 |
---|---|---|---|---|---|---|---|---|---|
바이트 값 | $ | 3 | 아르 자형 | N | $ | 4 | N | ㅏ | 중 |
7. 명령이 계속해서 복사됩니다.
마스터 노드가 현재 데이터를 슬레이브 노드에 동기화하면 복제 설정 과정이 완료됩니다. 다음으로, 마스터 노드는 마스터-슬레이브 데이터 일관성을 보장하기 위해 슬레이브 노드에 지속적으로 쓰기 명령을 보냅니다.
Redis 마스터-슬레이브 복제의 단점
호스트 마스터가 다운되면 스위치를 수동으로 해결해야 합니다.
노출 문제:
마스터 노드가 다운되어 쓰기 서비스를 사용할 수 없게 되면 수동으로 전환하여 마스터 노드를 다시 선택하고 마스터-슬레이브 관계를 수동으로 설정해야 합니다.
마스터-슬레이브 스위칭 기술
마스터 서버가 다운되면 슬레이브 서버를 마스터 서버로 수동 전환해야 하는데, 이는 수동 개입이 필요하고 시간이 많이 걸리고 노동 집약적이며 일정 기간 동안 서비스를 사용할 수 없게 됩니다.이는 권장되는 접근 방식이 아니며 더 자주 다음 사항에 우선순위를 둡니다.감시 모드。
센티넬 개요
Sentinel 모드는 특별한 모드입니다. 먼저 Redis는 sentinel 명령을 제공하며 독립적인 프로세스입니다. 원칙은 센티널이 명령을 보내고 Redis 서버의 응답을 기다리는 방식으로 실행 중인 여러 Redis 인스턴스를 모니터링한다는 것입니다.
센티넬 역할
새 sentinel-26379.conf 파일을 생성합니다.
#端口
port 26379
#守护进程运行
daemonize yes
#日志文件
logfile "26379.log"
sentinel monitor mymaster localhost 6379 2
매개변수:
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
새 sentinel-26381.conf 파일을 생성합니다.
#端口
port 26381
#守护进程运行
daemonize yes
#日志文件
logfile "26381.log"
sentinel monitor mymaster localhost 6379 2
센티넬 노드 시작
redis-sentinel sentinel-26379.conf
센티넬 노드 상태 보기
[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
모니터링 단계
알아채다:
- sentinel(sentinel 1)------>마스터(master)와 슬레이브(slave)에 정보를 시작하고 전체 정보를 얻습니다.
- 센티넬(sentinel 2)------>마스터(master)에 정보를 시작하면 기존 센티넬(sentinel 1)의 정보를 알고 슬레이브(slave)에 연결하게 됩니다.
- sentinel (sentinel 2) -----> sentinel (sentinel 1) 구독을 시작합니다.
알림 단계
Sentinel은 정보를 수집하기 위해 마스터와 슬레이브에 지속적으로 알림을 보냅니다.
장애 조치 단계
알림 단계에서 센티널이 보낸 알림이 마스터로부터 응답을 받지 못하면 마스터를 SRI_S_DOWN으로 표시하고 마스터의 상태를 각 센티널에 보냅니다. 저도 확인해서 보내겠습니다. 결과는 각 센티널과 공유됩니다. 센티널 중 절반이 마스터가 다운되었다고 생각하면 마스터를 SRI_0_DOWN으로 표시합니다.
질문은 다음과 같습니다.
이때 마스터는 누가 교체되어야 할까요?
투표 방법
방법:
내가 먼저 선거 통지를 받은 파수꾼이 누구에게든 투표할 것입니다.
일부 사례를 제거합니다.
개요
마스터 노드 장애 시 Sentinel의 모니터링 및 자동 장애 조치 기능을 보여줍니다.
장애 조치 시연
kill 명령을 사용하여 마스터 노드를 종료합니다.
ps aux |grep redis
kill -9 pid
센티넬 노드 정보 보기
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
알아채다:
센티넬이 마스터 노드의 장애를 감지하고 이를 전송하는 데 시간이 걸리기 때문에 마스터 노드가 전환되지 않은 것을 알 수 있습니다.
노드 6379 다시 시작
[root@localhost src]# ./redis-cli info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:down
구성 파일이 다시 작성됩니다.
장애 조치 단계에서는 센티널 및 마스터-슬레이브 노드의 구성 파일이 다시 작성됩니다.
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
결론적으로
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
매개변수:
- 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/
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
각 노드가 성공적으로 시작되는지 확인
[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
클러스터 구성
명령 형식: --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
클러스터 확인
모든 클라이언트에 연결
./redis-cli -h 192.168.47.100 -p 6379 -c
매개변수:
‐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>
레디스 클러스터 모든 데이터는 16384개의 슬롯(slot)으로 나누어지며, 각 노드는 슬롯의 일부를 담당합니다. 슬롯 정보는 각 노드에 저장됩니다. 마스터 노드에만 슬롯이 할당되고, 슬레이브 노드에는 슬롯이 할당되지 않습니다.
슬롯 포지셔닝 알고리즘: k1 = 127001
기본적으로 클러스터는 crc16 알고리즘을 사용하여 키 값을 해시하여 정수 값을 얻은 다음 이 정수 값을 모듈로 16384로 사용하여 특정 슬롯을 얻습니다.
해시 슬롯 = CRC16(키) % 16384
회복
노드 보기
192.168.66.103:8001> cluster nodes
마스터 노드를 죽여라
lsof -i:8001
kill -9 pid
노드 정보 관찰
구성 파일 수정
spring.data.redis.cluster.nodes=192.168.47.100:6381,192.168.47.100:6383,192.168.47.100:6380
알아채다
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"));
}
}
제 내용이 도움이 되셨다면 좋아요 부탁드립니다좋아요, 댓글, 즐겨찾기 .만들기는 쉽지 않은데, 모두의 응원이 나를 지탱해주는 힘이에요