이 기사에서는 Redis 지식 포인트에 대한 답변 분석 및 마인드 맵을 포함하여 40개의 Redis 인터뷰 질문을 공유합니다. 도움이 필요한 친구들이 모두 참고할 수 있기를 바랍니다.
Redis는 완전 오픈 소스이며 무료이며 BSD 프로토콜을 준수하며 고성능 키-값 데이터베이스입니다.
Redis는 다른 키-값 캐시 제품과 비교하여 다음과 같은 세 가지 특징을 가지고 있습니다.
(1) Redis는 데이터 지속성을 지원하며, 메모리의 데이터를 디스크에 저장할 수 있으며, 재시작 시 다시 로드하여 사용할 수 있습니다.
(2) Redis는 단순한 키-값 유형의 데이터를 지원할 뿐만 아니라 list, set, zset, hash와 같은 데이터 구조의 저장도 제공합니다.
(3) Redis는 데이터 백업, 즉 마스터-슬레이브 모드의 데이터 백업을 지원합니다.
[관련 추천: Redis 동영상 튜토리얼]
Redis의 장점
(1) 매우 높은 성능 – Redis는 110,000회/초의 속도로 읽고 81,000회/초의 속도로 쓸 수 있습니다.
(2) 풍부한 데이터 유형 – Redis는 이진 사례에 대한 문자열, 목록, 해시, 집합 및 순서 집합 데이터 유형 작업을 지원합니다.
(3) 원자성 - Redis의 모든 작업은 원자성입니다. 즉, 성공적으로 실행되거나 실패할 경우 전혀 실행되지 않습니다. 개별 작업은 원자적입니다. 다중 작업은 MULTI 및 EXEC 명령어로 래핑된 트랜잭션, 즉 원자성도 지원합니다.
(4) 풍부한 기능 - Redis는 게시/구독, 알림, 키 만료 및 기타 기능도 지원합니다.
Redis는 다른 키-값 저장소와 어떻게 다릅니까?
(1) Redis는 더 복잡한 데이터 구조를 가지며 이에 대한 원자적 연산을 제공합니다. 이는 다른 데이터베이스와는 다른 진화 경로입니다. Redis의 데이터 유형은 기본 데이터 구조를 기반으로 하며 추가 추상화가 필요 없이 프로그래머에게 투명합니다.
(2) Redis는 메모리에서 실행되지만 디스크에 유지될 수 있으므로 데이터 양이 하드웨어 메모리보다 클 수 없기 때문에 다양한 데이터 세트를 고속으로 읽고 쓸 때 메모리를 측정해야 합니다. 인메모리 데이터베이스의 또 다른 장점은 디스크의 동일한 복잡한 데이터 구조와 비교할 때 메모리에서의 작동이 매우 간단하므로 Redis는 강력한 내부 복잡성을 가지고 많은 작업을 수행할 수 있다는 것입니다. 또한 디스크 형식 측면에서 임의 액세스가 필요하지 않기 때문에 컴팩트하게 추가 생성됩니다.
답변: Redis는 문자열(string), 해시(hash), 목록(list), 집합(set) 및 zsetsorted 집합: 순서 집합)의 다섯 가지 데이터 유형을 지원합니다.
실제 프로젝트에서 더 일반적으로 사용되는 것은 문자열과 해시입니다. 고급 Redis 사용자라면 HyperLogLog, Geo 및 Pub/Sub 데이터 구조도 추가해야 합니다.
BloomFilter, RedisSearch, Redis-ML 등 Redis 모듈도 사용해봤다고 하면 면접관의 눈빛이 빛나기 시작할 것입니다.
(1) HashMap과 마찬가지로 데이터가 메모리에 저장되므로 빠릅니다. HashMap의 장점은 검색 및 연산의 시간 복잡도가 O1)
(2) 문자열을 포함한 풍부한 데이터 유형을 지원합니다. , list 및 set , Zset, hash 등
(3) 지원 트랜잭션, 작업은 모두 원자성입니다. 소위 원자성은 데이터에 대한 모든 변경 사항이 실행되거나 전혀 실행되지 않음을 의미합니다.
(4 ) 풍부한 기능: 캐싱, 메시지에 사용할 수 있으며 키를 눌러 만료 시간을 설정하면 만료 후 자동으로 삭제됩니다
(1) Memcached의 모든 값은 단순한 문자열이며, 이를 대체하는 redis는 더 풍부한 데이터 유형을 지원합니다.
(2) Redis는 Memcached보다 훨씬 빠릅니다
(3) Redis는 내구성이 있습니다. 데이터 변환
(1) 저장 방법 Memecache는 모든 데이터를 메모리에 저장합니다. 정전 후에는 데이터가 메모리 크기를 초과할 수 없습니다. Redis는 데이터 지속성을 보장하기 위해 하드 디스크에 부분적으로 저장됩니다.
(2) 데이터 지원 유형 Memcache의 데이터 유형 지원은 비교적 간단합니다. Redis에는 복잡한 데이터 유형이 있습니다.
(3) 사용되는 기본 모델이 다르고 기본 구현 방법과 클라이언트와의 통신을 위한 애플리케이션 프로토콜이 다릅니다. Redis는 자체 VM 메커니즘을 직접 구축합니다. 일반 시스템이 시스템 기능을 호출하면 이동 및 요청에 일정 시간이 낭비되기 때문입니다.
답변: Redis는 단일 프로세스 및 단일 스레드입니다. Redis는 큐 기술을 사용하여 동시 액세스를 직렬 액세스로 전환하여 기존 데이터베이스 직렬 제어의 오버헤드를 제거합니다.
답변: 512M
Redis는 두 가지 지속성 메커니즘을 제공합니다: RDB 및 AOF 메커니즘:
1. RDBRedis DataBase) 지속성 모드:
는 Redis 데이터베이스의 모든 키-값 쌍을 기록하기 위해 데이터 세트 스냅샷을 사용하는 반영구적 모드를 나타냅니다. 특정 시점에 임시 파일에 데이터를 씁니다. 지속성이 완료된 후 이 임시 파일을 사용하여 마지막 지속된 파일을 교체하여 데이터를 복구합니다.
장점:
(1) dump.rdb 파일이 하나만 있어 지속성이 편리합니다.
(2) 재해에 강하고 안전한 디스크에 파일을 저장할 수 있습니다.
(3) 성능을 최대화하려면 하위 프로세스를 포크하여 쓰기 작업을 완료하고 기본 프로세스가 계속 명령을 처리하도록 하여 IO가 최대화되도록 합니다. 지속성을 위해 별도의 하위 프로세스를 사용하고 메인 프로세스는 IO 작업을 수행하지 않으므로 Redis의 고성능을 보장합니다.)
(4) 데이터 세트가 클 경우 시작 효율성은 AOF보다 높습니다.
단점:
낮은 데이터 보안. RDB는 일정 간격으로 유지됩니다. 지속성 사이에 redis가 실패하면 데이터 손실이 발생합니다. 따라서 이 방법은 데이터 요구 사항이 엄격하지 않은 경우에 더 적합합니다.
2.AOFAppend-only 파일) 지속성 방법:
은 모든 명령줄 레코드가 redis 명령 요청 프로토콜 형식으로 완전히 영구적으로 저장된다는 것을 의미합니다. aof 파일로 저장됩니다.
장점:
(1) 데이터 보안, aof 지속성은appendfsync 속성으로 구성할 수 있으며 항상 각 명령 작업이 aof 파일에 기록됩니다.
(2) 추가 모드를 통해 파일을 작성합니다. 서버가 중간에 다운되더라도 redis-check-aof 도구를 사용하여 데이터 일관성 문제를 해결할 수 있습니다.
(3) AOF 메커니즘의 다시 쓰기 모드. AOF 파일을 다시 작성하기 전에(파일이 너무 크면 명령이 병합되고 다시 작성됨) 일부 명령을 삭제할 수 있습니다(실수로 플러시올 등))
단점:
(1) AOF 파일이 다음보다 큽니다. RDB 파일이며 복구 속도가 느립니다.
(2) 데이터 세트가 크면 시작 효율성이 rdb보다 낮습니다.
(1) 마스터가 메모리 스냅샷을 작성하지 않는 것이 가장 좋습니다. 마스터가 메모리 스냅샷을 작성하는 경우 save 명령은 메인 스레드의 작업을 차단하는 rdbSave 함수를 예약합니다. .스냅샷이 크면 성능에 미치는 영향이 매우 크고 간헐적으로 서비스가 중단됩니다
(2) 중요한 데이터의 경우 슬레이브에서 AOF 백업 데이터를 활성화하고 1초에 한 번씩 동기화하도록 정책이 설정됩니다.
(3) 마스터-슬레이브 복제 속도를 높이려면 연결 안정성을 보장하기 위해 마스터와 슬레이브가 동일한 LAN에 있는 것이 가장 좋습니다
(4) 마스터 라이브러리에 슬레이브를 추가하지 마십시오.
(5) 마스터-슬레이브 복제에 그래프 구조를 사용하지 말고 단방향 연결 목록을 사용하십시오. 구조가 더 안정적입니다. 즉, Master
(1) 예약 삭제: 키 만료 시간을 설정하면서 타이머(타이머)를 생성하여 키 만료 시간이 되면 타이머가 즉시 키 삭제를 수행하도록 합니다.
(2) 지연 삭제: 키가 만료되도록 두고, 키 공간에서 키를 가져올 때마다 획득한 키가 만료되었는지 확인하고, 만료되지 않은 경우 키를 삭제하고, 키를 반환합니다. 열쇠.
(3) 정기 삭제: 프로그램은 가끔씩 데이터베이스를 확인하고 만료된 키를 삭제합니다. 삭제할 만료된 키 수와 확인할 데이터베이스 수를 결정하는 것은 알고리즘에 달려 있습니다.
휘발성-lru: 만료 시간이 설정된 데이터 세트(server.db[i].expires)에서 가장 최근에 사용된 데이터를 선택하여 제거합니다
휘발성 -ttl : 만료시간이 설정된 데이터셋(server.db[i].expires)에서 만료될 데이터를 선택하여 제거
휘발성-random : 만료시간이 설정된 데이터셋을 선택(서버) .db[i].expired)
allkeys-lru: 데이터 세트(server.db[i].dict)에서 가장 최근에 사용된 데이터를 선택하여 제거합니다.
allkeys-random: 데이터 세트(server.db)에서 [i] .dict) no-enviction(eviction): 데이터 제거를 금지합니다.
여기서 6가지 메커니즘에 주목하세요. 휘발성 및 allkeys는 만료 시간이 있는 데이터 세트에서 데이터를 제거할지 아니면 모든 데이터 세트에서 데이터를 제거할지 여부를 지정합니다. , 다음 lru, ttl 및 random은 세 가지 다른 제거 전략과 절대 재활용되지 않는 no-enviction 전략입니다.
정책 규칙 사용:
(1) 데이터가 멱법칙 분포를 나타내는 경우, 즉 일부 데이터 액세스 빈도가 높고 일부 데이터 액세스 빈도가 낮은 경우 allkeys-lru를 사용하세요
(2) 데이터가 즉, 모든 데이터 액세스 빈도가 동일하다면 allkeys-random을 사용하세요
답변: 가장 빠른 읽기 및 쓰기 속도를 달성하기 위해 Redis는 모든 데이터를 메모리로 읽고 데이터를 디스크에 비동기식으로 씁니다. 그래서 Redis는 빠른 속도와 데이터 지속성의 특징을 가지고 있습니다. 데이터가 메모리에 저장되지 않으면 디스크 I/O 속도가 Redis 성능에 심각한 영향을 미칩니다. 오늘날, 메모리가 점점 저렴해지면 redis가 점점 더 인기를 끌 것입니다. 사용되는 최대 메모리가 설정되면 기존 데이터 레코드 수가 메모리 제한에 도달한 후에는 새 값을 삽입할 수 없습니다.
답변: Redis는 마스터-슬레이브 동기화와 슬레이브-슬레이브 동기화를 사용할 수 있습니다. 첫 번째 동기화 중에 기본 노드는 bgsave를 수행하고 후속 수정 작업을 메모리 버퍼에 기록합니다. 완료 후 전체 rdb 파일은 복제본 노드에 동기화되고, 복제본 노드는 rdb 이미지를 로드합니다. 기억 속으로. 로딩이 완료된 후 해당 기간 동안 수정된 작업 기록을 레플리카 노드에 동기화하여 재생하도록 마스터 노드에 통보하고 동기화 과정이 완료됩니다.
답변: 파이프라인에서 실행되는 명령 간에 인과 관계가 없는 경우 여러 IO 왕복 시간을 1회로 줄일 수 있습니다. 스트레스 테스트를 위해 redis-benchmark를 사용할 때 redis의 QPS 피크 값에 영향을 미치는 중요한 요소는 파이프라인 배치 명령의 수임을 알 수 있습니다.
(1) Redis Sentinal은 고가용성에 중점을 두고 마스터가 다운되면 자동으로 슬레이브를 마스터로 승격시켜 서비스를 계속 제공합니다.
(2) Redis 클러스터는 확장성에 중점을 둡니다. 단일 Redis 메모리가 부족할 경우 클러스터를 샤드 스토리지로 사용합니다.
답변: 복제 모델이 없는 세 개의 노드 A, B, C가 있는 클러스터에서 노드 B에 장애가 발생하면 전체 클러스터는 5501-11000 범위의 슬롯이 부족하여 사용할 수 없다고 생각합니다.
답변: Redisson, Jedis, 양상추 등 Redisson이 정식으로 권장됩니다.
Jedis는 Redis에 의해 Java로 구현된 클라이언트이며 해당 API는 Redis 명령에 대해 상대적으로 포괄적인 지원을 제공합니다. Redisson은 Jedis에 비해 분산되고 확장 가능한 Java 데이터 구조를 구현하지만 문자열 작업을 지원하지 않습니다. 정렬, 트랜잭션, 파이프라인, 파티션과 같은 Redis 기능을 지원하지 않습니다.
Redisson의 목적은 Redis에서 사용자의 우려사항을 분리하여 사용자가 비즈니스 로직 처리에 더 집중할 수 있도록 하는 것입니다.
비밀번호 설정: config set requirepass 123456
인증 비밀번호: auth 123456
Redis 클러스터는 일관된 해싱을 사용하지 않지만 해시 슬롯 개념을 도입합니다. Redis 클러스터에는 16384개의 해시 슬롯이 있습니다. 각 키는 CRC16 확인 및 모듈로 16384를 통과하여 배치할 슬롯을 결정합니다. 클러스터는 해시 슬롯의 일부를 담당합니다.
답변: 일부 노드가 실패하거나 대부분의 노드가 통신할 수 없는 경우에도 클러스터를 계속 사용할 수 있도록 하기 위해 클러스터는 마스터-슬레이브 복제 모델을 사용하며 각 노드에는 N-1 복제본이 있습니다. Redis 클러스터에서 쓰기 작업이 손실됩니까? 왜?
23. Redis 클러스터는 어떻게 복제되나요?
24. Redis 클러스터의 최대 노드 수는 몇 개입니까?
25. Redis 클러스터용 데이터베이스를 선택하는 방법은 무엇입니까?
26. Redis의 연결성을 테스트하는 방법은 무엇입니까?
27. Redis 트랜잭션을 이해하는 방법은 무엇입니까?
28. Redis 트랜잭션과 관련된 명령은 무엇입니까?
29, Redis 키의 만료 시간과 영구 유효성을 각각 설정하는 방법은 무엇입니까?
답변: 해시를 최대한 사용하세요. 해시 테이블(즉, 해시 테이블에 저장된 숫자가 작음)은 매우 작은 메모리를 사용하므로 데이터 모델을 최대한 해시 테이블로 추상화해야 합니다. 예를 들어, 웹 시스템에 사용자 개체가 있는 경우 사용자의 이름, 성, 이메일, 비밀번호에 대해 별도의 키를 설정하지 말고, 대신 모든 사용자 정보를 해시 테이블에 저장하세요.
A: 클라이언트가 새 명령을 실행하고 새 데이터를 추가했습니다. Redi는 메모리 사용량을 확인하여 maxmemory 제한보다 큰 경우 설정된 정책에 따라 재활용합니다. 새로운 명령이 실행됩니다. 그래서 우리는 지속적으로 경계에 도달한 다음 계속해서 경계 아래로 다시 재활용함으로써 메모리 한계의 경계를 넘고 있습니다. 명령 결과로 인해 많은 양의 메모리가 사용되는 경우(예: 큰 세트의 교차점을 새 키에 저장하는 경우) 이 메모리 사용량으로 인해 메모리 제한이 초과되는 데 오랜 시간이 걸리지 않습니다.
답변: 32비트 Redis 인스턴스를 사용하는 경우 일반적으로 작은 Key-Value가 많이 포함될 수 있으므로 Hash, list, sorted set, set 등과 같은 컬렉션 유형 데이터를 잘 활용할 수 있습니다. 보다 컴팩트한 방식으로 함께 저장됩니다.
답변: 설정된 상한에 도달하면 Redis write 명령은 오류 메시지를 반환합니다(그러나 read 명령은 여전히 정상적으로 반환될 수 있습니다.) 또는 Redis를 캐시로 사용하여 Redis가 구성 제거 메커니즘을 사용할 수 있습니다. 메모리 상한에 도달하면 플러시됩니다. 오래된 콘텐츠를 제거합니다.
A: 이론적으로 Redis는 최대 232개의 키를 처리할 수 있으며 실제 테스트에서 각 인스턴스는 최소 2억 5천만 개의 키를 저장했습니다. 우리는 더 큰 값을 테스트하고 있습니다. 모든 목록, 집합 및 정렬된 집합은 232개의 요소를 보유할 수 있습니다. 즉, Redis의 저장 한도는 시스템에서 사용 가능한 메모리 양입니다.
답변: Redis 메모리 데이터 세트의 크기가 특정 크기로 증가하면 데이터 제거 전략이 구현됩니다.
관련 지식: Redis는 6가지 데이터 제거 전략을 제공합니다.
휘발성-lru: 만료 시간이 설정된 데이터 세트(server.db[i].expires)에서 가장 최근에 사용된 데이터를 선택하여 제거합니다.
휘발성- ttl : 만료시간이 설정된 데이터셋(server.db[i].expires)에서 만료될 데이터를 선택하여 제거
휘발성-random : 만료시간이 설정된 데이터셋(server.db[i)을 선택 ].expires) 제거할 데이터 세트에서 데이터 선택
allkeys-lru: 제거할 데이터 세트(server.db[i].dict)에서 가장 최근에 사용된 데이터 선택
allkeys-random: 데이터 선택 데이터 세트(server.db[i].dict)에서 임의로 데이터 제거
no-enviction(eviction) 선택: 데이터 제거 금지
1. 세션 캐시
Redis 사용에 가장 일반적으로 사용되는 시나리오 중 하나는 세션 캐시입니다. Memcached와 같은 다른 저장소에 비해 Redis를 사용한 캐싱 세션의 장점은 Redis가 지속성을 제공한다는 것입니다. 엄격하게 일관성을 요구하지 않는 캐시를 유지할 때 대부분의 사람들은 사용자의 장바구니 정보가 모두 손실되면 불만을 품게 됩니다. 그래도 여전히 그럴까요? 다행히 Redis가 수년에 걸쳐 개선됨에 따라 Redis를 적절하게 사용하여 세션 문서를 캐시하는 방법을 쉽게 알아낼 수 있습니다. 잘 알려진 상용 플랫폼인 Magento도 Redis용 플러그인을 제공합니다.
2. FPC(전체 페이지 캐시)
Redis는 기본 세션 토큰 외에도 매우 간단한 FPC 플랫폼도 제공합니다. 일관성 문제로 돌아가서, Redis 인스턴스가 다시 시작되더라도 사용자는 디스크 지속성으로 인해 페이지 로딩 속도가 떨어지는 것을 볼 수 없습니다. 이는 PHP 로컬 FPC와 유사하게 크게 개선되었습니다. Magento를 다시 예로 들면, Magento는 Redis를 전체 페이지 캐시 백엔드로 사용할 수 있는 플러그인을 제공합니다. 또한 WordPress 사용자를 위해 Pantheon에는 매우 유용한 플러그인 wp-redis가 있어 탐색한 페이지를 최대한 빨리 로드하는 데 도움이 됩니다.
3. Queue
메모리 저장 엔진 분야에서 Redis의 가장 큰 장점 중 하나는 Redis를 좋은 메시지 큐 플랫폼으로 사용할 수 있도록 하는 목록 및 설정 작업을 제공한다는 것입니다. Redis가 대기열로 사용하는 작업은 목록에서 로컬 프로그래밍 언어(예: Python)의 푸시/팝 작업과 유사합니다. Google에서 "Redis 대기열"을 빠르게 검색하면 수많은 오픈 소스 프로젝트를 즉시 찾을 수 있습니다. 이러한 프로젝트의 목적은 Redis를 사용하여 다양한 대기열 요구 사항을 충족하는 매우 좋은 백엔드 도구를 만드는 것입니다. 예를 들어 Celery에는 Redis를 브로커로 사용하는 백엔드가 있습니다. 여기에서 볼 수 있습니다.
4, 리더보드/카운터
Redis는 메모리에서 숫자를 늘리거나 줄이는 작업을 매우 잘 구현합니다. 세트와 정렬 세트도 이러한 작업을 수행하는 것을 매우 간단하게 해줍니다. Redis는 이 두 가지 데이터 구조를 제공합니다. 따라서 정렬된 세트에서 상위 10명의 사용자를 얻으려면 이를 "user_scores"라고 부르겠습니다. 다음과 같이 하면 됩니다. 물론 이는 사용자의 점수를 기반으로 수행한다고 가정합니다. 사용자와 사용자의 점수를 반환하려면 다음과 같이 실행해야 합니다. ZRANGE user_scores 0 10 WITHSCORES Agora Games는 Ruby로 구현된 좋은 예이며 순위는 Redis를 사용하여 데이터를 저장합니다. 여기에서 확인할 수 있습니다.
5. 게시/구독
마지막(그러나 가장 중요한 것은) Redis의 게시/구독 기능입니다. 게시/구독에는 실제로 많은 사용 사례가 있습니다. 사람들이 이를 소셜 네트워크 연결에서 게시/구독 기반 스크립트의 트리거로 사용하고 심지어 Redis의 게시/구독 기능을 사용하여 채팅 시스템을 구축하는 것을 보았습니다!
답변: 지정된 모드의 키 목록을 검색하려면 키 명령을 사용하세요.
그러자 상대방은 이렇게 물었습니다. 이 Redis가 온라인 비즈니스에 서비스를 제공하고 있다면, 키 명령을 사용할 때 어떤 문제가 있나요?
이제 Redis의 주요 기능인 Redis는 단일 스레드라는 점에 답해야 합니다. 키 명령으로 인해 스레드가 일정 시간 동안 차단되고 명령이 실행될 때까지 온라인 서비스가 일시 중지됩니다. 이때, scan 명령을 사용하면 차단 없이 지정된 모드의 키 목록을 추출할 수 있지만, 클라이언트에서 한 번만 수행하면 어느 정도 중복될 가능성이 있지만, 전체 시간이 소요됩니다. 직접 사용하는 것보다 길어야 합니다.
답변: 많은 수의 키 만료 시간을 너무 집중적으로 설정하면 만료 시 redis가 잠시 지연될 수 있습니다. 일반적으로 만료 시간을 분산시키려면 시간에 임의의 값을 추가해야 합니다.
답변: 일반적으로 목록 구조는 대기열로 사용되며 rpush는 메시지를 생성하고 lpop은 메시지를 소비합니다. lpop에 메시지가 없으면 잠시 잠자기 후 다시 시도해 보세요. 상대방이 수면을 사용할 수 있는지 묻는다면 어떻게 되나요? list에는 blpop이라는 명령도 있는데 메시지가 없으면 메시지가 도착할 때까지 차단됩니다. 한 번 생산해서 여러 번 소비할 수 있는지 상대방이 묻는다면 어떻게 될까요? 게시/구독 주제 구독자 모델을 사용하면 1:N 메시지 대기열을 구현할 수 있습니다.
Pub/Sub의 단점이 무엇인지 상대방이 묻는다면?
소비자가 오프라인이 되면 생성된 메시지가 손실되므로 RabbitMQ와 같은 전문적인 메시지 대기열을 사용해야 합니다.
상대방이 redis가 지연 대기열을 어떻게 구현하는지 묻는다면?
이제 면접관을 때려죽이고 싶은 것 같군요. 야구방망이를 손에 쥐고 있으면서 왜 그렇게 세세하게 질문하시나요? 그러나 당신은 매우 자제하고 침착하게 대답했습니다. sortedset을 사용하고, 타임스탬프를 점수로 사용하고, 메시지 내용을 키로 사용하고, zadd를 호출하여 메시지를 생성하고, 소비자는 zrangebyscore 명령을 사용하여 N초 전에 폴링하는 데이터를 얻습니다. 처리를 위해. 이때 면접관이 몰래 엄지손가락을 치켜세웠습니다. 하지만 그가 몰랐던 것은 당신이 지금 이 순간 의자 뒤에서 가운데 손가락을 들고 있다는 사실이었다.
먼저 setnx를 사용하여 잠금을 잡은 후, 만료를 사용하여 잠금 해제를 잊어버리지 않도록 잠금에 만료 시간을 추가하세요.
이때, 상대방은 귀하의 답변이 좋다고 말하고, setnx 이후에expired를 실행하기 전에 프로세스가 예기치 않게 충돌하거나 유지 관리를 위해 다시 시작해야 하는 경우 어떻게 됩니까? 이때 놀라운 피드백을 주어야 한다. 아, 그래, 이 자물쇠는 절대로 풀리지 않을 것이다. 그런 다음 머리를 긁적이며 다음 결과가 자신의 주도권인 것처럼 잠시 생각한 다음 대답해야 합니다. set 명령에는 매우 복잡한 매개변수가 있다는 것을 기억합니다. 이 명령은 setnx를 설정하고 만료될 수 있어야 합니다. 동시에 하나의 지침으로 결합하여 사용하세요! 이때 상대방은 미소를 지으며 마음 속으로 조용히 말하기 시작할 것입니다. 이 사람은 나쁘지 않습니다.
더 많은 프로그래밍 관련 지식을 알고 싶다면 프로그래밍 입문을 방문해 주세요! !
위 내용은 놓칠 수 없는 Redis 인터뷰 질문 40개(답변 및 마인드맵 포함)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
