Redis의 데이터 구조에 대한 자세한 설명

실제 개발에서는 Redis를 자주 사용하게 되는데, 사용 시 데이터 타입을 어떻게 올바르게 선택해야 할까요? 어떤 데이터 유형이 어떤 시나리오에 적합한지 그리고 인터뷰에서 면접관은 Redis 데이터 구조에 대한 질문을 자주 받습니다. Redis使用会频繁，那么在使用过程中我们该如何正确抉择数据类型呢？哪些场景下适用哪些数据类型。而且在面试中也很常会被面试官问到Redis数据结构方面的问题：

• Redis为什么快呢？
• 为什么查询操作会变慢了？
• Redis Hash rehash过程
• 为什么使用哈希表作为Redis的索引

当我们分析理解了Redis数据结构，可以为了我们在使用Redis的时候，正确抉择数据类型使用，提升系统性能。【相关推荐：Redis视频教程】

Redis底层数据结构

Redis 是一个内存键值key-value 数据库，且键值对数据保存在内存中，因此Redis基于内存的数据操作，其效率高，速度快；

其中，Key是String类型，Redis 支持的 value 类型包括了 String、List 、 Hash 、 Set 、 Sorted Set 、BitMap等。Redis 能够之所以能够广泛地适用众多的业务场景，基于其多样化类型的value。

而Redis的Value的数据类型是基于为Redis自定义的对象系统redisObject实现的，

typedef struct redisObject{
    //类型
    unsigned type:4;
    //编码
    unsigned encoding:4;
    //指向底层实现数据结构的指针
    void *ptr;
    ….. 
}

redisObject除了记录实际数据，还需要额外的内存空间记录数据长度、空间使用等元数据信息，其中包含了 8 字节的元数据和一个 8 字节指针，指针指向具体数据类型的实际数据所在位置：

其中，指针指向的就是基于Redis的底层数据结构存储数据的位置，Redis的底层数据结构：SDS，双向链表、跳表，哈希表，压缩列表、整数集合实现的。

那么Redis底层数据结构是怎么实现的呢？

Redis底层数据结构实现

我们先来看看Redis比较简单的SDS,双向链表，整数集合。

SDS、双向链表和整数集合

SDS，使用len字段记录已使用的字节数，将获取字符串长度复杂度降低为O(1)，而且SDS是惰性释放空间的，你free了空间，系统把数据记录下来下次想用时候可直接使用。不用新申请空间。

整数集合，在内存中分配一块地址连续的空间，数据元素会挨着存放，不需要额外指针带来空间开销，其特点为内存紧凑节省内存空间，查询复杂度为O(1)效率高，其他操作复杂度为O(N)；

双向链表， 在内存上可以为非连续、非顺序空间，通过额外的指针开销前驱/后驱指针串联元素之间的顺序。

其特点为节插入/更新数据复杂度为O(1)效率高，查询复杂度为O(N)；

Hash哈希表

哈希表，其实类似是一个数组，数组的每个元素称为一个哈希桶，每个哈希桶中保存了键值对数据，且哈希桶中的元素使用dictEntry结构，

因此，哈希桶元素保存的并不是键值对值本身，而是指向具体值的指针，所以在保存每个键值对的时候会额外空间开销，至少有增加24个字节，特别是Value为String

• Redis가 왜 빠른가요?
• 쿼리 작업이 느려지는 이유는 무엇입니까?
• Redis 해시 재해시 프로세스
• 해시 테이블을 Redis 인덱스로 사용하는 이유
Redis 데이터 구조를 분석하고 이해하면 사용할 데이터 유형을 올바르게 선택할 수 있고 Redis 사용 시 시스템 성능을 향상시킬 수 있습니다. [관련 권장사항: 🎜Redis 동영상 튜토리얼] 🎜

Redis기본 데이터 구조

🎜Redis는 메모리 키-값 키-값 데이터베이스와 키-값 쌍 데이터는 메모리에 저장되므로 Redis 메모리 기반 데이터 작업은 매우 효율적이고 빠릅니다. 🎜🎜그 중 Key는 String 유형이고 Redis는 를 지원합니다. value 유형에는 String, List, Hash, Set, Sorted Set가 포함됩니다. code>, BitMap 등 Redis는 다양한 유형의 가치를 기반으로 다양한 비즈니스 시나리오에 널리 적용될 수 있습니다. 🎜🎜 Redis의 Value 데이터 유형은 Redis에 맞게 사용자 정의된 객체 시스템 <code>redisObject를 기반으로 합니다. code> >실제 데이터를 기록하는 것 외에도 🎜rrreee🎜redisObject는 8바이트의 메타데이터와 8단어 섹션을 포함하는 데이터 길이 및 공간 사용량과 같은 메타데이터 정보를 기록하기 위해 추가 메모리 공간이 필요합니다. 포인터는 특정 데이터 유형의 실제 데이터 위치를 가리킵니다. 🎜🎜🎜🎜그 중 포인터는 Redis 코드>의 기본 데이터 구조는 데이터의 위치를 ​​저장합니다. <code>Redis의 기본 데이터 구조는 SDS, 이중 연결 목록, 점프 목록, 해시 테이블입니다. , 압축 목록 및 정수 컬렉션. 🎜🎜그렇다면 Redis의 기본 데이터 구조는 어떻게 구현됩니까? 🎜

Redis 기본 데이터 구조 구현

🎜먼저 Redis의 더 간단한 SDS를 살펴보겠습니다. 양방향 연결 목록, 정수 집합. 🎜

SDS, 이중 연결 목록 및 정수 집합

🎜SDS, len를 사용하여 기록됨 > 필드 사용된 바이트 수는 문자열 길이를 얻는 복잡성을 O(1)로 줄이고 SDS는 지연 해제 공간이므로 해제합니다. 코드> 코드> 공간, 시스템은 데이터를 기록하고 다음에 사용할 때 직접 사용할 수 있습니다. 새로운 공간을 신청할 필요가 없습니다. <br><span class="img-wrap"><img class="lazy" src="https://img.php.cn/upload/article/000/000/024/a6bb77c337b840fb785407be5753fa62-2.png" alt="Redis의 데이터 구조에 대한 자세한 설명" title="Redis의 데이터 구조에 대한 자세한 설명"></span><br><strong>정수 컬렉션</strong>, 메모리에 연속된 주소가 있는 공간을 할당하면 데이터 요소가 서로 옆에 저장되므로 공간 오버헤드를 가져오기 위해 추가 포인터가 필요하지 않으며 그 특징은 메모리 컴팩트, 메모리 공간 절약, 쿼리 복잡도 O(1) 및 고효율, 기타 작업 복잡도 O(N);🎜🎜<strong>이중 연결 목록</strong>은 메모리 내에서 비연속적이고 비순차적인 공간일 수 있으며, 요소 간의 순서는 프런트엔드의 추가 포인터 오버헤드를 통해 직렬로 연결됩니다. /백엔드 포인터. 🎜🎜섹션 삽입/업데이트 데이터 복잡도가 O(1)이고 쿼리 복잡도가 O(N)인 것이 특징입니다. 🎜<h4> <strong><code>해시해시 테이블 🎜해시 테이블은 실제로 배열과 유사합니다. 배열의 각 요소를 해시 버킷이라고 합니다. 각 해시 버킷은 키-값 쌍 데이터를 저장하고 해시 버킷의 요소는 dictEntry를 사용합니다. 코드> 구조,
🎜🎜따라서 해시 버킷 요소는 키-값 쌍 자체를 저장하지 않고 A에 대한 포인터를 저장합니다. 특정 값이므로 각 키-값 쌍을 저장할 때 추가 공간 오버헤드가 발생합니다. 최소 24바이트가 추가됩니다. 특히 값이 문자열 인 경우 의 키-값 쌍에는 각 키-값 쌍에 추가로 24바이트의 공간이 필요합니다. 저장된 데이터의 양이 적고 추가 오버헤드가 데이터보다 큰 경우 공간 절약을 위해 데이터 구조를 변경하는 것을 고려해보세요. 🎜

글로벌 해시 테이블의 전체 그림을 살펴보겠습니다.

해시 테이블 작업은 빠르지만 Redis 데이터가 커지면 잠재적인 위험이 나타납니다. Redis数据变大后，就会出现一个潜在的风险：哈希表的冲突问题和 rehash开销问题，这可以解释为什么哈希表操作变慢了？

当往哈希表中写入更多数据时，哈希冲突是不可避免的问题 ， Redis 解决哈希冲突的方式，就是链式哈希，同一个哈希桶中的多个元素用一个链表来保存，它们之间依次用指针连接，如图所示：


当哈希冲突也会越来越多，这就会导致某些哈希冲突链过长，进而导致这个链上的元素查找耗时长，效率降低。

为了解决哈希冲突带了的链过长的问题，进行rehash操作，增加现有的哈希桶数量，分散单桶元素数量。那么rehash过程怎么样执行的呢？

Rehash

为了使rehash 操作更高效，使用两个全局哈希表：哈希表 1 和哈希表 2，具体如下：

• 将哈希表 2 分配更大的空间，
• 把哈希表 1 中的数据重新映射并拷贝到哈希表 2 中；
• 释放哈希表 1 的空间

但由于表1和表2在重新映射复制时数据大，如果一次性把哈希表 1 中的数据都迁移完，会造成 Redis 线程阻塞，无法服务其他请求。

为了避免这个问题，保证Redis能正常处理客户端请求，Redis 采用了渐进式 rehash。

每处理一个请求时，从哈希表 1 中依次将索引位置上的所有 entries 拷贝到哈希表 2 中，把一次性大量拷贝的开销，分摊到了多次处理请求的过程中，避免了耗时操作，保证了数据的快速访问。



在理解完HashHash 테이블 충돌 문제 및 rehash 오버헤드 문제

,

이것이 해시 테이블 작업이 느린 이유를 설명할 수 있나요?

해시 테이블에 더 많은 데이터를 쓸 때 해시 충돌은 피할 수 없는 문제입니다. Redis가 해시 충돌을 해결하는 방식은

체인 해싱으로, 동일한 해시 버킷에 여러 해시가 연결되어 있습니다. 그림과 같이 포인터를 사용하여 차례로 연결됩니다.


해시 충돌이 점점 더 많아지면 일부 해시 충돌이 Long 체인을 통과하여 요소 검색이 발생하게 됩니다. 이 체인에 시간이 오래 걸리고 효율성이 떨어집니다.
해시 충돌로 인해 체인이 너무 길어지는 문제를 해결하기 위해 rehash 작업

을 수행하여 기존 해시 버킷 수를 늘리고 단일 버킷에 요소 수를 분산시킵니다. . 그렇다면 rehash 프로세스는 어떻게 수행되나요?

재해시

재해시 작업을 보다 효율적으로 만들기 위해 두 개의 전역 해시 테이블, 즉 해시 테이블 1과 해시 테이블 2가 사용됩니다.

• 해시 테이블 2에 더 큰 공간을 할당하고,
• 해시 테이블 1의 데이터를 해시 테이블 2에 다시 매핑하고 복사합니다.
• li>
• 해시 테이블 1의 공간을 해제하세요

단, 재매핑 및 복사 중에 테이블 1과 테이블 2의 데이터가 크기 때문에 해시 테이블 1의 모든 데이터를 한 번만 실행하면 Redis 스레드가 차단되어 다른 요청을 처리할 수 없게 됩니다.

이 문제를 방지하고 Redi가 클라이언트 요청을 정상적으로 처리할 수 있도록 하기 위해 Redis 는

점진적 rehash

를 채택합니다.
요청이 처리될 때마다 인덱스 위치의 모든 항목이 해시 테이블 1에서 해시 테이블 2로 순차적으로 복사되며, 동시에 많은 양의 복사본을 복사하는 오버헤드는 여러 요청을 처리하는 과정에 할당됩니다. , 시간이 많이 소요되는 작업이 필요하지 않으므로 데이터에 대한 빠른 액세스가 보장됩니다. 압축된 목록 및 건너뛰기 목록압축된 목록컴팩트한 메모리는 메모리 공간을 절약합니다. 데이터 요소는 공간 오버헤드를 가져오고 위치를 찾는 데 필요한 추가 포인터 없이 서로 옆에 저장됩니다. 첫 번째 요소와 마지막 요소는 세 개의 헤더 필드의 길이를 통해 직접 찾을 수 있으며 복잡도는 O(1)입니다. Jump list 특징: 데이터의 양이 많을 때 스킵 테이블의 검색 복잡도는 O(logN)입니다. 요약하자면, 기본 데이터 구조의 시간 복잡도를 알 수 있습니다. 시간 복잡도

at 해시 해시 테이블 관련 지식 포인트를 이해한 후, 흔하지 않은 압축 목록과 스킵 테이블을 살펴보겠습니다.
, 배열을 기준으로 압축된 목록에는 헤더에 zlbytes, zltail 및 zllen이라는 세 개의 필드가 있으며, 각각 목록의 길이, 오프셋을 나타냅니다. 목록의 끝과 목록의 길이. 압축된 목록에는 목록의 끝을 나타내는 zlend도 있습니다.
장점:
는 연결된 목록을 기반으로 다단계 인덱스를 추가하여 아래 그림과 같이 인덱스 위치에서 여러 번의 점프를 통해 데이터의 신속한 위치 지정을 실현합니다.	예를 들어 쿼리 33
	데이터 구조 유형

🎜🎜🎜🎜해시 테이블🎜🎜O(1)🎜🎜🎜🎜 정수 배열 🎜🎜O(N)🎜🎜🎜🎜이중 연결 목록🎜🎜O(N)🎜🎜🎜🎜압축 목록🎜🎜O(N)🎜🎜🎜🎜목록 건너뛰기🎜🎜O(logN)🎜🎜🎜 🎜

Redis의 사용자 정의 개체 시스템 유형은 Redis의 Value 데이터 유형이고 Redis의 데이터 유형입니다. code>는 기본 데이터 구조를 기반으로 구현됩니다. 데이터 유형은 무엇입니까? Redis自定义的对象系统类型即为Redis的Value的数据类型，Redis的数据类型是基于底层数据结构实现的，那数据类型有哪些呢？

Redis数据类型

String、List、Hash、Sorted Set、Set

Redis 데이터 유형

문자열, 목록, 해시, 정렬 Set, Set은 비교적 일반적인 유형이며 기본 데이터 구조와의 해당 관계는 다음과 같습니다. SDS( 단순 동적 문자열)이중 연결 목록압축 목록Hash압축 목록
해시 테이블정렬 집합

List


Com 누른 목록


Set

해시 테이블
정수 배열

데이터 유형의 해당 특성은 구현의 기본 데이터 구조와 유사하며 속성도 동일하며 SDS 구현을 기반으로 하는

String은 간단한 에 적합합니다. 키-값 저장소, setnx 키 값은 분산 잠금, 카운터(원자성) 및 분산 전역 고유 ID를 구현합니다. String，基于SDS实现，适用于简单key-value存储、setnx key value实现分布式锁、计数器(原子性)、分布式全局唯一ID。

List， 按照元素进入List 的顺序进行排序的，遵循FIFO(先进先出)规则，一般使用在 排序统计以及简单的消息队列。

Hash， 是字符串key和字符串value之间的映射，十分适合用来表示一个对象信息 ，特点添加和删除操作复杂度都是O(1)。

Set，是String 类型元素的无序集合，集合成员是唯一的，这就意味着集合中不能出现重复的数据。 基于哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。

Sorted Set，  是Set的类型的升级， 不同的是每个元素都会关联一个 double 类型的分数，通过分数排序，可以范围查询。

那我们再来看看这些数据类型，Redis Geo、HyperLogLog、BitMap？

Redis Geo， 将地球看作为近似为球体，基于GeoHash 将二维的经纬度转换成字符串，来实现位置的划分跟指定距离的查询。特点一般使用在跟位置有关的应用。

HyperLogLog， 是一种概率数据结构，它使用概率算法来统计集合的近似基数 ， 错误率大概在0.81%。 当集合元素数量非常多时，它计算基数所需的空间总是固定的，而且还很小，适合使用做 UV 统计。

BitMap ，用一个比特位来映射某个元素的状态， 只有 0 和 1 两种状态，非常典型的二值状态，且其本身是用 String 类型作为底层数据结构实现的一种统计二值状态的数据类型  ，优势大量节省内存空间，可是使用在二值统计场景。

在理解上述知识后，我们接下来讨论一下根据哪些策略选择相对应的应用场景下的Redis数据类型？

选择合适的Redis数据类型策略

在实际开发应用中，Redis可以适用于众多的业务场景，但我们需要怎么选择数据类型存储呢？

主要依据就是时间/空间复杂度，在实际的开发中可以考虑以下几个点：

• 数据量，数据本身大小
• 集合类型统计模式
• 支持单点查询/范围查询
• 特殊使用场景

数据量，数据本身大小

当数据量比较大，数据本身比较小，使用String就会使用额外的空间大大增加，因为使用哈希表保存键值对，使用dictEntry结构保存，会导致保存每个键值对时额外保存dictEntry的三个指针的开销，这样就会导致数据本身小于额外空间开销，最终会导致存储空间数据大小远大于原本数据存储大小。

可以使用基于整数数组和压缩列表实现了 List、Hash 和 Sorted Set ，因为整数数组和压缩列表在内存中都是分配一块地址连续的空间，然后把集合中的元素一个接一个地放在这块空间内，非常紧凑，不用再通过额外的指针把元素串接起来，这就避免了额外指针带来的空间开销。而且采用集合类型时，一个 key 就对应一个集合的数据，能保存的数据多了很多，但也只用了一个 dictEntry，这样就节省了内存。

集合类型统计模式

Redis

List는 FIFO(선입 선출) 규칙에 따라 List에 요소가 입력되는 순서에 따라 정렬됩니다. 일반적으로 통계 및 단순 정렬에 사용됩니다. 메시지 대기열. 🎜🎜Hash는 key 문자열과 value 문자열 간의 매핑입니다. 삭제 작업의 복잡성은 O(1)입니다. 🎜🎜Set은 String 유형 요소의 순서가 지정되지 않은 컬렉션입니다. 집합 구성원은 고유하므로 집합에 중복 데이터가 나타날 수 없습니다. 해시 테이블을 기반으로 구현되므로 추가, 삭제, 검색의 복잡도는 O(1)입니다. 🎜🎜Sorted Set은 Set 유형의 업그레이드입니다. 차이점은 각 요소가 이중 유형 점수와 연결되어 있다는 점입니다. 🎜🎜그럼 Redis Geo, HyperLogLog, BitMap 데이터 유형을 살펴볼까요? 🎜🎜Redis Geo는 지구를 대략적인 구로 취급하고 GeoHash를 기반으로 2차원 경도와 위도를 문자열로 변환하여 위치 분할 및 지정된 거리 쿼리를 구현합니다. 기능은 일반적으로 위치 관련 애플리케이션에 사용됩니다. 🎜🎜HyperLogLog는 확률적 알고리즘을 사용하여 약 0.81%의 오류율로 세트의 대략적인 카디널리티를 계산하는 확률적 데이터 구조입니다. 설정된 요소의 개수가 매우 클 경우 카디널리티를 계산하는 데 필요한 공간이 항상 고정되어 있고 매우 작기 때문에 UV 통계에 적합합니다. 🎜🎜BitMap은 1비트를 사용하여 요소의 상태를 매핑합니다. 매우 일반적인 바이너리 상태인 0과 1의 두 가지 상태만 있으며 문자열 유형을 기본 데이터로 사용하여 구현됩니다. 이진 상태 통계를 위한 데이터 유형으로, 메모리 공간을 많이 절약할 수 있다는 장점이 있으며 이진 통계 시나리오에 사용할 수 있습니다. 🎜🎜위의 지식을 이해한 후, 해당 애플리케이션 시나리오에서 Redis 데이터 유형을 선택하기 위해 어떤 전략을 사용해야 하는지 토론해 볼까요? 🎜

적절한 Redis 데이터 유형 전략 선택

🎜실제 개발 애플리케이션에서 Redis는 다양한 비즈니스 시나리오에 적용될 수 있지만 어떻게 선택해야 할까요? 데이터 유형 저장은 어떻습니까? 🎜🎜주요 기준은 시간/공간 복잡성입니다. 실제 개발에서는 다음 사항을 고려할 수 있습니다. 🎜

• 데이터 볼륨, 데이터 자체의 크기
• 설정 유형 통계 모드
• 단일 지점 쿼리/범위 쿼리 지원
• 특수 사용 시나리오

데이터 양, 데이터 자체의 크기

🎜 데이터의 양이 상대적으로 많고 데이터 자체가 상대적으로 작은 경우 문자열을 사용하면 추가 공간 사용이 크게 늘어납니다. 테이블은 키-값 쌍을 저장하는 데 사용되며 dictEntry 구조를 저장하면 각 키-값 쌍을 저장할 때 dictEntry의 세 가지 추가 포인터를 저장하는 오버헤드가 발생합니다. 이로 인해 데이터 자체가 추가 공간 오버헤드보다 작아지고 궁극적으로 데이터 크기가 원래 데이터 저장 크기보다 훨씬 커집니다. 🎜🎜정수 배열 및 압축 목록을 기반으로 목록, 해시 및 정렬 집합, <strong>정수 배열</strong>과 <strong>압축 목록</strong> 모두 메모리에 연속 주소가 있는 공간을 할당한 다음 컬렉션의 요소를 이 공간에 차례로 넣기 때문입니다. 공간은 매우 작으며 요소를 서로 연결하기 위해 추가 포인터를 사용할 필요가 없습니다. 이는 추가 포인터로 인해 발생하는 공간 오버헤드를 방지합니다. 게다가 컬렉션 타입을 사용할 경우 하나의 키가 컬렉션의 데이터에 해당하므로 더 많은 데이터를 저장할 수 있지만 <code>dictEntry는 하나만 사용하므로 메모리가 절약된다. 🎜

수집 유형 통계 모드

🎜Redis일반적인 집합 유형 통계 모드는 다음과 같습니다. 🎜

• 집계 통계(교집합, 차이 및 통합 통계): 여러 세트에 대한 집계 계산을 수행할 때 설정을 선택할 수 있습니다.
Set；
• 排序统计（要求集合类型能对元素保序）： Redis中List 和 Sorted Set是有序集合，List是按照元素进入 List 的顺序进行排序的，Sorted Set 可以根据元素的权重来排序；
• 二值状态统计（ 集合元素的取值就只有 0 和 1 两种 ）：Bitmap 本身是用 String 类型作为底层数据结构实现的一种统计二值状态的数据类型 ， Bitmap通过 BITOP 按位 与、或、异或的操作后使用 BITCOUNT 统计 1 的个数。
• 基数统计（ 统计一个集合中不重复的元素的个数 ）：HyperLogLog 是一种用于统计基数的数据集合类型 ，统计结果是有一定误差的，标准误算率是 0.81% 。需要精确统计结果的话，用 Set 或 Hash 类型。



Set类型，适用统计用户/好友/关注/粉丝/感兴趣的人集合聚合操作，比如

• 统计手机APP每天的新增用户数
• 两个用户的共同好友

Redis中List 和 Sorted Set是有序集合，使用应对集合元素排序需求 ，比如

• 最新评论列表
• 排行榜

Bitmap二值状态统计，适用数据量大，且可以使用二值状态表示的统计，比如：

• 签到打卡，当天用户签到数
• 用户周活跃
• 用户在线状态

HyperLogLog 是一种用于统计基数的数据集合类型， 统计一个集合中不重复的元素个数 ，比如

• 统计网页的 UV ， 一个用户一天内的多次访问只能算作一次

支持单点查询/范围查询

Redis中List 和 Sorted Set是有序集合支持范围查询，但是Hash是不支持范围查询的

特殊使用场景

消息队列，使用Redis作为消息队列的实现，要消息的基本要求消息保序、处理重复的消息和保证消息可靠性，方案有如下：

• 基于 List 的消息队列解决方案
• 基于 Streams 的消息队列解决方案

	基于List	基于Strems
消息保序	使用LPUSH/RPOP	使用XADD/XREAD
阻塞读取	使用BRPOP	使用XREAD block
重复消息处理	生产者自行实现全局唯一ID	Streams自动生成全局唯一ID
消息可靠性	使用BRPOPLPUSH	使用PENDING List自动留存消息
适用场景	消息总量小	消息总量大，需要消费组形式读取数据

基于位置 LBS 服务，使用Redis的特定GEO数据类型实现，GEO 可以记录经纬度形式的地理位置信息，被广泛地应用在 LBS 服务中。  比如:打车软件是怎么基于位置提供服务的。

总结

Redis之所以那么快，是因为其基于内存的数据操作和使用Hash통계 정렬(요소를 유지하려면 세트 유형이 필요함) Order): Redis의 List와 Sorted Set는 순서가 지정된 컬렉션이며 List는 요소에 따라 를 입력합니다. .List는 순서대로 정렬되며, Sorted Set은 요소의 가중치에 따라 정렬될 수 있습니다.

Binary 상태 통계(집합 요소의 값은 0만 입니다. 1) ): Bitmap 자체는 String 유형을 기본 데이터 구조로 사용하여 구현된 통계적 이진 상태 데이터 유형입니다. Bitmap은 BITOP을 통해 비트별 AND, OR 및 XOR을 사용합니다. 연산 후 BITCOUNT를 사용하여 1의 개수를 계산합니다.

카디널리티 통계(세트의 고유 요소 수 계산): HyperLogLog는 카디널리티를 계산하는 데 사용되는 데이터 수집 유형입니다. 통계 결과에는 특정 오류율이 있습니다. 0.81%. 정확한 통계 결과가 필요한 경우 Set 또는 Hash 유형을 사용하세요.

Set 유형, 사용자/친구/팔로우/팬/관심인 수집 집계 작업에 적합합니다(예: 🎜🎜🎜매일 모바일 앱의 신규 사용자 수 계산🎜두 사용자의 공통 친구🎜List 및 Redis의 Sorted Set는 순서가 지정된 집합입니다. 🎜🎜🎜최신 댓글 목록🎜순위 목록🎜비트맵 바이너리 상태 통계와 같은 수집 요소 정렬에 대한 요구에 대응하여 대용량에 적합합니다. 데이터이며 사용할 수 있습니다. 다음과 같은 이진 상태로 표시되는 통계: 🎜🎜🎜로그인 및 클럭인, 당일 사용자 체크인 수🎜사용자 주간 활성🎜사용자 온라인 상태🎜HyperLogLog code>는 카디널리티를 계산하는 데 사용되는 데이터 컬렉션 유형입니다. 예를 들어 🎜🎜🎜는 컬렉션의 UV를 계산합니다. 사용자가 하루에 여러 번 방문한 웹페이지는 한 번만 계산됩니다.<h4><strong>단일 지점 쿼리/범위 쿼리 지원</strong></h4>🎜<code>목록 및 Redis의 정렬된 집합 은 범위 쿼리를 지원하는 정렬된 컬렉션이지만 Hash는 범위 쿼리를 지원하지 않습니다🎜

특수 사용 시나리오

🎜Message Queue, Redis를 메시지 대기열 구현으로 사용하는 경우 메시지의 기본 요구 사항은 메시지 순서 보존, 중복 메시지 처리 및 메시지 안정성 보장에 대한 솔루션은 다음과 같습니다. 🎜🎜🎜목록 기반 메시지 대기열 솔루션 🎜스트림 기반 메시지 대기열 솔루션 tr> tr>스트림은 전역적으로 고유한 ID를 자동으로 생성합니다.메시지 안정성🎜위치 기반 LBS 서비스를 사용하여 구현됨 특정 GEO 데이터 유형인 Redis, GEO는 위도와 경도를 기록할 수 있습니다. LBS 형식의 지리적 위치 정보는 LBS 서비스에서 널리 사용됩니다. 예: 택시 호출 소프트웨어가 위치 기반 서비스를 제공하는 방법. 🎜

요약

🎜Redis는 메모리 기반 데이터 작업과 Hash 해싱 As 사용으로 인해 매우 빠릅니다. 인덱스, 테이블은 매우 효율적이고 빠르며, 기본 데이터의 다양화 덕분에 다양한 시나리오에 적합한 데이터 유형을 선택하면 쿼리 성능이 향상될 수 있습니다. 🎜🎜더 많은 프로그래밍 관련 지식을 보려면 🎜프로그래밍 비디오🎜를 방문하세요! ! 🎜

	목록 기반	스트렘 기반
메시지 순서 보존	LPUSH/RPOP 사용 td>	XADD/XREAD 사용
읽기 차단	BRPOP 사용 td>	XREAD 블록 사용
중복 메시지 처리	생산자가 전역 고유 ID를 직접 구현
BRPOPLPUSH 사용	PENDING 메시지를 자동으로 보관하는 목록
적용 가능한 시나리오	총 메시지 양이 적음	총계 메시지 양이 많고 소비자 그룹 형태로 데이터를 읽어야 함

위 내용은 Redis의 데이터 구조에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!