Redis에서 고가용성 및 지속성을 구성하는 방법-Redis-php.cn

Redis에서 고가용성 및 지속성을 구성하는 방법

1. Redis 고가용성

1. Redis 고가용성 개요

웹 서버에서 고가용성은 서버에 정상적으로 접속할 수 있는 시간을 말하며, 그 측정기준은 얼마만큼 정상적인 서비스를 제공할 수 있는지를 기준으로 합니다. (99.9%, 99.99%, 99.999% 등). [관련 추천 : Redis 영상 튜토리얼]

그러나 Redis의 맥락에서 고가용성의 의미는 정상적인 서비스 제공(마스터-슬레이브 분리, 빠른 재해 복구 기술 등)을 보장하는 것보다 더 넓은 의미로 보입니다. , 데이터 용량 확장도 고려해야하며, 데이터 보안이 유지됩니다.

2. Redis 고가용성 전략

Redis에서 고가용성을 달성하기 위한 기술에는 주로 지속성, 마스터-슬레이브 분리, 센티널 및 클러스터가 포함됩니다.

고가용성 전략	설명
Persistence	Persistence은 가장 간단한 고가용성 방법입니다(때때로 고가용성 방법으로 분류되지도 않음). 주요 기능은 데이터 백업입니다. 곧 데이터가 저장됩니다. 프로세스가 종료될 때 데이터가 손실되지 않도록 하드 디스크에 저장합니다.
마스터-슬레이브 복제	마스터-슬레이브 복제는 고가용성 Redis의 기반입니다. Sentinel과 Cluster 모두 마스터-슬레이브 복제를 기반으로 고가용성을 달성합니다. 마스터-슬레이브 복제는 주로 데이터의 다중 시스템 백업은 물론 읽기 작업을 위한 로드 밸런싱 및 간단한 오류 복구를 구현합니다. 결함: 장애 복구를 자동화할 수 없고, 쓰기 작업의 로드 밸런싱을 수행할 수 없으며, 저장 용량이 단일 시스템으로 제한됩니다.
Sentinel	Sentinel은 마스터-슬레이브 복제를 기반으로 자동화된 오류 복구를 구현합니다. 단점: 쓰기 작업은 로드 밸런싱될 수 없으며 저장 용량은 단일 시스템으로 제한됩니다.
Cluster	Redis는 쓰기 작업의 로드 밸런싱이 불가능하고 저장 용량이 단일 머신으로 제한되는 문제를 클러스터링을 통해 해결하여 비교적 완전한 고가용성 솔루션을 구현합니다.

2. Redis 지속성

1. Redis 지속성 기능

Redis는 메모리 내 데이터베이스로, 서버 정전 등으로 인해 Redis 프로세스가 비정상적으로 종료된 후 데이터가 영구적으로 손실되는 것을 방지합니다. 따라서 정기적인 유지 관리가 필요합니다. Redis가 다음에 다시 시작될 때 메모리에서 하드 디스크로 데이터를 저장해야 합니다. 영구 파일을 사용하여 데이터를 복구하세요. 또한 재해 백업에 대비하기 위해 영구 파일을 원격 위치에 복사할 수 있습니다.

2. Redis 지속성의 두 가지 방법

RDB 지속성
메모리에 있는 Redis의 데이터베이스 기록을 정기적으로 디스크에 저장하는 것이 원칙입니다.
AOF 지속성(파일만 추가)
MySQL의 binlog와 유사한 방식으로 Redis 작업 로그를 파일에 기록하는 것이 원칙입니다.
AOF 지속성은 실시간 성능이 더 뛰어나므로, 즉 프로세스가 예기치 않게 종료될 때 데이터 손실이 적으므로 AOF가 현재 주류 지속성 방법이지만 RDB 지속성은 여전히 그 자리를 차지하고 있습니다.

3.RDB 지속성

RDB 지속성은 바이너리를 사용하여 현재 프로세스의 데이터를 메모리에 스냅샷으로 생성하여 지정된 시간 간격 내에 하드 디스크에 저장하는 것을 의미합니다(그래서 스냅샷 지속성이라고도 함). 압축 저장, 저장된 파일 접미사는 rdb입니다. Redis가 다시 시작되면 스냅샷 파일을 읽어 데이터를 복원할 수 있습니다.

3.1 트리거 조건

RDB 지속성의 트리거는 수동 트리거와 자동 트리거의 두 가지 유형으로 나뉩니다.

3.1.1

save 명령과 bgsave 명령을 모두 수동으로 트리거하면 RDB 파일을 생성할 수 있습니다.
save 명령은 RDB 파일이 생성될 때까지 Redis 서버 프로세스를 차단합니다. Redis 서버가 차단되는 동안 서버는 어떤 명령 요청도 처리할 수 없습니다.
bgsave 명령은 RDB 파일 생성을 담당하는 하위 프로세스를 포크()하고, 상위 프로세스(예: Redis 기본 프로세스)는 계속해서 요청을 처리합니다.
bgsave 명령 실행 중에는 fork 하위 프로세스만 서버를 차단하고, save 명령의 경우 전체 프로세스가 서버를 차단하므로 save는 기본적으로 포기되었으며 save 사용은 반드시 온라인 환경에서는 제거됩니다.

3.1.2 자동 트리거

RDB 지속성이 자동으로 트리거되면 Redis는 지속성을 위해 save 대신 bgsave를 선택합니다.

3.2 구성 방법

구성 파일을 수정하여 설정: save m n
자동 트리거의 가장 일반적인 상황은 구성 파일에 m n을 저장하는 것입니다. m 초 내에 n 변경 사항이 발생할 때를 지정하면 bgsave를 트리거합니다.

[root@localhost ~]# vim /etc/redis/6379.conf ##219行，以下三个save条件满足任意一个时，都会引起bgsave的调用save 900 1	##当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsavesave 300 10	##当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsavesave 60 10000	##当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave##254行，指定RDB文件名dbfilename dump.rdb##264行，指定RDB文件和AOF文件所在目录dir /var/lib/redis/6379##242行，是否开启RDB文件压缩rdbcompression yes

로그인 후 복사

3.3 기타 자동 트리거링 메커니즘

mn 저장 외에도 bgsave를 트리거하는 몇 가지 다른 상황이 있습니다.

마스터-슬레이브 복제 시나리오에서 슬레이브 노드가 전체 복사 작업을 수행하는 경우, 마스터 노드는 bgsave 명령을 실행하고 rdb 파일을 슬레이브 노드로 보냅니다.
shutdown 명령을 실행하면 rdb 지속성이 자동으로 실행됩니다.

3.4 실행 프로세스

Redis에서 고가용성 및 지속성을 구성하는 방법

Redis 상위 프로세스는 먼저 현재 save를 실행 중인지, 아니면 bgsave/bgrewriteaof의 하위 프로세스를 실행 중인지 확인합니다. 실행 중인 경우 bgsave 명령이 직접 반환됩니다. bgsave/bgrewriteaof의 하위 프로세스는 주로 성능 고려 사항으로 인해 동시에 실행할 수 없습니다. 두 개의 동시 하위 프로세스가 동시에 많은 수의 디스크 쓰기 작업을 수행하므로 심각한 성능 문제가 발생할 수 있습니다.
하위 프로세스를 생성할 때 상위 프로세스가 분기 작업을 수행하여 상위 프로세스가 차단되었습니다. 이 기간 동안 Redis는 클라이언트에서 어떤 명령도 실행할 수 없었습니다.
상위 프로세스가 분기된 후 bgsave 명령은 "백그라운드 저장 시작됨" 메시지를 반환하고 더 이상 상위 프로세스를 차단하지 않으며 다른 명령에 응답할 수 있습니다.
하위 프로세스는 RDB 파일을 생성하고 임시 파일을 생성합니다. 상위 프로세스 메모리 스냅샷을 기반으로 하는 스냅샷 파일입니다. 완료 후 원본 파일은 원자적으로 대체됩니다. 하위 프로세스는 완료를 나타내기 위해 상위 프로세스에 신호를 보내고 상위 프로세스는 실행을 위한 특별한 순서가 없습니다. 그러나 AOF의 우선순위가 높기 때문에 AOF가 켜져 있으면 Redis는 데이터를 복원하기 위해 AOF 파일을 로드하는 데 우선순위를 부여합니다. AOF가 꺼진 경우에만 Redis 서버가 시작되고 자동으로 로드될 때 RDB 파일이 감지됩니다. 로드가 완료될 때까지 RDB 파일을 로드하는 동안 서버가 차단됩니다.
Redis는 RDB 파일을 로드할 때 RDB 파일을 확인합니다. 파일이 손상되면 로그에 오류가 인쇄되고 Redis가 시작되지 않습니다.
4. AOF 지속성
RDB 지속성은 프로세스 데이터를 파일에 기록하는 반면, AOF 지속성은 Redis가 실행한 각 쓰기 및 삭제 명령을 별도의 로그 파일에 기록하며, 쿼리 작업은 Redis가 다시 시작될 때 기록되지 않습니다. AOF 파일을 다시 복원하여 데이터를 복원합니다.

4.1 开启 AOF

Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置

[root@localhost ~]# vim /etc/redis/6379.conf ##700行，修改，开启AOFappendonly yes##704行，指定AOF文件名称appendfilename "appendonly.aof"##796行，是否忽略最后一条可能存在问题的指令aof-load-truncated yes[root@localhost ~]# /etc/init.d/redis_6379 restartStopping ...
Redis stopped
Starting Redis server...

로그인 후 복사

4.2 执行流程

由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程。

AOF的执行流程包括：

命令追加（append）：将Redis的写命令追加到缓冲区aof_buf；
根据不同的同步策略，把aof_buf中的内容写入硬盘，并实现文件同步
文件重写（rewrite）：定期重写AOF文件，达到压缩的目的。

4.2.1 命令追加（append）

Redis先将命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO称为Redis负载的瓶颈。

命令追加的格式是Redis命令请求的协议格式，它是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单、避免二次开销等优点。在AOF文件中，除了用于指定数据库的select命令（如select 0为选中0号数据库）是由Redis添加的，其他都是客户端发送来的写命令。

4.2.2 文件写入（write）和文件同步（sync）

Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write和fsync函数，说明如下：
为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失；因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。

4.2.3 三种同步方式

AOF缓存区的同步文件策略存在三种同步方式，通过对/etc/redis/6379.conf的729行的修改进行配置。

4.2.3.1 appendfsync always

将命令写入aof_buf后，立即进行系统fsync操作，将其同步到AOF文件，当fsync操作完成后，线程便会返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也就只能处理几万个命令，而且会大大降低SSD的寿命。

4.2.3.2 appendfsync no

命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负载，通常同步周期为30秒。文件同步时间不可预测，并且缓冲区中的数据会堆积很多，导致数据安全性无法保障。

4.2.3.3 appendfsync everysec（推荐）

命令写入aof_buf后调用系统write操作，write完成后线程返回：fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，一次是Redis的默认配置，也是我们推荐的配置。

4.2.4 文件重写（rewrite）

随着时间流逝，Redis服务器执行的写命令越来越多，AOF文件也会越来越大；过大的AOF文件不仅会影响服务器的正常运行，也会导致数据恢复需要的时间过长。
文件重写是指定期重写AOF文件，减小AOF文件的体积。需要注意的是，AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作。
关于文件重写需要注意的另一点是：对于AOF持久化来说，文件重写虽然是强烈推荐的，但并不是必须的；即使没有文件重写，数据也可以被持久化并在Redis启动的时候导入；因此在一些现实中，会关闭自动的文件重写，然后定时任务在每天的某一时刻定时执行。

4.2.4.1 具有压缩功能的原因

文件重写之所以能够压缩AOF文件，原因在于：

过期的数据不再写入文件。
无效的命令不再写入文件：如有些数据被重复设置（set mykey v1,set mykey v2）、有些数据被删除了（set myset v1,del myset）等。
多条命令可以合并为一个：如sadd myset v1,sadd myset v2,sadd myset v3可以合并为sadd myset v1 v2 v3。

通过上述原因可以看出，由于重写后AOF执行的命令减少了，文件重写既可以减少文件占用的空间，也可以加快恢复速度。

4.2.4.2 文件重写的触发

文件重写分为手动触发和自动触发：

수동 트리거: bfrewriteaof 명령을 직접 호출합니다. 이 명령의 실행은 bgsave와 다소 유사합니다. 두 포크 프로세스는 모두 특정 작업을 수행하며 포크할 때만 차단됩니다.
자동 트리거링: auto-aof-rewrite-min-size 옵션과 auto-aof-rewrite-percentage 옵션을 설정하여 bgrewriteaof를 자동으로 실행합니다. auto-aof-rewrite-min-size와 auto-aof-rewrite-percentage 두 가지 옵션이 동시에 충족되는 경우에만 AOF 다시 쓰기, 즉 bgrewriteaof 작업이 자동으로 트리거됩니다.

자동으로 트리거된 구성은 /etc/redis/6379.conf의 771 및 772행에 있습니다.自动触发的配置位于/etc/redis/6379.conf的771行和772行

auto-aof-rewrite-percentage 100
当前AOF文件大小（即aof_current_size）是上次日志重写时AOF文件大小（aof_base_size）两倍时，发生bgrewriteaof操作
auto-aof-rewrite-min-size 64mb
当前AOF文件执行bgrewriteaof命令的最小值，避免刚开始启动Redis时由于文件尺寸较小导致频繁的bgrewriteaof

4.2.4.3 文件重写的流程

Redis에서 고가용성 및 지속성을 구성하는 방법
文件重写的流程如下：

Redis父进程首先平判断当前是否存在正在执行bgsave/bgrewriteaof的子进程；如果存在则bgrewriteaof命令直接返回，如果存在bgsave命令则等bgsave执行完成后再执行。
父进程执行fork操作创建子进程，这个过程中父进程是阻塞的。
父进程fork后，bgrewriteaof命令返回“Background append only file rewrite started”信息并不再阻塞父进程，并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确。
子进程只能共享fork操作时的内存数据，这是因为fork操作使用了写时复制技术。由于父进程依然在响应命令，因此Redis使用AOF重写缓冲区（aof_rewrite_buf）保存这部分数据，防止新AOF文件生成期间丢失这部分数据。也就是说，bgrewriteaof执行期间，Redis的写命令同时追加到aof_buf和aof_rewrite_buf两个缓冲区。
子进程根据内存快照，按照命令合并规则写入到新的AOF文件。
子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看。
父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。
使用新的AOF文件替换老文件，文成AOF重写。

关于文件重写的流程，有两点需要特别注意：

auto-aof-rewrite-percentage 100
현재 AOF 파일 크기( 즉, aof_current_size )가 마지막 로그 재작성 중에 AOF 파일 크기(aof_base_size)의 두 배이면 bgrewriteaof 작업이 발생합니다
auto-aof-rewrite-min-size 64mb
bgrewriteaof 명령을 실행하기 위한 현재 AOF 파일의 최소값 초기 시작을 방지하려면 Redis의 파일 크기가 작기 때문에 bgrewriteaof

4.2.4.3 파일 재작성 프로세스

자식 프로세스는 포크 작업 중에만 메모리 데이터를 공유할 수 있습니다. 이는 포크 작업이 쓰기 중 복사 기술을 사용하기 때문입니다. 상위 프로세스가 여전히 명령에 응답하고 있으므로 Redis는 AOF 재작성 버퍼(aof_rewrite_buf)를 사용하여 데이터의 이 부분을 저장하여 새 AOF 파일 생성 중에 이 데이터 부분이 손실되는 것을 방지합니다. 즉, bgrewriteaof 실행 중에 Redis의 쓰기 명령이 aof_buf 및 aof_rewrite_buf 버퍼에 동시에 추가됩니다.

하위 프로세스는 메모리 스냅샷과 명령 병합 규칙에 따라 새 AOF 파일에 씁니다.

하위 프로세스가 새 AOF 파일 작성을 마친 후 상위 프로세스에 신호를 보내고 상위 프로세스는 정보 지속성을 통해 볼 수 있는 통계 정보를 업데이트합니다.

상위 프로세스는 AOF 재작성 버퍼의 데이터를 새 AOF 파일에 기록하여 새 AOF 파일에 저장된 데이터베이스 상태가 서버의 현재 상태와 일치하는지 확인합니다.

🎜이전 파일을 새 AOF 파일로 교체하고 AOF에 다시 작성합니다. 🎜🎜🎜🎜 파일 재작성 프로세스와 관련하여 특별한 주의가 필요한 두 가지 사항이 있습니다: 🎜🎜🎜🎜재작성은 하위 프로세스를 분기하는 상위 프로세스에 의해 수행됩니다🎜🎜🎜🎜write 명령이 실행됩니다. Redis가 다시 작성하는 동안 새 AOF 파일에 추가해야 합니다. 이러한 이유로 Redis는 aof_rewrite_buf 캐시 🎜🎜🎜🎜4.3 시작 시 로드 🎜🎜🎜🎜AOF가 켜져 있으면 Redis는 먼저 AOF 파일을 로드합니다. 시작할 때 데이터를 복원합니다. AOF일 때만 닫히면 RDB 파일이 로드되어 데이터를 복원합니다. 🎜🎜🎜🎜AOF를 켰지만 AOF 파일이 없으면 RDB 파일이 있어도 로드되지 않습니다. 🎜🎜🎜🎜Redis는 AOF 파일을 로드할 때 AOF 파일을 확인합니다. 파일이 손상되면 로그에 오류가 인쇄되고 Redis가 시작되지 않습니다. 그러나 AOF 파일의 끝이 불완전하고(갑자기 시스템 가동 중지로 인해 파일 끝이 쉽게 불완전해질 수 있음) aof_load_truncated 매개변수가 설정된 경우 로그에 경고가 출력되고 Redis는 이를 무시합니다. AOF 파일의 끝을 확인하고 성공적으로 시작합니다. aof_load_truncated 매개변수는 기본적으로 활성화됩니다. 🎜🎜🎜🎜5. RDB와 AOF의 장점과 단점🎜🎜🎜RDB 지속성🎜🎜🎜장점: RDB 파일은 크기가 작고 네트워크 전송 속도가 빠르며 전체 복사에 적합합니다. 물론, RDB의 가장 중요한 장점 중 하나는 AOF에 비해 성능에 미치는 영향이 상대적으로 적다는 것입니다. 🎜 단점: RDB 파일의 잘 알려진 단점은 데이터 스냅샷의 지속성 방법에 따라 실시간 지속성을 달성할 수 없다는 것입니다. 오늘날 데이터가 점점 더 중요해지면서 대량의 데이터 손실은 종종 용납될 수 없습니다. 그래서 AOF 지속성이 주류가 됩니다. 또한 RDB 파일은 특정 형식을 충족해야 하며 호환성이 좋지 않아야 합니다(예: 이전 버전의 Redis는 새 버전의 RDB 파일과 호환되지 않습니다). 🎜 RDB 지속성을 위해 bgsave가 포크 작업을 수행할 때 Redis 기본 프로세스가 차단되는 반면, 하드 디스크에 데이터를 쓰는 하위 프로세스도 IO 부담을 가져옵니다. 🎜🎜🎜AOF 지속성🎜🎜🎜RDB 지속성에 따라 AOF의 우선 순위는 2차 지속성과 우수한 호환성을 지원하는 것입니다. 단점은 대용량 파일, 느린 복구 속도 및 성능에 큰 영향을 미칩니다. 🎜🎜AOF 지속성의 경우 하드 디스크에 데이터를 쓰는 빈도가 크게 증가하고(everysec 정책에 따라 두 번째 수준) IO 압력이 더 커지며 AOF에 추가 차단 문제가 발생할 수도 있습니다. 🎜

RDB의 bgsave와 유사하게 AOF 파일을 다시 작성하면 포크 차단 및 하위 프로세스 IO 로드 문제에 직면하게 됩니다. AOF는 하드 디스크에 데이터를 더 자주 기록하므로 Redis 기본 프로세스의 성능에 더 큰 영향을 미칩니다.

일반적으로 AOF의 자동 다시 쓰기 기능을 끄고 다시 쓰기 작업에 대한 예약 작업을 설정하고 업무량이 적은 이른 아침에 수행하여 AOF의 영향을 줄이는 것이 좋습니다. 메인 프로세스의 성능과 IO의 읽기 및 쓰기 압력에 영향을 미칩니다.

위 내용은 Redis에서 고가용성 및 지속성을 구성하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!