Redis는 고급 키-값 데이터베이스입니다. 멤캐시드와 비슷하지만, 데이터가 영속성이 있고 데이터 타입도 풍부합니다. 문자열, 연결 리스트, 집합, 그리고 순서 모음이 있습니다. 서버 측에서 컬렉션의 합, 교차, 보완(차분) 계산을 지원하며, 다양한 정렬 기능도 지원합니다. 그래서 Redis는 데이터 구조 서버로도 볼 수 있습니다.
모든 Redis 데이터는 메모리에 저장된 후 때때로 디스크에 비동기적으로 저장됩니다(이를 "반영속 모드"라고 부릅니다); 또한 모든 데이터 변경 사항을 추가 파일 파일(AOF)에 기록할 수 있으며, 이를 "완전 지속 모드"라고 부릅니다.
첫 번째 방법은 filesnapshotting입니다: 기본 redis는 데이터를 스냅샷 형태로 디스크에 영속화합니다(이진 파일, dump.rdb, 이 파일 이름은 지정할 수 있음). 구성 파일의 형식은 다음과 같습니다: save N M은 redis에서 최소 M개의 수정이 발생하면 N초 이내에 redis가 디스크에 스냅샷을 가져옵니다. 물론, 수동으로 저장이나 비동기식 bgsave를 수행해 스냅샷을 찍을 수도 있습니다.
작동 방식을 간단히 소개하자면: Redis가 지속되어야 할 때, Redis는 자식 프로세스를 포크합니다; 자식 프로세스는 데이터를 디스크의 임시 RDB 파일에 기록합니다; 서브프로세스가 임시 파일을 모두 쓰면 원본 RDB를 교체하는데, 이는 쓰기 시 복사(copy-on-write)의 장점이 있습니다
또한 지속성 방법인 Append-only: filesnapshotting 메서드도 있습니다. redis가 비정상적으로 죽으면 최근 데이터가 손실됩니다(손실된 데이터의 양은 저장 정책 설정에 따라 다릅니다). 이것이 가장 큰 단점입니다. 비즈니스 용량이 클수록 손실되는 데이터가 많다는 점입니다. 추가 전용 방법은 모든 데이터 손실을 처리할 수 있지만, redis의 성능은 더 떨어집니다. AOF는 프로세스 내내 지속될 수 있으며, 구성 파일에서만 켜기만 하면 됩니다(기본값은 '아니오'), 부속 '예' AEF가 활성화된 후, redis가 데이터를 수정하는 명령을 실행할 때마다 그 파일이 aof 파일에 추가되고, redis가 재시작되면 AOF 파일을 읽기 위해 "재생"을 통해 redis가 닫히기 직전 마지막 순간으로 복원됩니다.
LOG 재작성 데이터가 수정됨에 따라 AOF 파일이 점점 커지면서, 많은 데이터가 키의 변경 사항을 기록합니다. 따라서 redis에는 흥미로운 기능이 있습니다: 클라이언트 측 작업에 영향을 주지 않고 백그라운드에서 AOF 파일을 재구성할 수 있습니다. 언제든지 BGREWRITEAOF 명령을 실행하면 현재 메모리에서 가장 짧은 명령 시퀀스를 디스크에 기록하며, 이 명령들은 상태 변경, 카운터 변경 등 불필요한 변경 없이 현재 데이터 상황을 완전히 구성할 수 있어 AOF 파일 크기를 줄일 수 있습니다. 그래서 OF를 사용할 때는 Redis에서 BGREWRITEAOF 사용도 권장합니다.
AOF 파일을 새로고침하는 세 가지 방법이 있는데, 구성 매개변수 appendfsync를 참고하세요: appendfsync는 수정 명령이 제출될 때마다 항상 fsync를 호출해 AOF 파일에 플러시하는데, 이는 매우 느리지만 매우 안전합니다; appendfsync everysec은 매초 fsync를 호출하여 AOF 파일에 빠르게 플러시하지만, 1초 이내에 데이터를 잃을 수 있습니다; appendfsync는 운영체제에 의존하지 않고, redis는 OV를 적극적으로 새로고침하지 않아서 가장 빠르지만 보안이 좋지 않습니다. 초당 새로고침 수가 기본적으로 권장되어 속도와 보안을 모두 고려합니다.
시스템 문제로 인해 AOF가 손상되었을 수 있습니다. redis가 더 이상 이 OF를 불러올 수 없게 되니, 아래 단계를 따라 해결할 수 있습니다: 먼저 AOF 파일을 백업하고 다른 곳으로 복사하세요; 원본 OF 파일을 수정하고 실행: $redis-check-aof –fix; diff –u 명령어를 사용해 복구 전후로 파일 불일치를 확인할 수 있습니다. Redis 서비스를 재시작하세요.
LOG Rewrite 작동 원리: Copy-on-write를 사용하기도 마찬가지입니다: 먼저 redis가 자식 프로세스를 포크하고; 자식 프로세스는 최신 AOF를 임시 파일에 기록합니다; 부모 프로세스는 가장 최근에 실행된 변경 사항을 점진적으로 메모리에 기록합니다(이 시점에는 이전 AOF가 여전히 작성되어 있으며, 실패하면 안전하게 다시 작성할 수 있습니다); 자식 프로세스가 임시 파일을 다시 쓰기를 마치면, 부모 프로세스는 신호를 받고 이전의 점진적 변경 사항을 임시 파일 끝에 메모리에 기록합니다. Redis는 이전 OF 파일의 이름을 바꾸고, 임시 파일의 이름을 바꾸며, 새 OF에 쓰기 시작합니다.
마지막으로, 만약(머신이나 디스크 충돌)을 대비해, filesnapshotting 또는 Append-Only 방식으로 생성된 *rdb *.aof 파일을 원격 기기에 정기적으로 백업하는 것을 잊지 마세요. 저는 30분마다 크론탭을 사용해 SCP를 진행합니다. Redis의 마스터-슬레이브 기능은 사용하지 않았는데, 30분 정도 백업이면 괜찮을 것 같고, 마스터-슬레이브가 있다면 머신을 좀 낭비하는 것 같아서요. 결국 이는 적용 방식에 따라 다릅니다.
|
게시됨 2017. 8. 24. 오후 4:37:45
|
|
|
