이 기사에서는 Redis에 대한 관련 지식을 제공합니다. Redis의 장점과 특징을 주로 소개합니다. Redis는 ANSI C 언어로 작성된 오픈 소스이며 BSD 프로토콜을 준수하고 네트워크를 지원하며 메모리를 기반으로 할 수 있습니다. 분산 스토리지 데이터베이스에 대해 살펴보겠습니다. 모두에게 도움이 되기를 바랍니다.
추천 학습: Redis 동영상 튜토리얼
Remote DIctionary Server(Redis)는 Salvatore Sanfilippo가 작성한 키-값 저장 시스템으로 크로스 플랫폼 비관계형 데이터베이스입니다.
Redis는 ANSI C 언어로 작성된 오픈 소스 키-값 저장소 데이터베이스로, BSD 프로토콜을 준수하고 네트워크, 메모리 기반, 분산, 선택적 지속성을 지원하며 여러 언어로 API를 제공합니다.
Redis는 값이 문자열, 해시, 목록, 집합, 정렬된 집합 등의 유형이 될 수 있기 때문에 종종 데이터 구조 서버라고 합니다.
3. 단일 스레드를 사용하면 불필요한 컨텍스트 전환 및 경쟁 조건이 방지됩니다. CPU를 소비하는 여러 프로세스나 스레드로 인한 전환이 없으며 다양한 잠금 문제를 고려할 필요가 없습니다. 잠금 해제. 교착 상태로 인한 성능 소모 없음
4. 다중 채널 I/O 다중화 모델, 비차단 IO 사용
5. 클라이언트 간 통신을 위한 애플리케이션 프로토콜이 다릅니다. Redis는 자체 VM 메커니즘을 직접 구축합니다. 왜냐하면 일반 시스템이 시스템 기능을 호출하면 이동 및 요청에 일정량의 시간이 낭비되기 때문입니다.
6. O 다중화 모델
다중 채널 I/O 다중화 모델은 select, poll 및 epoll을 사용하여 여러 스트림의 I/O 이벤트를 동시에 모니터링합니다. 유휴 상태일 때 하나 이상의 스트림에 오류가 있는 경우 현재 스레드가 차단됩니다. I/O 이벤트가 발생하면 차단 상태에서 깨어나므로 프로그램은 모든 스트림을 폴링하고(epoll은 실제로 이벤트를 생성한 스트림만 폴링함) 준비된 스트림만 순서대로 처리합니다. 이 접근 방식은 많은 쓸모 없는 작업을 방지합니다.
** 여기서 "다중"은 여러 네트워크 연결을 의미하고 "재사용"은 동일한 스레드를 재사용하는 것을 의미합니다. **다중 채널 I/O 다중화 기술을 사용하면 단일 스레드가 여러 연결 요청을 효율적으로 처리할 수 있으며(네트워크 IO의 시간 소모 최소화) Redis는 메모리에서 데이터를 매우 빠르게 처리합니다. Redis 성능에 영향을 미치는 병목 현상이 발생하지 않도록 위의 사항이 주로 Redis의 높은 처리량에 기여합니다.
위의 모든 분석은 Redis가 빠른 분위기를 조성하기 위한 것임을 먼저 이해해야 합니다! 공식 FAQ에는 Redis가 메모리 기반 작업이기 때문에 CPU가 Redis의 병목 현상이 되지 않는다고 명시되어 있습니다. Redis의 병목 현상은 시스템 메모리 크기나 네트워크 대역폭 때문일 가능성이 높습니다. 싱글 스레딩은 구현하기 쉽고 CPU에 병목 현상이 발생하지 않으므로 싱글 스레드 솔루션을 채택하는 것이 논리적입니다(결국 멀티 스레딩을 사용하면 많은 문제가 발생합니다!).
redis 127.0.0.1:6379> SET rediskey redis OK redis 127.0.0.1:6379> GET rediskey "redis"
Redis 해시는 문자열 형식의 필드(field)와 값(value)의 매핑입니다. 특히 물건을 보관하는 데 적합합니다.
Redis의 각 해시는 232 - 1개의 키-값 쌍(40억 개 이상)을 저장할 수 있습니다.
Redis 목록은 삽입 순서로 정렬된 간단한 문자열 목록입니다. 목록의 헤드(왼쪽) 또는 꼬리(오른쪽)에 요소를 추가할 수 있습니다.
목록에는 최대 232 - 1개의 요소(4294967295, 목록당 40억 개 이상의 요소)가 포함될 수 있습니다.
redis 127.0.0.1:6379> LPUSH rediskey redis (integer) 1 redis 127.0.0.1:6379> LPUSH rediskey mongodb (integer) 2 redis 127.0.0.1:6379> LPUSH rediskey mysql (integer) 3 redis 127.0.0.1:6379> LRANGE rediskey 0 10 1) "mysql" 2) "mongodb" 3) "redis"
Redis의 Set은 순서가 지정되지 않은 문자열 유형의 모음입니다. 집합 구성원은 고유합니다. 즉, 집합에 중복 데이터가 나타날 수 없습니다.
컬렉션 개체의 인코딩은 intset 또는 hashtable일 수 있습니다.
Redis의 컬렉션은 해시 테이블을 통해 구현되므로 추가, 삭제, 검색의 복잡성은 O(1)입니다.
컬렉션의 최대 멤버 수는 232 - 1입니다(4294967295, 각 컬렉션은 40억 명 이상의 멤버를 저장할 수 있습니다).
redis 127.0.0.1:6379> SADD rediskey redis (integer) 1 redis 127.0.0.1:6379> SADD rediskey mongodb (integer) 1 redis 127.0.0.1:6379> SADD rediskey mysql (integer) 1 redis 127.0.0.1:6379> SADD rediskey mysql (integer) 0 redis 127.0.0.1:6379> SMEMBERS rediskey 1) "mysql" 2) "mongodb" 3) "redis"
Redis의 정렬된 집합도 집합과 마찬가지로 문자열 형식 요소의 모음이며 중복 멤버를 허용하지 않습니다.
차이점은 각 요소가 이중 유형 점수와 연관되어 있다는 것입니다. Redis는 점수를 사용하여 컬렉션의 구성원을 작은 것부터 큰 것까지 정렬합니다.
주문한 세트의 구성원은 고유하지만 점수는 반복될 수 있습니다.
세트는 해시 테이블을 통해 구현되므로 추가, 삭제, 검색의 복잡성은 O(1)입니다. 컬렉션의 최대 구성원 수는 232 - 1(4294967295, 각 컬렉션은 40억 명 이상의 구성원을 저장할 수 있음)입니다.
Redis는 버전 2.8.9에 HyperLogLog 구조를 추가했습니다.
Redis HyperLogLog는 카디널리티 통계에 사용되는 알고리즘입니다. HyperLogLog의 장점은 입력 요소의 수나 양이 매우 클 때 카디널리티를 계산하는 데 필요한 공간이 항상 고정되어 매우 작다는 것입니다.
Redis에서 각 HyperLogLog 키에는 거의 2^64개 요소의 카디널리티를 계산하는 데 12KB의 메모리만 필요합니다. 이는 카디널리티를 계산할 때 더 많은 메모리를 소비하는 컬렉션과 뚜렷한 대조를 이룹니다. 요소가 많을수록 더 많은 메모리가 소비됩니다.
그러나 HyperLogLog는 입력 요소를 기반으로 카디널리티만 계산하고 입력 요소 자체를 저장하지 않기 때문에 HyperLogLog는 입력의 각 요소를 컬렉션처럼 반환할 수 없습니다.
예를 들어 데이터 세트가 {1, 3, 5, 7, 5, 7, 8}이면 이 데이터 세트의 카디널리티 세트는 {1, 3, 5,7, 8}, 카디널리티(반복되지 않는 요소)는 5입니다. 카디널리티 추정은 허용 가능한 오류 범위 내에서 카디널리티를 빠르게 계산하는 것입니다.
다음 예는 HyperLogLog의 작업 프로세스를 보여줍니다.
//添加指定元素到 HyperLogLog 中。 redis 127.0.0.1:6379> PFADD rediskey "redis" 1) (integer) 1 redis 127.0.0.1:6379> PFADD rediskey "mongodb" 1) (integer) 1 redis 127.0.0.1:6379> PFADD rediskey "mysql" 1) (integer) 1 //添加指定元素到 HyperLogLog 中。 redis 127.0.0.1:6379> PFCOUNT rediskey (integer) 3
Redis 게시 및 구독(pub/sub)은 메시지 통신 모델입니다. 발신자(pub)가 메시지를 보냅니다. 구독자(sub))가 메시지를 수신합니다.
Redis 클라이언트는 원하는 수의 채널을 구독할 수 있습니다.
다음 그림은 채널 Channel1과 이 채널을 구독하는 세 클라이언트(client2, client5 및 client1) 간의 관계를 보여줍니다.
다음 예는 게시 및 구독이 작동하는 방식을 보여줍니다. Two redis-cli 클라이언트를 열어야 합니다.
이 예에서는 runoobChat이라는 구독 채널을 만들었습니다.
redis 127.0.0.1:6379> SUBSCRIBE runoobChat Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "runoobChat" 3) (integer) 1
现在，我们先重新开启个 redis 客户端，然后在同一个频道 runoobChat 发布两次消息，订阅者就能接收到消息。
redis 127.0.0.1:6379> PUBLISH runoobChat "Redis PUBLISH test" (integer) 1 redis 127.0.0.1:6379> PUBLISH runoobChat "Learn redis by runoob.com" (integer) 1 # 订阅者的客户端会显示如下消息 1) "message" 2) "runoobChat" 3) "Redis PUBLISH test" 1) "message" 2) "runoobChat" 3) "Learn redis by runoob.com"
gif 演示如下：
runoobChat 频道。Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：
一个事务从开始到执行会经历以下三个阶段：
以下是一个事务的例子， 它先以 MULTI 开始一个事务， 然后将多个命令入队到事务中， 最后由 EXEC 命令触发事务， 一并执行事务中的所有命令：
redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days" QUEUED redis 127.0.0.1:6379> GET book-name QUEUED redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series" QUEUED redis 127.0.0.1:6379> SMEMBERS tag QUEUED redis 127.0.0.1:6379> EXEC 1) OK 2) "Mastering C++ in 21 days" 3) (integer) 3 4) 1) "Mastering Series" 2) "C++" 3) "Programming"
单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。
事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的回滚，也不会造成后续的指令不做。
这是官网上的说明 From redis docs on transactions:
It’s important to note that even when a command fails, all the other commands in the queue are processed – Redis will not stop the processing of commands.
比如：
redis 127.0.0.1:7000> multi OK redis 127.0.0.1:7000> set a aaa QUEUED redis 127.0.0.1:7000> set b bbb QUEUED redis 127.0.0.1:7000> set c ccc QUEUED redis 127.0.0.1:7000> exec 1) OK 2) OK 3) OK
如果在 set b bbb 处失败，set a 已成功不会回滚，set c 还会继续执行。
Redis 脚本使用 Lua 解释器来执行脚本。 Redis 2.6 版本通过内嵌支持 Lua 环境。执行脚本的常用命令为 EVAL。
redis 127.0.0.1:6379> EVAL "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second
1) "key1"
2) "key2"
3) "first"
4) "second"Redis GEO 主要用于存储地理位置信息，并对存储的信息进行操作，该功能在 Redis 3.2 版本新增。
Redis GEO 操作方法有：
redis> GEOADD Sicily 13.361389 38.115556 "Palermo" 15.087269 37.502669 "Catania" (integer) 2 redis> GEODIST Sicily Palermo Catania "166274.1516" redis> GEORADIUS Sicily 15 37 100 km 1) "Catania" redis> GEORADIUS Sicily 15 37 200 km 1) "Palermo" 2) "Catania" redis>
Redis Stream 是 Redis 5.0 版本新增加的数据结构。
Redis Stream 主要用于消息队列（MQ，Message Queue），Redis 本身是有一个 Redis 发布订阅 (pub/sub) 来实现消息队列的功能，但它有个缺点就是消息无法持久化，如果出现网络断开、Redis 宕机等，消息就会被丢弃。
简单来说发布订阅 (pub/sub) 可以分发消息，但无法记录历史消息。
而 Redis Stream 提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据，并且能记住每一个客户端的访问位置，还能保证消息不丢失。
Redis Stream 的结构如下所示，它有一个消息链表，将所有加入的消息都串起来，每个消息都有一个唯一的 ID 和对应的内容：
每个 Stream 都有唯一的名称，它就是 Redis 的 key，在我们首次使用 xadd 指令追加消息时自动创建。
上图解析：
Redis는 클라이언트-서버 모델과 요청/응답 프로토콜을 기반으로 하는 TCP 서비스입니다. 이는 일반적으로 요청이 다음 단계를 따른다는 것을 의미합니다.
Redis 파이프라인 기술을 사용하면 서버가 응답하지 않을 때 클라이언트가 서버에 계속 요청을 보내고 결국 모든 서버의 응답을 한 번에 읽을 수 있습니다.
추천 학습: Redis 비디오 튜토리얼
위 내용은 Redis의 장점과 특징에 대해 이야기해보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
