Redis Advanced(2) 분산 캐시

1 독립 실행형 Redis에는 네 가지 주요 문제가 있습니다.

1.1 데이터 손실 문제

해결책	Redis 데이터 지속성 실현

지속성 : Redis 캐시는 메모리에 저장되지만 메모리는 데이터를 저장하지 않고(메모리 읽기 및 쓰기가 빠름) 디스크는 데이터를 저장하므로(더 많은 IO 상호 작용, 읽기 및 쓰기가 느림) Redis를 메모리에 저장하고 데이터를 지속적으로 저장해야 합니다. 디스크 중간에.

1.2 장애 복구 문제

해결책	Redis Sentinel을 사용하여 건강 감지 및 자동 복구 실현

1.3 동시성 문제

해결책	읽기-쓰기 분리를 달성하기 위해 마스터-슬레이브 클러스터 구축

1.4 저장 용량 문제

해결책	샤드 클러스터를 구축합니다. 슬롯 메커니즘을 사용하여 동적 확장 실현

2 데이터 손실 문제: Redis 지속성으로 RDB 및 AOF 해결

2.1 RDB 지속성

RDB(Redis 데이터베이스 백업 파일) (Redis 데이터 백업 파일): Redis数据快照. 把内存中的数据记录到磁盘中.
Redis 인스턴스가 실패하고 다시 시작되면 RDB文件디스크에서 스냅샷 파일( )을 읽고 데이터를 복원합니다. 기본적으로 현재 실행 중인 디렉터리에 저장됩니다 .

2.1.1 실행 타이밍

실행 시간	설명하다	시험
저장 명령 실행	저장 명령은 기본 프로세스가 RDB를 실행하게 하고 다른 명령은 프로세스 중에 차단됩니다.只有在数据迁移时可能用到此命令
bgsave 명령 실행	이 명령은 异步执行RDB실행 후 开启独立进程RDB를 완료 할 수 있으며 메인 프로세스는 영향을 받지 않고 사용자 요청을 계속 처리할 수 있습니다.
중단 시간	Redis가 다운되었을 때 저장 명령을 실행하여 RDB 지속성을 확보하십시오.
트리거 RDB 조건	Redis 내부에는 redis.conf 파일에서 수정할 수 있는 트리거 RDB 메커니즘이 있습니다.

2.1.2 트리거 RDB 조건 및 기타 구성

Redis에는 redis.conf 파일에서 찾을 수 있는 RDB를 트리거하는 메커니즘이 있으며 형식은 다음과 같습니다.

# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1  
save 300 10  
save 60 10000 

RDB의 다른 구성도 redis.conf 파일에서 설정할 수 있으며 형식은 다음과 같습니다.

# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes

# RDB文件名称
dbfilename dump.rdb  

# 文件保存的路径目录
dir ./ 

2.1.3 RDB의 원리

RDB 원칙: 먼저 bgsave가 시작되면 fork 메인 프로세스가 자식 프로세스를 가져오고 자식 프로세스는 메인 프로세스의 저장된 데이터를 공유합니다. 둘째, 포크가 완료된 후 메모리 데이터를 읽고 RDB 파일에 씁니다.

fork采用copy-on-write技术：

• 메인 프로세스가 읽기 작업을 수행할 때 공유 메모리에 액세스합니다.
• 메인 프로세스가 쓰기 작업을 수행하면 데이터의 복사본이 복사되고 쓰기 작업이 수행됩니다.

2.1.4 RDB 모드에서 bgsave 기본 프로세스

먼저 포크 메인 프로세스는 메모리 공간을 공유하는 프로세스를 얻습니다.두 번째는 자식 프로세스가 메모리 데이터를 읽고 새 RDB 파일에 씁니다.마지막으로 이전 RDB 파일을 새 RDB 파일로 교체합니다.

2.1.5 RDB의 단점

• RDB 실행 간격이 길다(필요하기 때문에 ) 保存一时刻redis缓存的所有快照.两次RDB之间写入数据丢失风险
• 포크 하위 프로세스, 압축 및 RDB 파일 쓰기는 시간이 많이 걸립니다.

2.2 AOF 지속성

2.2.1 AOF의 원리

AOF(Append Only File): Redis에서 처리하는 모든 쓰기 명령은 AOF 파일(명령 로그 파일)에 기록되어야 합니다.

2.2.2 AOF 구성

2.2.2.1 AOF는 기본적으로 비활성화되어 있습니다. redis.conf 구성 파일을 수정하여 AOF를 활성화하십시오.

# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"

2.2.3 AOF 명령 기록 빈도를 위한 세 가지 전략

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

2.2.4 AOF 파일 재작성

2.2.4.1 다시 작성하는 이유:

AOF 방식은 명령을 기록하기 때문에 RDB 방식으로 생성되는 파일은 훨씬 더 큽니다. **

2.2.4.2 재작성을 위한 아이디어:

예를 들어 같은 키에 대한 여러 작업의 경우 마지막 작업만 의미가 있으므로 이러한 작업에서 생성되는 불필요한 명령을 줄이는 것이 필요합니다.

2.2.4.3 구현:

AOF 파일이 다시 쓰기 기능을 수행하도록 명령을 실행 bgrewriteaof하고 가장 적은 명령으로 동일한 효과를 얻습니다.

2.2.4.4 Redis는 임계값이 트리거될 때 자동으로 AOF 파일을 다시 작성합니다. 임계값은 redis.conf에서도 구성할 수 있습니다.

# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-min-size 64mb 

2.3 RDB와 AOF의 비교

3 동시성 문제: Redis 마스터-슬레이브

3.1 Redis 마스터-슬레이브 아키텍처를 구축하는 이유

단일 노드 Redis의 동시성 기능에는 상한이 있습니다 동시성 기능을 향상시켜야 하는 경우 마스터-슬레이브 클러스터를 구축하여 읽기-쓰기 분리를 달성해야 합니다.

3.1 마스터-슬레이브 아키텍처 구축

3.2 마스터-슬레이브 데이터 동기화 원리

3.2.1 전체 동기화

마스터-슬레이브 데이터 동기화의 원리: 먼저 마스터-슬레이브가 처음으로 연결을 설정할 때 전체 동기화를 수행합니다(RDB 파일을 네트워크를 통해 슬레이브로 전송).

3.2.2 질문: 마스터는 고약이 처음으로 연결된다는 것을 어떻게 알 수 있습니까? 그리고 마스터는 이 슬레이브가 자신의 슬레이브 노드임을 어떻게 결정합니까?

답변: salve는 데이터 동기화를 수행합니다. 먼저 salve는 데이터를 마스터로 보냅니다 自己原有的replid和offset. 마스터는 슬레이브가 보낸 응답이 자신과 동일하다는 것을 발견하면 不一致이것이 全新slave완료되어야 함 을 의미합니다 全量同步. 그런 다음 슬레이브는 master자체적으로 replid和offset发送给slave정보를 저장합니다 . 앞으로 슬레이브의 레플리카는 마스터와 같을 것이고 一致슬레이브도 자신의 슬레이브 노드라고 판단할 것입니다.

즉, 마스터는 노드가 처음으로 동기화되었는지 여부를 판단합니다. 기준은 입니다 比较replid是否相同.

명사	설명하다
복제 ID(replid)(데이터 세트 태그)	동일한 ID는 동일한 데이터 세트를 나타냅니다. 각 마스터에는 고유한 회신이 있으며 슬레이브는 마스터 노드 회신을 상속합니다.
오프셋(오프셋)	repl_baklog 의 데이터가 증가 함에 따라 증가합니다 . 슬레이브가 동기화를 완료하면 현재 동기화 오프셋을 기록합니다 . 예를 들어 slave的offset小于master的offset, 슬레이브 데이터를 기술하려면 落后于master필요합니다 更新.

3.2.3 증분 동기화

4 장애 복구 문제: Redis Sentinel

5 스토리지 용량 문제: Redis 샤딩 클러스터

마스터 마스터 노드 복제에 RDB를 사용하는 이유와 AOF를 사용하지 않는 이유는 무엇입니까?

답변: 오해, 첫 번째 RDB, 다음 AOF, 즉 RDB와 AOF의 조합