Redis가 왜 그렇게 빠른지에 대한 심층 분석은 무엇입니까?

우리 모두는 Redis가 매우 빠르고 QPS가 100,000(초당 요청 수)에 도달할 수 있다는 것을 알고 있습니다. Redis가 왜 그렇게 빠른가요? 이 글을 통해 알아보세요. [관련 권장 사항: Redis 동영상 튜토리얼]

메모리 구현 기반

우리 모두는 메모리 읽기 및 쓰기가 디스크 읽기 및 쓰기보다 훨씬 빠르다는 것을 알고 있습니다. Redis는 메모리 스토리지 기반으로 구현된 데이터베이스로, 디스크에 데이터를 저장하는 데이터베이스에 비해 디스크 I/O 소모가 없습니다. MySQL과 같은 디스크 데이터베이스는 쿼리 효율성을 높이기 위해 인덱스를 생성해야 하는 반면, Redis 데이터는 메모리에 저장되어 메모리에서 직접 작동하므로 속도가 매우 빠릅니다.

효율적인 데이터 구조

우리는 MySQL 인덱스가 효율성을 높이기 위해 B+ 트리 데이터 구조를 선택한다는 것을 알고 있습니다. 실제로, 합리적인 데이터 구조는 애플리케이션/프로그램을 더 빠르게 만들 수 있습니다. 먼저 Redis의 데이터 구조 및 내부 인코딩 다이어그램을 살펴보겠습니다.

SDS 단순 동적 문자열

struct sdshdr { //SDS简单动态字符串
    int len;    //记录buf中已使用的空间
    int free;   // buf中空闲空间长度
    char buf[]; //存储的实际内容
}

문자열 길이 처리

C 언어에서는捡田螺的小男孩이 문자열의 길이를 얻으려면 처음부터 시작해야 함 탐색을 시작해야 하며 복잡도는 O(n)입니다. Redis에는 현재 문자열의 길이를 기록하는 len 필드가 이미 있으며 이를 직접 얻을 수 있으며 시간 복잡도는 O(1)입니다.

메모리 재할당 횟수를 줄입니다

C 언어에서 문자열을 수정하려면 메모리를 재할당해야 합니다. 수정 빈도가 높을수록 메모리 할당 빈도가 높아져 성능이 소모됩니다. Redis에서 SDS는 공간 사전 할당과 지연 공간 해제라는 두 가지 최적화 전략을 제공합니다.

공간 사전 할당

SDS 단순 동적 문자열 수정 및 공간 확장 시 필요한 메모리 공간 할당 외에도 추가로 사용되지 않는 공간이 할당됩니다. 할당 규칙은 보라색입니다.

• SDS 수정 후 len의 길이가 1M 미만인 경우 len과 동일한 길이의 사용되지 않은 공간이 추가로 할당됩니다. 예를 들어 len=100이면 재할당 후 buf의 실제 길이는 100(사용된 공간) + 100(추가 공간) + 1(널 문자) = 201이 됩니다.
• SDS가 수정된 후 len 길이가 1M보다 크면 프로그램은 1M의 사용되지 않은 공간을 할당합니다.

Lazy space release

SDS가 단축되면 초과된 메모리 공간을 회수하는 대신 free를 사용하여 초과된 공간을 기록합니다. 후속 수정 작업이 있는 경우 여유 공간이 메모리 할당을 줄이기 위해 직접 사용됩니다.

Hash

Redis는 글로벌 해시를 사용하여 모든 키-값 쌍을 저장하는 K-V 인메모리 데이터베이스입니다. 이 해시 테이블은 여러 개의 해시 버킷으로 구성됩니다. 해시 버킷의 항목 요소는 *key和*value指针，其中*key指向了实际的键，*value을 저장하고 실제 값을 가리킵니다.

해시 테이블 조회 속도는 매우 빠르며 Java의 HashMap과 다소 비슷합니다. 이를 통해 O(1) 시간 복잡도로 키-값 쌍을 빠르게 찾을 수 있습니다. 먼저 키를 통해 해시 값을 계산하고 해당 해시 버킷 위치를 찾은 다음 항목을 찾고 항목에서 해당 데이터를 찾습니다.

어떤 친구들은 질문할 수도 있습니다. 해시 테이블에 많은 양의 데이터를 쓸 때 해시 충돌 문제가 발생하지 않을까요? 그러면 효율성이 떨어집니다.

해시 충돌: 동일한 해시 값이 서로 다른 키를 통해 계산되어 동일한 해시 버킷에 빠지게 됩니다.

해시 충돌을 해결하기 위해 Redis는 Chain Hash를 사용합니다. 체인 해싱은 동일한 해시 버킷의 여러 요소가 연결 목록에 저장되고 포인터를 사용하여 차례로 연결되는 것을 의미합니다.

어떤 친구들은 여전히 ​​질문이 있을 수 있습니다. 해시 충돌 체인의 요소는 포인터를 통해 하나씩만 검색한 다음 작동할 수 있습니다. 해시 테이블에 많은 양의 데이터가 삽입되면 충돌이 많아지고 충돌 연결 리스트가 길어져 쿼리 효율성이 떨어지게 됩니다.

효율성을 유지하기 위해 Redis는 해시 테이블에서 rehash 작업을 수행합니다. 이는 해시 버킷을 추가하고 충돌을 줄이는 것을 의미합니다. 재해시를 더욱 효율적으로 만들기 위해 Redis는 기본적으로 두 개의 전역 해시 테이블을 사용합니다. 하나는 현재 사용하는 기본 해시 테이블이고 다른 하나는 확장용인 백업 해시 테이블입니다.

跳跃表

跳跃表是Redis特有的数据结构，它其实就是在链表的基础上，增加多级索引，以提高查找效率。跳跃表的简单原理图如下:

• 每一层都有一条有序的链表，最底层的链表包含了所有的元素。
• 跳跃表支持平均 O（logN）,最坏 O（N）复杂度的节点查找，还可以通过顺序性操作批量处理节点。

压缩列表ziplist

压缩列表ziplist是列表键和字典键的的底层实现之一。它是由一系列特殊编码的内存块构成的列表， 一个ziplist可以包含多个entry， 每个entry可以保存一个长度受限的字符数组或者整数，如下：

• zlbytes ：记录整个压缩列表占用的内存字节数
• zltail: 尾节点至起始节点的偏移量
• zllen : 记录整个压缩列表包含的节点数量
• entryX: 压缩列表包含的各个节点
• zlend : 特殊值0xFF(十进制255)，用于标记压缩列表末端

由于内存是连续分配的，所以遍历速度很快。。

合理的数据编码

Redis支持多种数据基本类型，每种基本类型对应不同的数据结构，每种数据结构对应不一样的编码。为了提高性能，Redis设计者总结出，数据结构最适合的编码搭配。

Redis是使用对象（redisObject）来表示数据库中的键值，当我们在 Redis 中创建一个键值对时，至少创建两个对象，一个对象是用做键值对的键对象，另一个是键值对的值对象。

//关注公众号：捡田螺的小男孩
typedef struct redisObject{
    //类型
   unsigned type:4;
   //编码
   unsigned encoding:4;
   //指向底层数据结构的指针
   void *ptr;
    //...
 }robj;

redisObject中，type 对应的是对象类型，包含String对象、List对象、Hash对象、Set对象、zset对象。encoding 对应的是编码。

• String：如果存储数字的话，是用int类型的编码;如果存储非数字，小于等于39字节的字符串，是embstr；大于39个字节，则是raw编码。
• List：如果列表的元素个数小于512个，列表每个元素的值都小于64字节（默认），使用ziplist编码，否则使用linkedlist编码
• Hash：哈希类型元素个数小于512个，所有值小于64字节的话，使用ziplist编码,否则使用hashtable编码。
• Set：如果集合中的元素都是整数且元素个数小于512个，使用intset编码，否则使用hashtable编码。
• Zset：当有序集合的元素个数小于128个，每个元素的值小于64字节时，使用ziplist编码，否则使用skiplist（跳跃表）编码

合理的线程模型

单线程模型：避免了上下文切换

Redis是单线程的，其实是指Redis的网络IO和键值对读写是由一个线程来完成的。但Redis的其他功能，比如持久化、异步删除、集群数据同步等等，实际是由额外的线程执行的。

Redis的单线程模型，避免了CPU不必要的上下文切换和竞争锁的消耗。也正因为是单线程，如果某个命令执行过长（如hgetall命令），会造成阻塞。Redis是面向快速执行场景的内存数据库，所以要慎用如lrange和smembers、hgetall等命令。

什么是上下文切换？举个粟子：

• 比如你在看一本英文小说，你看到某一页，发现有个单词不会读，你加了个书签，然后去查字典。查完字典后，你回来从书签那里继续开始读，这个流程就很舒畅。
• 如果你一个人读这本书，肯定没啥问题。但是如果你去查字典的时候，别的小伙伴翻了一下你的书，然后溜了。你再回来看的时候，发现书不是你看的那一页了，你得花时间找到你的那一页。
• 一本书，你一个人怎么看怎么打标签都没事，但是人多了翻来翻去，这本书各种标记就很乱了。可能这个解释很粗糙，但是道理应该是一样的。

I/O 多路复用

什么是I/O多路复用？

• I/O: 네트워크 I/O
• Multiple: 여러 네트워크 연결
• Multiplexing: 동일한 스레드를 재사용합니다.
• IO 멀티플렉싱은 실제로 여러 파일 핸들을 모니터링할 수 있는 스레드를 구현하는 동기식 IO 모델입니다. 파일 핸들이 준비되면 파일 핸들 없이 해당 읽기 및 쓰기 작업을 수행하도록 애플리케이션에 알릴 수 있습니다. 애플리케이션이 차단되고 CPU가 넘겨집니다.

다중 I/O 다중화 기술을 사용하면 단일 스레드가 다중 연결 요청을 효율적으로 처리할 수 있으며 Redis는 I/O 다중화 기술 구현으로 epoll을 사용합니다. 또한 Redis의 자체 이벤트 처리 모델은 네트워크 I/O에 너무 많은 시간을 낭비하지 않고 epoll의 연결, 읽기, 쓰기 및 닫기를 이벤트로 변환합니다.

가상 메모리 메커니즘

Redis는 VM 메커니즘을 자체적으로 직접 구축합니다. 일반 시스템처럼 시스템 기능을 호출하지 않으므로 이동 및 요청에 일정 시간이 낭비됩니다.

Redis의 가상 메모리 메커니즘은 무엇인가요?

가상 메모리 메커니즘은 자주 액세스하지 않는 데이터(콜드 데이터)를 메모리에서 디스크로 일시적으로 교환하여 액세스해야 하는 다른 데이터(핫 데이터)를 위한 귀중한 메모리 공간을 확보합니다. VM 기능은 핫 데이터와 콜드 데이터의 분리를 실현할 수 있으므로 핫 데이터는 여전히 메모리에 있고 콜드 데이터는 디스크에 저장됩니다. 이렇게 하면 메모리 부족으로 인해 액세스 속도가 느려지는 문제를 피할 수 있습니다.

더 많은 프로그래밍 관련 지식을 보려면 프로그래밍 비디오를 방문하세요! !

위 내용은 Redis가 왜 그렇게 빠른지에 대한 심층 분석은 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!