Redis의 장점과 특징에 대해 이야기해보겠습니다.

이 기사에서는 Redis에 대한 관련 지식을 제공합니다. Redis의 장점과 특징을 주로 소개합니다. Redis는 ANSI C 언어로 작성된 오픈 소스이며 BSD 프로토콜을 준수하고 네트워크를 지원하며 메모리를 기반으로 할 수 있습니다. 분산 스토리지 데이터베이스에 대해 살펴보겠습니다. 모두에게 도움이 되기를 바랍니다.

추천 학습: Redis 동영상 튜토리얼

redis란 무엇입니까

Remote DIctionary Server(Redis)는 Salvatore Sanfilippo가 작성한 키-값 저장 시스템으로 크로스 플랫폼 비관계형 데이터베이스입니다.

Redis는 ANSI C 언어로 작성된 오픈 소스 키-값 저장소 데이터베이스로, BSD 프로토콜을 준수하고 네트워크, 메모리 기반, 분산, 선택적 지속성을 지원하며 여러 언어로 API를 제공합니다.

Redis는 값이 문자열, 해시, 목록, 집합, 정렬된 집합 등의 유형이 될 수 있기 때문에 종종 데이터 구조 서버라고 합니다.

Redis의 특징:

• 인 메모리 데이터베이스는 빠르고 데이터 지속성을 지원합니다. 메모리의 데이터를 디스크에 저장하고 다시 시작할 때 사용할 수 있도록 다시 로드할 수 있습니다.
• Redis는 단순한 키-값 유형의 데이터를 지원할 뿐만 아니라 list, set, zset, hash 등과 같은 데이터 구조의 저장도 제공합니다.
• Redis는 데이터 백업, 즉 마스터-슬레이브 모드에서의 데이터 백업을 지원합니다.
• 트랜잭션 지원

Redis의 장점:

• 매우 높은 성능 - Redis는 110,000회/초의 속도로 읽고 81,000회/초의 속도로 쓸 수 있습니다.
• 다양한 데이터 유형 – Redis는 바이너리 사례에 대한 문자열, 목록, 해시, 집합 및 순서 집합 데이터 유형 작업을 지원합니다.
• Atomic - Redis의 모든 작업은 원자적이며 Redis는 여러 작업을 병합한 후 원자 실행도 지원합니다. (트랜잭션)
• 다양한 기능 - Redis는 게시/구독, 알림, 키 만료 및 기타 기능도 지원합니다.

Redis는 다른 키-값 스토어와 어떻게 다른가요?

• Redis는 더 복잡한 데이터 구조를 가지며 이에 대한 원자적 연산을 제공합니다. 이는 다른 데이터베이스와는 다른 진화 경로입니다. Redis의 데이터 유형은 기본 데이터 구조를 기반으로 하며 추가 추상화가 필요 없이 프로그래머에게 투명합니다.
• Redis는 메모리에서 실행되지만 디스크에 유지될 수 있으므로, 데이터 양이 하드웨어 메모리보다 클 수 없기 때문에 다양한 데이터 세트를 고속으로 읽고 쓸 때 메모리 무게를 측정해야 합니다. 인메모리 데이터베이스의 또 다른 장점은 디스크의 동일한 복잡한 데이터 구조와 비교할 때 메모리에서의 작동이 매우 간단하므로 Redis는 강력한 내부 복잡성을 가지고 많은 작업을 수행할 수 있다는 것입니다. 또한 디스크 형식 측면에서 임의 액세스가 필요하지 않으므로 컴팩트하게 추가 생성됩니다.

Memcache와 Redis의 차이점은 무엇인가요?

1. 저장 방법 Memecache는 모든 데이터를 메모리에 저장합니다. 정전 후에는 데이터가 메모리 크기를 초과할 수 없습니다. Redis의 일부는 하드 디스크에 저장되며 redis는 데이터를 유지할 수 있습니다
2. 데이터 지원 유형 memcached 모든 값은 간단한 문자열로 대체되며 list, set 및 zset , hash 및 를 제공하는 보다 풍부한 데이터 유형을 지원합니다. 다른 데이터 구조는 다른 기본 모델을 사용하여 저장됩니다. 클라이언트와의 통신을 위한 기본 구현 방법 및 애플리케이션 프로토콜이 다릅니다. Redis는 자체 VM 메커니즘을 직접 구축했습니다. 일반 시스템이 시스템 기능을 호출하면 이동 및 요청에 일정 시간이 낭비되기 때문입니다.
3. 값 값 크기는 다릅니다. Redis는 최대 512M에 도달할 수 있습니다. Memcache는 1MB에 불과합니다.
4. Redis는 memcached보다 훨씬 빠릅니다.
5. Redis는 데이터 백업, 즉 마스터-슬레이브 모드의 데이터 백업을 지원합니다.
6. Redis가 왜 그렇게 빠른가요? 1. 완전히 메모리를 기반으로 하며 대부분의 요청은 순수 메모리 작업이므로 매우 빠릅니다. HashMap과 마찬가지로 데이터가 메모리에 저장되는 장점은 검색 및 연산의 시간 복잡도가 O(1)이라는 것입니다.

2. 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는 왜 싱글 스레드인가요?

위의 모든 분석은 Redis가 빠른 분위기를 조성하기 위한 것임을 먼저 이해해야 합니다! 공식 FAQ에는 Redis가 메모리 기반 작업이기 때문에 CPU가 Redis의 병목 현상이 되지 않는다고 명시되어 있습니다. Redis의 병목 현상은 시스템 메모리 크기나 네트워크 대역폭 때문일 가능성이 높습니다. 싱글 스레딩은 구현하기 쉽고 CPU에 병목 현상이 발생하지 않으므로 싱글 스레드 솔루션을 채택하는 것이 논리적입니다(결국 멀티 스레딩을 사용하면 많은 문제가 발생합니다!).

Redis 데이터 유형 및 명령

1. String(String)

redis 127.0.0.1:6379> SET rediskey redis
OK
redis 127.0.0.1:6379> GET rediskey
"redis"

2. Hash(Hash)

Redis 해시는 문자열 형식의 필드(field)와 값(value)의 매핑입니다. 특히 물건을 보관하는 데 적합합니다.

Redis의 각 해시는 232 - 1개의 키-값 쌍(40억 개 이상)을 저장할 수 있습니다.

3. 목록(List)

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"

4. Set

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"

5. 정렬된 집합(sorted set)

Redis의 정렬된 집합도 집합과 마찬가지로 문자열 형식 요소의 모음이며 중복 멤버를 허용하지 않습니다.

차이점은 각 요소가 이중 유형 점수와 연관되어 있다는 것입니다. Redis는 점수를 사용하여 컬렉션의 구성원을 작은 것부터 큰 것까지 정렬합니다.

주문한 세트의 구성원은 고유하지만 점수는 반복될 수 있습니다.

세트는 해시 테이블을 통해 구현되므로 추가, 삭제, 검색의 복잡성은 O(1)입니다. 컬렉션의 최대 구성원 수는 232 - 1(4294967295, 각 컬렉션은 40억 명 이상의 구성원을 저장할 수 있음)입니다.

6. HyperLogLog

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

7. 게시 및 구독

Redis 게시 및 구독(pub/sub)은 메시지 통신 모델입니다. 발신자(pub)가 메시지를 보냅니다. 구독자(sub))가 메시지를 수신합니다.

Redis 클라이언트는 원하는 수의 채널을 구독할 수 있습니다.

다음 그림은 채널 Channel1과 이 채널을 구독하는 세 클라이언트(client2, client5 및 client1) 간의 관계를 보여줍니다.

Example

다음 예는 게시 및 구독이 작동하는 방식을 보여줍니다. Two redis-cli 클라이언트를 열어야 합니다.

이 예에서는 runoobChat이라는 구독 채널을 만들었습니다.

第一个 redis-cli 客户端

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-cli 客户端

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 演示如下：

• 开启本地 Redis 服务，开启两个 redis-cli 客户端。
• 在第一个 redis-cli 客户端输入 SUBSCRIBE runoobChat，意思是订阅 runoobChat 频道。
• 在第二个 redis-cli 客户端输入 PUBLISH runoobChat “Redis PUBLISH test” 往 runoobChat 频道发送消息，这个时候在第一个 redis-cli 客户端就会看到由第二个 redis-cli 客户端发送的测试消息。

8. 事务

Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：

• 批量操作在发送 EXEC 命令前被放入队列缓存。
• 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
• 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

一个事务从开始到执行会经历以下三个阶段：

• 开始事务。
• 命令入队。
• 执行事务。

实例

以下是一个事务的例子， 它先以 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 还会继续执行。

9. 脚本

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"

10 GEO

Redis GEO 主要用于存储地理位置信息，并对存储的信息进行操作，该功能在 Redis 3.2 版本新增。

Redis GEO 操作方法有：

• geoadd：添加地理位置的坐标。
• geopos：获取地理位置的坐标。
• geodist：计算两个位置之间的距离。
• georadius：根据用户给定的经纬度坐标来获取指定范围内的地理位置集合。
• georadiusbymember：根据储存在位置集合里面的某个地点获取指定范围内的地理位置集合。
• geohash：返回一个或多个位置对象的 geohash 值。

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>

11 Redis Stream

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 指令追加消息时自动创建。

上图解析：

• Consumer Group: XGROUP CREATE 명령을 사용하여 생성된 소비자 그룹에는 여러 소비자(소비자)가 있습니다.
• last_delivered_id: 커서. 각 소비자 그룹에는 last_delivered_id 커서가 있습니다. 메시지를 읽는 모든 소비자는 커서 last_delivered_id를 앞으로 이동합니다.
• pending_ids: 소비자의 확인되지 않은 ID를 유지하는 데 사용되는 소비자의 상태 변수입니다. 보류 중_ids는 클라이언트가 읽었지만 아직 ack(승인 문자)를 받지 못한 메시지를 기록합니다.

Redis 파이프라인 기술

Redis는 클라이언트-서버 모델과 요청/응답 프로토콜을 기반으로 하는 TCP 서비스입니다. 이는 일반적으로 요청이 다음 단계를 따른다는 것을 의미합니다.

• 클라이언트는 서버에 쿼리 요청을 보내고 일반적으로 차단 모드에서 소켓 반환을 수신하여 서버의 응답을 기다립니다.
• 서버는 명령을 처리하고 결과를 클라이언트에 반환합니다.

---

Redis 파이프라인 기술

Redis 파이프라인 기술을 사용하면 서버가 응답하지 않을 때 클라이언트가 서버에 계속 요청을 보내고 결국 모든 서버의 응답을 한 번에 읽을 수 있습니다.

추천 학습: Redis 비디오 튜토리얼

위 내용은 Redis의 장점과 특징에 대해 이야기해보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!