Redis에서 가장 일반적인 인터뷰 질문

PHP 프로그래머 인터뷰 중에 Redis에 대한 인터뷰 질문을 접할 수도 있습니다. 이 기사는 모든 사람에게 도움이 되기를 바라며 Redis에서 가장 일반적인 인터뷰 질문을 주로 공유합니다.

특별 추천: 2020 redis 인터뷰 질문(최신)

2. Reids의 특징

Redis는 기본적으로 Memcached와 마찬가지로 Key-Value 유형의 메모리 내 데이터베이스이며 전체 데이터베이스가 로드됩니다. 작업은 메모리에서 수행되며 데이터베이스 데이터는 저장을 위해 주기적으로 비동기 작업을 통해 하드 디스크로 플러시됩니다. 순수한 메모리 작업이기 때문에 Redis는 성능이 뛰어나고 초당 100,000회 이상의 읽기 및 쓰기 작업을 처리할 수 있는 것으로 알려진 가장 빠른 Key-Value DB입니다.

　Redis의 우수성은 성능뿐만 아니라 다양한 데이터 구조 저장을 지원한다는 점이 가장 큰 장점입니다. 또한, 1MB의 데이터만 저장할 수 있는 memcached와 달리 단일 값의 최대 한도는 1GB입니다. 따라서 Redis는 List를 사용하여 FIFO 이중 연결 목록 만들기, 경량 고성능 메시지 대기열 서비스 구현, Set을 사용하여 고성능 태그 시스템 만들기 등과 같은 유용한 기능을 수행하는 데 사용할 수 있습니다. . 또한 Redis는 저장된 Key-Value의 만료 시간을 설정할 수도 있으므로 memcached의 향상된 버전으로도 사용할 수 있습니다.

Redis의 가장 큰 단점은 데이터베이스 용량이 물리적 메모리에 의해 제한되어 대용량 데이터의 고성능 읽기 및 쓰기에 사용할 수 없다는 것입니다. 따라서 Redis에 적합한 시나리오는 주로 고성능 작업 및 계산으로 제한됩니다. 더 적은 양의 데이터.

3. Redis를 사용하면 어떤 이점이 있나요?

(1) HashMap과 마찬가지로 데이터가 메모리에 저장되기 때문에 빠릅니다. HashMap의 장점은 검색 및 연산의 시간 복잡도가 O(1) 이라는 것입니다.

(3) 트랜잭션 지원, 작업은 모두 원자성입니다. 소위 원자성은 데이터에 대한 모든 변경 사항이 실행되거나 전혀 실행되지 않음을 의미합니다.
(4) 풍부한 기능: 사용할 수 있습니다. 캐싱, 메시징, 키 만료 시간을 설정하면 만료 후 자동으로 삭제됩니다

　　　　(1) memcached의 모든 값은 간단한 문자열이며, 이를 대체하는 redis는 더 풍부한 데이터 유형을 지원합니다.　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　uucessous in in memcached >> (1) memcached의 모든 값은 단순 문자열입니다. 이를 대체한 redis는 더 풍부한 데이터 유형을 지원합니다.

　　1) 저장 방법 Memecache는 모든 데이터를 메모리에 저장합니다. 정전 후에는 데이터가 메모리 크기를 초과할 수 없습니다. Redis의 일부는 하드 디스크에 저장되어 데이터 지속성을 보장합니다.

　　3) 사용되는 기본 모델이 다릅니다. 기본 구현 방법과 클라이언트와의 통신을 위한 애플리케이션 프로토콜이 다릅니다. Redis는 자체 VM 메커니즘을 직접 구축했습니다. 일반 시스템이 시스템 기능을 호출하면 이동 및 요청에 일정 시간이 낭비되기 때문입니다.

　　1).Master는 메모리 스냅샷을 작성하고 save 명령은 스냅샷이 상대적으로 큰 경우 기본 스레드의 작업을 차단하는 rdbSave 기능을 예약합니다. , 성능에 미치는 영향은 매우 큽니다. 서비스가 간헐적으로 중단되므로 마스터가 메모리 스냅샷을 작성하지 않는 것이 가장 좋습니다.

　　2) 마스터 AOF 지속성. AOF 파일을 다시 작성하지 않으면 이 지속성 방법은 성능에 최소한의 영향을 미치지만 AOF 파일이 너무 크면 복구 속도에 영향을 미칩니다. 마스터 재시작. 메모리 스냅샷 및 AOF 로그 파일을 포함하여 마스터에서 지속성 작업을 수행하지 않는 것이 가장 좋습니다. 특히 데이터가 중요한 경우 슬레이브는 AOF 백업 데이터를 활성화해야 하며 전략은 다음과 같습니다. 초당 한 번씩 동기화합니다.

　　3).마스터는 AOF 파일을 다시 쓰기 위해 BGREWRITEAOF를 호출합니다. AOF는 다시 쓰는 동안 많은 양의 CPU와 메모리 리소스를 차지하므로 과도한 서비스 부하가 발생하고 단기적인 서비스 중단이 발생합니다.

　　4) Redis 마스터-슬레이브 복제의 성능 문제. 마스터-슬레이브 복제 속도와 연결 안정성을 위해 슬레이브와 마스터가 동일한 LAN에 있는 것이 가장 좋습니다

　관련 지식: Redis 메모리 데이터 세트의 크기가 특정 크기로 증가하면 데이터 제거 전략(재활용 전략)이 구현됩니다. Redis는 6가지 데이터 제거 전략을 제공합니다.

• 휘발성-lru: 제거할 만료 시간이 설정된 데이터 세트(server.db[i].expires)에서 가장 최근에 사용된 데이터를 선택합니다. : 만료시간이 설정되어 있는 데이터셋(server.db[i].expires) 중 만료될 데이터를 선택하여 제거합니다

• 휘발성-random : 만료시간이 설정된 데이터셋(server.expires)을 선택합니다. db[i].expires)

• allkeys-lru: 데이터 세트(server.db[i].dict)에서 가장 최근에 사용된 데이터를 선택하여 제거합니다.

• allkeys-random: 가장 최근에 사용된 데이터를 선택합니다. 데이터 세트(server.db) [i].dict) 제거할 데이터를 선택하세요.

• no-enviction(eviction): 데이터를 제거하는 것은 금지되어 있습니다.

• 8. 언어로 악성 로그인 방지 코드 구현,
1시간으로 제한 각 사용자 ID는 최대 5회까지만 로그인할 수 있습니다. 특정 로그인 기능이나 기능의 경우 빈 기능을 사용하면 되며, 자세히 작성할 필요가 없습니다.

　 목록으로 구현: 목록의 각 요소는 최근 5번째 로그인 시간과 현재 시간의 차이가 1시간 이내인 경우 Python으로 작성된 코드는 다음과 같습니다.

#!/usr/bin/env python3
import redis  
import sys  
import time  
 
r = redis.StrictRedis(host=’127.0.0.1′, port=6379, db=0)  
try:       
    id = sys.argv[1]
except:      
    print(‘input argument error’)    
    sys.exit(0)  
if r.llen(id) >= 5 and time.time() – float(r.lindex(id, 4)) <= 3600:      
    print(“you are forbidden logining”)
else:       
    print(‘you are allowed to login’)    
    r.lpush(id, time.time())    
    # login_func()

　Redis는 가장 빠른 읽기 및 쓰기 속도를 달성하기 위해 모든 데이터를 메모리에 읽고 디스크에 씁니다. 비동기적으로. 그래서 Redis는 빠른 속도와 데이터 지속성의 특징을 가지고 있습니다. 데이터가 메모리에 저장되지 않으면 디스크 I/O 속도가 Redis 성능에 심각한 영향을 미칩니다. 오늘날, 메모리가 점점 저렴해지면 redis가 점점 더 인기를 끌 것입니다.
　 최대 사용 메모리가 설정되어 있으면 데이터 레코드 수가 메모리 제한에 도달한 후에는 새 값을 삽입할 수 없습니다.

　 Redis는 큐 기술을 사용하여 동시 액세스를 직렬 액세스로 전환하여 기존 데이터베이스 직렬 제어의 오버헤드를 제거합니다

　 Redis는 대기열 모드를 사용하여 동시 액세스를 직렬 액세스로 전환하는 단일 프로세스 단일 스레드 모드입니다. Redis 자체에는 잠금 개념이 없으며 Redis는 여러 클라이언트 연결을 위해 경쟁하지 않습니다. 그러나 Jedis 클라이언트가 동시에 Redis에 액세스하는 경우 연결 시간 초과, 데이터 변환 오류, 차단, 클라이언트 연결 종료 등의 문제가 발생할 수 있습니다. 모두 클라이언트 연결 혼란으로 인해 발생합니다. 이 문제에 대한 해결책은 두 가지가 있습니다: 　　1. 클라이언트 관점에서 각 클라이언트가 Redis와 정상적이고 질서 있게 통신할 수 있도록 연결을 풀링하고 동기화된 내부 잠금을 클라이언트 읽기 및 읽기에 사용합니다. Redis 작업을 작성합니다.

　 2. 서버 관점에서 setnx를 사용하여 잠금을 구현합니다.

12. Redis 사물 CAS(check-and-set 작업은 낙관적 잠금 구현)에 대한 이해?

　 다른 많은 데이터베이스와 마찬가지로 Redis도 NoSQL 데이터베이스로 트랜잭션 메커니즘을 제공합니다. Redis에서는 MULTI/EXEC/DISCARD/WATCH 네 가지 명령이 트랜잭션 구현의 초석입니다. 관계형 데이터베이스 개발 경험이 있는 개발자에게는 이 개념이 낯설지 않다고 생각합니다. 그럼에도 불구하고 Redis의 트랜잭션 구현 기능을 간략하게 나열하겠습니다.

　　2) 관계형 데이터베이스의 트랜잭션과 비교하여 Redis 트랜잭션에서는 명령이 실행되지 않으면 후속 명령이 계속 실행됩니다. 　　3) 관계형 데이터베이스 개발 경험이 있는 사람이라면 "BEGIN TRANSACTION" 문으로 이해할 수 있는 MULTI 명령을 통해 트랜잭션을 시작할 수 있습니다. 이 명령문 이후에 실행되는 명령은 트랜잭션 내의 작업으로 간주됩니다. 마지막으로 EXEC/DISCARD 명령을 실행하여 트랜잭션 내의 모든 작업을 커밋/롤백할 수 있습니다. 이 둘

　　　Redis 명령은 관계형 데이터베이스의 COMMIT/ROLLBACK 문과 동일하다고 간주될 수 있습니다.
　　4) 트랜잭션이 시작되기 전에 클라이언트와 서버 사이에 통신 장애가 발생하고 네트워크 연결이 끊어지면 이후에 실행될 모든 명령문은 서버에서 실행되지 않습니다. 그러나 클라이언트가 EXEC 명령을 실행한 후 네트워크 중단 이벤트가 발생하면 트랜잭션의 모든 명령이 서버에 의해 실행됩니다.
　　5) Append-Only 모드를 사용하는 경우 Redis는 write 시스템 함수를 호출하여 이 호출에서 트랜잭션의 모든 쓰기 작업을 디스크에 씁니다. 그러나 쓰기 프로세스 중에 정전으로 인한 가동 중지 시간과 같은 시스템 충돌이 발생하는 경우 현재 데이터의 일부만 디스크에 기록될 수 있으며 데이터의 다른 부분은 손실됩니다.

　　　Redis 서버는 다시 시작할 때 필요한 일련의 일관성 검사를 수행합니다. 유사한 문제가 발견되면 즉시 종료되고 해당 오류 메시지가 표시됩니다. 이때 Redis 툴킷에 제공되는 redis-check-aof 도구를 최대한 활용해야 합니다. 이 도구는 데이터 불일치 오류를 찾고 작성된 데이터의 일부를 롤백하는 데 도움이 될 수 있습니다. 복구 후 Redis 서버를 다시 시작할 수 있습니다.

　Redis 트랜잭션에서는 WATCH 명령을 사용하여 CAS(check-and-set) 기능을 제공할 수 있습니다. 트랜잭션이 실행되기 전에 WATCH 명령을 통해 여러 키를 모니터링한다고 가정합니다. WATCH 이후 키 값이 변경되면 EXEC 명령으로 실행된 트랜잭션이 중단되고 호출자에게 알리기 위해 Null 다중 대량 응답이 반환됩니다.

실행이 실패했습니다. 예를 들어, 키 값의 원자적 증가를 완료하기 위해 Redis에서 incr 명령이 제공되지 않는다고 다시 가정합니다. 이 기능을 구현하려면 해당 코드를 직접 작성하면 됩니다. 의사 코드는 다음과 같습니다.

　val = val + 1
　SET mykey $val
　위 코드는 클라이언트가 여러 개인 경우 단일 연결의 경우에만 실행 결과가 정확하다는 것을 보장할 수 있습니다. 동시에 이 코드 조각이 동시에 실행되면 다중 스레드 프로그램에서 자주 발생하는 오류 시나리오, 즉 경쟁 조건이 발생합니다. 예를 들어 클라이언트 A와 B는 동시에 mykey의 원래 값을 읽습니다. 값이 10이라고 가정합니다. 그 후 두 클라이언트 모두 값에 1을 추가하고 이를 Redis 서버에 다시 설정합니다. 결과는 우리가 생각한 12가 아니라 11입니다. 비슷한 문제를 해결하려면 WATCH 명령의 도움이 필요합니다. 다음 코드를 참조하세요.
　WATCH mykey
　val = GET mykey
　val = val + 1
　MULTI
　SET mykey $val
　EXEC
이전 코드와 다름 , 새로운 코드는 mykey 값을 얻기 전에 먼저 WATCH 명령을 통해 키를 모니터링한 다음 트랜잭션에서 set 명령을 둘러쌉니다. 이렇게 하면 각 연결이 EXEC를 실행하기 전에 현재 mykey 값을 얻었는지 효과적으로 확인할 수 있습니다. 연결이 다른 사람에 의해 변경된 경우 연결된 클라이언트가 수정된 경우 현재 연결의 EXEC 명령이 실행되지 않습니다. 이러한 방식으로 호출자는 반환 값을 판단한 후 val이 성공적으로 재설정되었는지 여부를 알 수 있습니다.

1. 스냅샷

　작동 원리
　． Redis 포크.
　　． 하위 프로세스는 임시 RDB 파일에 데이터를 쓰기 시작합니다.
　． 하위 프로세스가 RDB 파일 쓰기를 마치면 이전 파일을 새 파일로 바꿉니다.
　． 이 방법을 사용하면 Redis가 쓰기 중 복사 기술을 사용할 수 있습니다.
2. AOF
스냅샷 모드는 그다지 강력하지 않습니다. 시스템이 중지되거나 Redis가 실수로 종료되면 Redis에 기록된 마지막 데이터가 손실됩니다. 이는 일부 애플리케이션에서는 큰 문제가 아닐 수 있지만 높은 신뢰성이 요구되는 애플리케이션의 경우
　Redis는 적합한 선택이 아닙니다.
　추가 전용 파일 모드는 또 다른 옵션입니다.
　 구성 파일에서 AOF 모드를 켤 수 있습니다.
3. 가상 메모리 모드
키가 작고 값이 클 때 VM을 사용하는 효과가 더 좋습니다.
키 이후에 더 많은 메모리가 절약되기 때문입니다. 잠시 동안 몇 가지 특별한 방법을 사용하여 큰 키를 큰 값으로 바꾸는 것을 고려할 수 있습니다. 예를 들어 키와 값을 새로운 값으로 결합하는 것을 고려할 수 있습니다.
　스왑에 액세스하도록 vm-max-threads 매개변수를 설정할 수 있습니다. 스레드 수는 시스템의 코어 수를 초과해서는 안 됩니다. 0으로 설정하면 스왑 파일의 모든 작업이 직렬로 수행되므로 지연이 발생할 수 있지만 데이터 무결성이 향상됩니다. .

직접 테스트해 보니 가상 메모리를 사용하는 성능도 좋은 것으로 나타났습니다. 데이터 양이 많은 경우 분산 또는 기타 데이터베이스를 고려할 수 있습니다.

15. Redis 캐시 무효화 전략 및 기본 키 무효화 메커니즘

캐시 시스템은 잘못된 데이터를 정기적으로 정리해야 하므로 기본 키 무효화 및
Redis에서는 수명이 있는 키를 휘발성이라고 합니다. 캐시를 생성할 때 해당 키의 수명을 설정하세요. 키가 만료되면(수명이 0) 삭제될 수 있습니다.
　1. 생존 시간에 영향을 미치는 일부 작업
　DEL 명령을 사용하여 키 전체를 삭제하여 생존 시간을 제거하거나 SET 및 GETSET 명령으로 원본 데이터를 덮어쓸 수 있습니다. 키와 다른 동일한 키 사용 키와 값을 덮어쓴 후에는 현재 데이터의 생존 시간이 달라집니다.
　예를 들어 키에 대해 INCR 명령을 실행하거나, 목록에 대해 LPUSH 명령을 실행하거나, 해시 테이블에 대해 HSET 명령을 실행하는 등의 작업은 키 자체의 생존 시간을 수정하지 않습니다. 반면에 RENAME을 사용하여 키 이름을 바꾸는 경우 이름이 바뀐 키의 생존 시간은 이름 바꾸기 전과 동일합니다.
RENAME 명령의 또 다른 가능성은 생존 시간이 있는 키의 이름을 생존 시간이 있는 another_key로 바꾸는 것입니다. 이때 이전 another_key(및 해당 생존 시간)는 삭제되고 이전 키의 이름이 변경됩니다. 는 another_key이므로 새로운 another_key의 생존 시간은 원래 키와 동일합니다. 키를 삭제하지 않고 키의 수명을 제거하여 키를 다시 영구 키로 만들려면 PERSIST 명령을 사용하십시오.
　2. 생존 시간을 업데이트하는 방법
　이미 생존 시간이 있는 키에 대해 EXPIRE 명령을 실행할 수 있으며, 새로 지정된 생존 시간이 이전 생존 시간을 대체합니다. 만료 시간의 정확도는 1ms 이내로 제어되었으며 기본 키 오류의 시간 복잡도는 O(1)입니다.
EXPIRE와 TTL 명령을 함께 사용하면 키의 현재 생존 시간을 확인할 수 있습니다. 설정이 성공하면 1을 반환하고, 키가 존재하지 않거나 키에 대해 생존 시간을 설정할 수 없으면 0을 반환합니다.
　최대 캐시 구성
　redis에서는 사용자가 최대 메모리 크기를 설정할 수 있습니다
　server.maxmemory
　기본값은 0이며, 최대 캐시는 지정되지 않습니다. 새 데이터가 추가되고 최대 메모리를 초과하면 Redis가 충돌합니다. 그러니 꼭 설정하세요. Redis 메모리 데이터 세트의 크기가 특정 크기로 증가하면 데이터 제거 전략이 구현됩니다.
　Redis는 6가지 데이터 제거 전략을 제공합니다.
　． 휘발성-lru: 만료 시간이 설정된 데이터 세트(server.db[i].expires)에서 최근에 가장 적게 사용된 데이터를 선택하여 제거합니다
　　． 휘발성-ttl: 만료 시간이 제거되도록 설정된 데이터 세트(server.db[i].expires)에서 만료 예정인 데이터를 선택합니다
　　． 휘발성-랜덤: 만료 시간이 설정된 데이터 세트(server.db[i].expires)에서 제거할 데이터를 무작위로 선택
　　． allkeys-lru: 데이터 세트(server.db[i].dict)에서 가장 최근에 사용된 데이터를 선택하여 제거
　． allkeys-random: 데이터 세트에서 제거할 데이터를 임의로 선택합니다(server.db[i].dict)
　　． no-enviction(eviction): 데이터를 추방하는 것은 금지되어 있습니다.
여기서 6가지 메커니즘에 주의하세요. Volatile 및 allkeys는 만료 시간이 있는 데이터 세트에서 데이터를 제거할지 아니면 다음 lru, ttl 및 모든 데이터 세트에서 데이터를 제거할지 여부를 지정합니다. 무작위는 세 가지 다른 제거 전략과 결코 재활용되지 않는 무권리 전략입니다.
　 사용 정책 규칙:
　 1. 데이터가 거듭제곱 법칙 분포를 나타내는 경우, 즉 일부 데이터 액세스 빈도가 높고 일부 데이터 액세스 빈도가 낮은 경우 allkeys-lru를 사용하세요
　 2. 데이터가 균등한 분포를 나타내는 경우, 즉, 모든 데이터 액세스 빈도가 모두 동일하면 allkeys-random을 사용하십시오.
세 가지 데이터 제거 전략:
ttl과 무작위는 이해하기 쉽고 구현하기 쉽습니다. 주된 이유는 Lru가 적어도 최근에 제거 전략을 사용했기 때문입니다. 설계는 만료 시간에 따라 키를 정렬한 다음 이를 제거하기 위해 첫 번째 유효하지 않은 키를 가져옵니다

16 redis에 가장 적합한 시나리오입니다

Redis는 모든 데이터 인 메모리 시나리오에 가장 적합합니다. Redis도 지속성 기능을 제공하지만 실제로는 전통적인 의미의 지속성과는 상당히 다른 디스크 기반 기능에 가깝습니다. Redis는 Memcached의 향상된 버전에 가깝습니다. 그러면 언제 Memcached를 사용해야 하고 언제 Redis를 사용해야 할까요? Redis와 Memcached의 차이점을 간단히 비교해 보면 대부분의 사람들은 다음과 같은 의견을 갖게 될 것입니다.
　1. Redis는 단순한 지원만 하는 것이 아닙니다. k/v 유형 데이터, 목록, 집합, zset, 해시 및 기타 데이터 구조에 대한 저장소도 제공합니다.
　2. Redis는 데이터 백업, 즉 마스터-슬레이브 모드에서의 데이터 백업을 지원합니다.
　3. Redis는 데이터 지속성을 지원하므로 데이터를 디스크 메모리에 보관하고 다시 시작할 때 사용하기 위해 다시 로드할 수 있습니다.
(1), 세션 캐시

Redis 사용에 가장 일반적으로 사용되는 시나리오 중 하나는 세션 캐시입니다. Redis를 사용하여 다른 스토리지(예: Memcached)보다 세션을 캐시할 때의 이점은 Redis가 지속성을 제공한다는 것입니다. 엄격하게 일관성을 요구하지 않는 캐시를 유지하다 보면 사용자의 장바구니 정보가 모두 사라지면 대부분의 사람들은 불만을 품게 될 것입니다. 이제

　 아직도 이렇겠습니까?

다행히 Redis가 수년에 걸쳐 개선됨에 따라 Redis를 올바르게 사용하여 세션 문서를 캐시하는 방법을 쉽게 파악할 수 있습니다. 잘 알려진 상용 플랫폼인 Magento도 Redis 플러그인을 제공합니다.

(2), FPC(Full Page Cache)
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"라고 부르겠습니다. 다음과 같이 실행하면 됩니다. 물론 이것은 사용자를 기반으로 한다고 가정합니다. 점수는 오름차순으로 정렬됩니다. 주문하다. 사용자와 사용자의 점수를 반환하려면 다음과 같이 실행해야 합니다.

　
　Agora Games는 Ruby로 구현된 좋은 예이며 순위는 Redis를 사용하여 데이터를 저장합니다. 여기에서 볼 수 있습니다.
(5), Publish/Subscribe
마지막(그러나 가장 중요한 것은) Redis의 게시/구독 기능입니다. 게시/구독에는 실제로 많은 사용 사례가 있습니다. 사람들이 이를 소셜 네트워크 연결에서 게시/구독 기반 스크립트의 트리거로 사용하고 심지어 Redis의 게시/구독 기능을 사용하여 채팅 시스템을 구축하는 것을 보았습니다! (아니요, 이것은 사실입니다. 확인할 수 있습니다.)
　Redis가 제공하는 모든 기능 중에서 사용자에게 이러한 다기능을 제공하지만 이것이 사람들이 가장 좋아하지 않는 기능이라고 생각합니다.

관련 권장 사항:

php의 redis에 대한 자세한 설명

php의 redis 적용 예

Redis의 일반적인 사용 시나리오 공유

위 내용은 Redis에서 가장 일반적인 인터뷰 질문의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!