1), twemproxy는 일반적인 개념은 Proxy 방식과 비슷하고, 사용법도 일반 Redis와 다르지 않습니다. 그 아래에 여러 개의 Redis 인스턴스를 설정한 뒤, 사용 시에는 위치를 바꿔주세요. redis는 연결되어야 합니다. twemproxy에 연결하려면 요청을 프록시로 수신하고 일관된 해시 알고리즘을 사용하여 요청을 특정 redis로 전송하고 결과를 twemproxy에 반환합니다. 사용하기 쉽고(redis에 비해 연결 포트만 수정하면 됨) 기존 프로젝트를 확장하기 위한 첫 번째 선택입니다. 문제: twemproxy 자체 단일 포트 인스턴스의 압박으로 인해 일관된 해싱을 사용한 후 redis 노드 수가 변경되면 계산된 값이 변경되고 데이터가 자동으로 새 노드로 이동할 수 없습니다.
2) 현재 가장 일반적으로 사용되는 클러스터 솔루션인 codis는 기본적으로 twemproxy와 동일한 효과를 가지지만, 노드 수가 변경되면 오래된 노드 데이터를 새로운 해시 노드로 복구하는 기능을 지원합니다.
3) Redis Cluster3.0과 함께 제공되는 클러스터는 분산 알고리즘이 일관된 해싱이 아닌 해시 슬롯 개념과 자체적으로 노드 설정 슬레이브 노드를 지원하는 것이 특징입니다. 자세한 내용은 공식 문서를 참조하세요.
4. 비즈니스 코드 레이어에서 구현하고, 관련되지 않은 여러 개의 Redis 인스턴스를 코드 레이어에서 생성한 후 해당 키에 대한 해시 계산을 수행한 후 해당 Redis 인스턴스에서 데이터를 작동합니다. 이 방법은 해시 계층 코드에 대한 요구 사항이 상대적으로 높습니다. 고려 사항에는 노드 오류 후 대체 알고리즘 솔루션, 데이터 충격 후 자동 스크립트 복구, 인스턴스 모니터링 등이 포함됩니다.
11. Redis 클러스터 솔루션으로 인해 전체 클러스터를 사용할 수 없게 되는 상황은 무엇입니까?
복제 모델이 없는 3개의 노드 A, B, C가 있는 클러스터에서 노드 B에 장애가 발생하면 전체 클러스터는 5501-11000 범위의 슬롯이 없다고 생각합니다. 사용할 수 없습니다.
12. MySQL에는 2천만 개의 데이터가 있지만 Redis에 저장되는 데이터는 20만 개뿐입니다.
Redis 메모리 데이터 세트 크기가 특정 크기로 증가하면 데이터 제거 전략이 구현됩니다.
13. Redis에 적합한 시나리오는 무엇입니까?
(1) 세션 캐시(Session Cache) Redis를 사용하기 위해 가장 일반적으로 사용되는 시나리오 중 하나는 세션 캐시(Session Cache)입니다. Redis를 사용하여 다른 스토리지(예: Memcached)보다 세션을 캐시할 때의 이점은 Redis가 지속성을 제공한다는 것입니다. 엄격하게 일관성을 요구하지 않는 캐시를 유지할 때 대부분의 사람들은 사용자의 장바구니 정보가 모두 손실되면 불만을 품게 됩니다. 그래도 여전히 그럴까요? 다행히 Redis가 수년에 걸쳐 개선됨에 따라 Redis를 적절하게 사용하여 세션 문서를 캐시하는 방법을 쉽게 알아낼 수 있습니다. 잘 알려진 상용 플랫폼인 Magento도 Redis 플러그인을 제공합니다.
(2), 전체 페이지 캐시(FPC) Redis는 기본 세션 토큰 외에도 매우 간단한 FPC 플랫폼도 제공합니다. 일관성 문제로 돌아가서, Redis 인스턴스가 다시 시작되더라도 사용자는 디스크 지속성으로 인해 페이지 로딩 속도가 떨어지는 것을 볼 수 없습니다. 이는 PHP 로컬 FPC와 유사하게 크게 개선되었습니다. Magento를 다시 예로 들면, Magento는 Redis를 전체 페이지 캐시 백엔드로 사용할 수 있는 플러그인을 제공합니다. 또한 WordPress 사용자를 위해 Pantheon에는 매우 유용한 플러그인 wp-redis가 있어 탐색한 페이지를 최대한 빨리 로드하는 데 도움이 됩니다.
(3) 메모리 저장 엔진 분야에서 큐 Redis의 가장 큰 장점 중 하나는 Redis를 좋은 메시지 큐 플랫폼으로 사용할 수 있도록 목록 및 설정 작업을 제공한다는 것입니다. Redis가 대기열로 사용하는 작업은 로컬 프로그래밍 언어(예: Python)에서 목록의 푸시/팝 작업과 유사합니다. Google에서 "Redis 대기열"을 빠르게 검색하면 수많은 오픈 소스 프로젝트를 즉시 찾을 수 있습니다. 이러한 프로젝트의 목적은 Redis를 사용하여 다양한 대기열 요구 사항을 충족하는 매우 좋은 백엔드 도구를 만드는 것입니다. 예를 들어 Celery에는 Redis를 브로커로 사용하는 백엔드가 있습니다. 여기에서 볼 수 있습니다.
(4) 순위/카운터 Redis는 메모리에서 숫자를 늘리거나 줄이는 연산을 매우 잘 구현합니다. 세트와 정렬 세트도 이러한 작업을 수행하는 것을 매우 간단하게 해줍니다. Redis는 이 두 가지 데이터 구조를 제공합니다. 따라서 정렬된 세트에서 상위 10명의 사용자를 얻으려면 이를 "user_scores"라고 부르겠습니다. 다음과 같이 하면 됩니다. 물론 이는 사용자의 점수를 기반으로 수행한다고 가정합니다. 사용자와 사용자의 점수를 반환하려면 다음과 같이 실행해야 합니다. ZRANGE user_scores 0 10 WITHSCORESAgora Games는 Ruby로 구현된 좋은 예이며 순위는 Redis를 사용하여 데이터를 저장합니다. 여기서 볼 수 있습니다. .
(5), 게시/구독 마지막(하지만 확실히 중요한 것은) Redis의 게시/구독 기능입니다. 게시/구독에는 실제로 많은 사용 사례가 있습니다. 사람들이 이를 소셜 네트워크 연결에서 게시/구독 기반 스크립트의 트리거로 사용하고 심지어 Redis의 게시/구독 기능을 사용하여 채팅 시스템을 구축하는 것을 보았습니다! (아니요, 사실입니다. 확인해 보세요.)
14. Redis에서 지원하는 Java 클라이언트는 무엇입니까? 공식적으로 권장되는 것은 무엇입니까?
Redisson, Jedis, 양상추 등 공식적인 권장 사항은 Redisson을 사용하는 것입니다.
15. Redis와 Redisson은 어떤 관계인가요?
Redisson은 사용자가 분산 환경에서 일부 Java 개체(Bloom 필터, BitSet, Set, SetMultimap, ScoredSortedSet 등)를 쉽게 구현할 수 있도록 도와주는 고급 분산 조정 Redis 클라이언트입니다. , 맵, ConcurrentMap, 목록, ListMultimap, 큐, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, ReadWriteLock, AtomicLong, CountDownLatch, 게시/구독, HyperLogLog).
16. 제디스와 레디슨의 장점과 단점은 무엇인가요?
Jedis는 Redis에 의해 Java로 구현된 클라이언트입니다. Redisson은 Redis 명령에 대해 상대적으로 포괄적인 지원을 제공하며 이는 Jedis와 유사합니다. Redis는 함수가 상대적으로 간단하고 문자열 작업을 지원하지 않으며 정렬, 트랜잭션, 파이프라인, 파티션과 같은 Redis 기능을 지원하지 않습니다. Redisson의 목적은 Redis에서 사용자의 우려사항을 분리하여 사용자가 비즈니스 로직 처리에 더 집중할 수 있도록 하는 것입니다.
17. Redis에서 비밀번호를 설정하고 확인하는 방법은 무엇인가요?
비밀번호 설정: config set requirepass 123456 인증 비밀번호: auth 123456
18. Redis 해시 슬롯의 개념에 대해 이야기해 주세요.
Redis 클러스터는 일관된 해싱을 사용하지 않지만 해시 슬롯 개념을 도입합니다. Redis 클러스터에는 16384개의 해시 슬롯이 있으며 각 키는 CRC16 확인 후 확인됩니다. 모듈은 배치할 슬롯을 결정하고 클러스터의 각 노드는 해시 슬롯의 일부를 담당합니다.
19. Redis 클러스터의 마스터-슬레이브 복제 모델은 무엇입니까?
일부 노드가 실패하거나 대부분의 노드가 통신할 수 없는 경우에도 클러스터를 계속 사용할 수 있도록 하기 위해 클러스터는 마스터-슬레이브 복제 모델을 사용하며 각 노드에는 N-1 복제본이 있습니다. Product.
20. Redis 클러스터에서 쓰기 작업이 손실되나요? 왜?
Redis는 데이터의 강력한 일관성을 보장하지 않습니다. 즉, 실제로 특정 조건에서는 클러스터의 쓰기 작업이 손실될 수 있습니다.
21. Redis 클러스터는 어떻게 복제되나요?
비동기 복제
22. Redis 클러스터의 최대 노드 수는 몇 개입니까?
16384.
23. Redis 클러스터용 데이터베이스를 선택하는 방법은 무엇입니까?
Redis 클러스터는 현재 데이터베이스를 선택할 수 없으며 기본값은 데이터베이스 0입니다.
24. Redis의 연결성을 테스트하는 방법은 무엇입니까?
ping
25. Redis에서 파이프라인의 용도는 무엇입니까?
요청/응답 서버는 이전 요청이 아직 응답되지 않은 경우에도 새 요청을 처리할 수 있습니다. 이를 통해 응답을 기다리지 않고 서버에 여러 명령을 보내고 최종적으로 한 단계로 해당 응답을 읽을 수 있습니다. 이것이 수십 년 동안 널리 사용되어 온 기술인 파이프라이닝입니다. 예를 들어, 많은 POP3 프로토콜은 이 기능에 대한 지원을 구현하여 서버에서 새 이메일을 다운로드하는 프로세스 속도를 크게 향상시킵니다.
26. Redis 트랜잭션을 이해하는 방법은 무엇입니까?
트랜잭션은 단일 격리된 작업입니다. 트랜잭션의 모든 명령은 직렬화되어 순서대로 실행됩니다. 트랜잭션이 실행되는 동안 다른 클라이언트가 보낸 명령 요청으로 인해 중단되지 않습니다. 트랜잭션은 원자성 작업입니다. 즉, 트랜잭션의 모든 명령이 실행되거나 어느 것도 실행되지 않습니다.
27. Redis 트랜잭션과 관련된 명령어는 무엇인가요?
멀티、EXEC、삭제、보기
##28. Redis 키의 만료 시간과 영구 유효성을 각각 설정하는 방법은 무엇입니까?
EXPIRE 및 PERSIST 명령.
29. Redis는 어떻게 메모리를 최적화하나요?
해시 테이블(해시)을 최대한 사용하세요. 해시 테이블(해시 테이블에 저장되는 개수가 적다는 뜻)은 메모리를 아주 적게 사용하므로 저장을 하셔야 합니다. 모델은 해시 테이블로 추상화됩니다. 예를 들어 웹 시스템에 사용자 개체가 있는 경우 사용자의 이름, 성, 이메일 및 비밀번호에 대해 별도의 키를 설정하지 말고 대신 모든 사용자 정보를 해시 테이블에 저장하세요. 🎜#
30. Redis 재활용 프로세스는 어떻게 진행되나요? 클라이언트가 새 명령을 실행하고 새 데이터를 추가했습니다. Redi는 메모리 사용량을 확인하여 maxmemory 한도보다 큰 경우 설정된 정책에 따라 재활용합니다. 새로운 명령이 실행됩니다. 그래서 우리는 지속적으로 경계에 도달한 다음 계속해서 경계 아래로 다시 재활용함으로써 메모리 한계의 경계를 넘고 있습니다. 명령 결과로 인해 많은 양의 메모리가 사용되는 경우(예: 큰 세트의 교차점을 새 키에 저장하는 경우) 이 메모리 사용량으로 인해 메모리 제한이 초과되는 데 오랜 시간이 걸리지 않습니다.
31. Redis 재활용에는 어떤 알고리즘이 사용되나요? LRU 알고리즘
32. Redis는 어떻게 대용량 데이터를 삽입하나요?
Redis2.6 시작 redis-cli는 대량의 데이터 삽입 작업을 수행하기 위해 파이프 모드라는 새로운 모드를 지원합니다.
33. Redis 파티셔닝이 필요한 이유는 무엇입니까?
파티션을 사용하면 Redis가 더 큰 메모리를 관리할 수 있으며 Redis는 모든 시스템의 메모리를 사용할 수 있습니다. 파티션이 없으면 최대 한 대의 머신 메모리만 사용할 수 있습니다. 파티셔닝을 사용하면 단순히 컴퓨터를 추가하는 것만으로도 Redis의 컴퓨팅 성능을 두 배로 늘릴 수 있으며, 컴퓨터와 네트워크 카드의 수가 증가하면 Redis의 네트워크 대역폭도 두 배로 늘어납니다.
34. 어떤 Redis 파티션 구현 솔루션을 사용할 수 있는지 알고 계시나요?
클라이언트 측 파티셔닝은 클라이언트가 데이터를 저장하거나 읽을 Redis 노드를 이미 결정했음을 의미합니다. 대부분의 클라이언트는 이미 클라이언트측 파티셔닝을 구현하고 있습니다. 브로커 파티셔닝은 클라이언트가 브로커에게 요청을 보낸 후 브로커가 데이터를 쓰거나 읽기 위해 이동할 노드를 결정하는 것을 의미합니다. 에이전트는 파티션 규칙에 따라 요청할 Redis 인스턴스를 결정한 다음 Redis 응답 결과에 따라 이를 클라이언트에 반환합니다. Redis 및 memcached의 프록시 구현은 Twemproxy 쿼리 라우팅(Query Routing)입니다. 이는 클라이언트가 임의의 Redis 인스턴스를 무작위로 요청한 다음 Redis가 해당 요청을 올바른 Redis 노드로 전달함을 의미합니다. Redis 클러스터는 하이브리드 형태의 쿼리 라우팅을 구현하지만 한 Redis 노드에서 다른 Redis 노드로 요청을 직접 전달하는 대신 클라이언트의 도움을 받아 올바른 Redis 노드로 직접 리디렉션합니다.
35. Redis 파티셔닝의 단점은 무엇인가요?
여러 키를 사용하는 작업은 일반적으로 지원되지 않습니다. 예를 들어 두 컬렉션은 서로 다른 Redis 인스턴스에 저장될 수 있으므로 교차할 수 없습니다(실제로 이러한 상황에 대한 방법이 있지만 Intersection 명령을 직접 사용할 수는 없습니다). 동시에 여러 키를 작동하는 경우 Redis 트랜잭션을 사용할 수 없습니다. 분할 세분성이 핵심이므로 매우 큰 정렬 세트처럼 매우 긴 단일 거대한 키로 데이터 세트를 분할할 수 없습니다. 파티션을 사용하면 데이터 처리가 매우 복잡해집니다. 예를 들어 백업을 위해 여러 Redis 인스턴스와 호스트에서 RDB/AOF 파일을 동시에 수집해야 합니다. 파티셔닝 시 동적으로 확장하거나 축소하는 것은 복잡할 수 있습니다. Redis 클러스터는 런타임에 Redis 노드를 추가하거나 삭제하여 사용자에게 최대한 투명한 데이터 재조정을 달성할 수 있습니다. 그러나 일부 다른 클라이언트 분할 또는 프록시 분할 방법은 이 기능을 지원하지 않습니다. 하지만 이 문제를 더 잘 해결할 수 있는 사전 샤딩 기술도 있습니다.
36. Redis 영구 데이터 및 캐시를 확장하는 방법은 무엇입니까?
Redis를 캐시로 사용하는 경우 일관된 해싱을 사용하여 동적 확장 및 축소를 달성합니다. Redis를 영구 저장소로 사용하는 경우 고정된 키-노드 매핑 관계를 사용해야 하며, 일단 결정된 노드 수는 변경할 수 없습니다. 그렇지 않은 경우(즉, Redis 노드를 동적으로 변경해야 하는 경우) 런타임 시 데이터 균형을 재조정할 수 있는 시스템을 사용해야 하며 현재는 Redis 클러스터에서만 이를 수행할 수 있습니다.
37. Redis 배포는 초기에 해야 할까요, 아니면 규모가 커지는 이후에 해야 할까요? 왜?
Redis는 매우 가볍기 때문에(단일 인스턴스는 1M 메모리만 사용) 향후 확장을 방지하는 가장 좋은 방법은 처음에 더 많은 인스턴스를 시작하는 것입니다. 서버가 하나만 있는 경우에도 파티션을 사용하여 동일한 서버에서 여러 인스턴스를 시작하여 Redis를 처음부터 분산 방식으로 실행할 수 있습니다. 처음에 32개 또는 64개의 인스턴스와 같이 몇 가지 Redis 인스턴스를 추가로 설정하는 것은 대부분의 사용자에게 번거로울 수 있지만 장기적으로는 희생할 가치가 있습니다. 이 경우 데이터가 계속해서 증가하고 더 많은 Redis 서버가 필요할 때 해야 할 일은 Redis 인스턴스를 한 서비스에서 다른 서버로 마이그레이션하는 것뿐입니다(파티셔닝 문제를 고려하지 않음). 다른 서버를 추가한 후에는 Redis 인스턴스의 절반을 첫 번째 머신에서 두 번째 머신으로 마이그레이션해야 합니다.
38. 트웸프록시(Twemproxy)란 무엇인가요?
Twemproxy는 Memcached의 ASCII 프로토콜과 Redis 프로토콜을 프록시하는 Twitter에서 관리하는 (캐싱) 프록시 시스템입니다. C 언어로 작성된 단일 스레드 프로그램이며 매우 빠르게 실행됩니다. Apache 2.0 라이센스를 사용하는 오픈 소스 소프트웨어입니다. Twemproxy는 자동 파티셔닝을 지원합니다. 프록시 Redis 노드 중 하나를 사용할 수 없으면 해당 노드가 자동으로 제외됩니다(이렇게 하면 원래 키-인스턴스 매핑 관계가 변경되므로 Redis를 캐시로 사용할 때만 Twemproxy를 사용해야 합니다). 여러 Twemproxy 인스턴스를 시작한 다음 클라이언트가 모든 Twemproxy 인스턴스에 연결되도록 할 수 있으므로 Twemproxy 자체에는 단일 문제 지점이 없습니다. Twemproxy는 Redis 클라이언트와 서버 사이의 중간 계층으로, 파티션 기능을 처리하는 것이 복잡하지 않아야 하며 상대적으로 안정적이어야 합니다.
39. 일관된 해싱을 지원하는 클라이언트는 무엇인가요?
Redis-rb, Predis 등
40. Redis와 다른 키-값 스토어의 차이점은 무엇인가요?
Redis는 더 복잡한 데이터 구조를 가지며 이에 대한 원자적 연산을 제공합니다. 이는 다른 데이터베이스와는 다른 진화 경로입니다. Redis의 데이터 유형은 기본 데이터 구조를 기반으로 하며 추가 추상화가 필요 없이 프로그래머에게 투명합니다. Redis는 메모리에서 실행되지만 디스크에 유지될 수 있으므로 다양한 데이터 세트를 고속으로 읽고 쓸 때 메모리를 측정해야 합니다. 데이터 양은 하드웨어 메모리보다 커서는 안 됩니다. 인메모리 데이터베이스의 또 다른 장점은 디스크의 동일한 복잡한 데이터 구조와 비교할 때 메모리에서의 작동이 매우 간단하므로 Redis는 강력한 내부 복잡성을 가지고 많은 작업을 수행할 수 있다는 것입니다. 또한 디스크 형식 측면에서 임의 액세스가 필요하지 않기 때문에 컴팩트하게 추가 생성됩니다.
41. Redis의 메모리 사용량은 얼마인가요?
예를 들어 보겠습니다. 1백만 개의 키-값 쌍(키는 0~999999이고 값은 "hello world" 문자열)이 내 32비트 Mac 노트북에서 100MB를 사용합니다. 동일한 데이터를 키에 담는 데는 16MB만 필요합니다. 이는 키 값에 큰 오버헤드가 있기 때문입니다. Memcached에서의 실행 결과는 비슷하지만 Redis가 유형 정보, 참조 카운팅 등을 기록하므로 오버헤드가 Redis보다 약간 적습니다. 물론 키-값 쌍이 클수록 둘 사이의 비율이 훨씬 더 좋습니다. 64비트 시스템은 32비트 시스템보다 더 많은 메모리 오버헤드를 필요로 합니다. 특히 키-값 쌍이 작은 경우 이는 64비트 시스템에서 포인터가 8바이트를 차지하기 때문입니다. 그러나 물론 64비트 시스템은 더 큰 메모리를 지원하므로 대규모 Redis 서버를 실행하려면 어느 정도 64비트 시스템이 필요합니다.
42. Redis의 메모리 사용량을 줄이는 방법은 무엇인가요?
32비트 Redis 인스턴스를 사용하는 경우 일반적으로 작은 Key-Value를 여러 개 함께 저장할 수 있기 때문에 Hash, list, sorted set, set 등과 같은 컬렉션 유형 데이터를 효과적으로 활용할 수 있습니다. 더 컴팩트한 방법으로.
43. Redis 사용량 및 상태 정보를 보는 데 사용되는 명령은 무엇입니까?
info
44. Redis에 메모리가 부족하면 어떻게 되나요?
설정된 상한에 도달하면 Redis write 명령은 오류 메시지를 반환합니다(그러나 read 명령은 여전히 정상적으로 반환될 수 있습니다.). 또는 Redis가 최대 한도에 도달하면 구성 제거 메커니즘을 사용하기 위해 Redis를 캐시로 사용할 수 있습니다. 메모리 상한선이 있으면 이전 내용이 플러시됩니다.
45. Redis는 멀티 코어 CPU의 활용도를 높이는 방법은 무엇입니까?
동일한 서버에 Redis의 여러 인스턴스를 배포하고 이를 다른 서버로 사용할 수 있으며, 어쨌든 서버 하나로는 충분하지 않으므로 여러 CPU를 사용하려는 경우 샤딩을 고려할 수 있습니다.
46. Redis 인스턴스는 최대 몇 개의 키를 저장할 수 있나요?
List, Set 및 Sorted Set을 최대 몇 개의 요소에 저장할 수 있나요? 이론적으로 Redis는 최대 232개의 키를 처리할 수 있으며 실제 테스트에서는 각 인스턴스에 최소 2억 5천만 개의 키가 저장되었습니다. 우리는 더 큰 값을 테스트하고 있습니다. 모든 목록, 집합 및 정렬된 집합은 232개의 요소를 보유할 수 있습니다. 즉, Redis의 저장 한도는 시스템에서 사용 가능한 메모리 값입니다.
47. 일반적인 Redis 성능 문제 및 해결 방법은 무엇입니까?
(1) 마스터는 RDB 메모리 스냅샷, AOF 로그 파일 등의 지속성 작업을 수행하지 않는 것이 가장 좋습니다.
(2) 데이터가 중요한 경우 슬레이브는 AOF 백업 데이터를 활성화하고 정책을 동기화하도록 설정합니다. 초당 한 번
(3) 마스터-슬레이브 복제 속도와 연결 안정성을 위해 마스터와 슬레이브가 동일한 LAN에 있는 것이 가장 좋습니다.
(4) 슬레이브 라이브러리를 큰 압박을 받고 있는 마스터 라이브러리
(5) 마스터 슬레이브 복제에 그래프 구조를 사용하지 마십시오. 즉, Master
48. Redis는 어떤 지속성 방법을 제공하나요?
RDB 지속성 모드는 지정된 시간 간격으로 데이터의 스냅샷을 저장할 수 있습니다. AOF 지속성 모드는 서버가 다시 시작되면 이러한 명령이 다시 실행되어 원래 데이터를 복원합니다. Redis 프로토콜을 사용하여 각 쓰기 작업을 파일 끝에 추가하고 저장합니다. Redis는 데이터 실행만 원하는 경우 AOF 파일 크기가 너무 크지 않도록 백그라운드에서 AOF 파일을 다시 작성할 수도 있습니다. 서버에 있는 경우 지속성 방법을 동시에 사용할 필요가 없습니다. 이 경우 redis가 다시 시작되면 원본 데이터를 복원하기 위해 AOF 파일이 먼저 로드됩니다. , 일반적으로 AOF 파일에 의해 저장된 데이터 세트는 RDB 파일에 의해 저장된 데이터 세트보다 더 완전하기 때문입니다. 가장 중요한 것은 RDB 지속성부터 시작하겠습니다. 방법.
49. 적절한 지속 방법을 선택하는 방법은 무엇입니까?
일반적으로 PostgreSQL에 필적하는 데이터 보안을 달성하려면 두 지속성 기능을 동시에 사용해야 합니다. 데이터에 많은 관심을 갖고 있지만 여전히 몇 분 내에 데이터 손실을 감당할 수 있는 경우 RDB 지속성을 사용할 수 있습니다. 많은 사용자가 AOF 지속성만 사용하지만 이 방법은 권장되지 않습니다. RDB 스냅샷(스냅샷)을 정기적으로 생성하는 것은 데이터베이스 백업에 매우 편리하고 RDB는 다음을 제외하고 AOF보다 빠르게 데이터 세트를 복원하기 때문입니다. 앞서 언급한 AOF 프로그램.
50. Redis를 다시 시작하지 않고도 구성을 수정하면 실시간으로 적용됩니까?
어떤 형태의 재부팅도 수행하지 않고 CONFIG SET 명령을 통해 수정할 수 있는 인스턴스 실행용 구성 옵션이 많이 있습니다. Redis 2.2부터는 Redis를 다시 시작하지 않고도 AOF에서 RDB의 스냅샷 지속성 또는 기타 수단으로 전환할 수 있습니다. 자세한 내용은 'CONFIG GET *' 명령을 검색하세요. 그러나 Redis 프로그램을 새 버전으로 업그레이드하거나 현재 CONFIG 명령에서 지원하지 않는 일부 구성 매개변수를 수정해야 하는 경우와 같이 다시 시작해야 하는 경우도 있습니다.
추천 학습: Redis 비디오 튜토리얼
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
