Heim > Datenbank > Redis > Detaillierte Analyse, warum Redis so schnell ist?

Detaillierte Analyse, warum Redis so schnell ist?

青灯夜游
Freigeben: 2021-09-16 19:46:34
nach vorne
2631 Leute haben es durchsucht

Detaillierte Analyse, warum Redis so schnell ist?

Wir alle wissen, dass Redis sehr schnell ist und seine QPS 100.000 (Anfragen pro Sekunde) erreichen kann. Warum ist Redis so schnell , erfahren Sie in diesem Artikel. [Verwandte Empfehlungen: Redis-Video-Tutorial]

Detaillierte Analyse, warum Redis so schnell ist?

Basierend auf der Speicherimplementierung

Wir alle wissen, dass das Lesen und Schreiben im Speicher viel schneller ist als das Lesen und Schreiben auf der Festplatte. Redis ist eine Datenbank, die auf Speicherspeicherung basiert. Im Vergleich zu Datenbanken, bei denen Daten auf der Festplatte gespeichert werden, entfällt der Festplatten-E/A-Verbrauch. Festplattendatenbanken wie MySQL müssen Indizes erstellen, um die Abfrageeffizienz zu beschleunigen, während Redis-Daten im Speicher gespeichert werden und direkt im Speicher ausgeführt werden, sodass sie sehr schnell sind.

Detaillierte Analyse, warum Redis so schnell ist?

Effiziente Datenstruktur

Wir wissen, dass der MySQL-Index zur Verbesserung der Effizienz die B+-Baum-Datenstruktur wählt. Tatsächlich kann eine vernünftige Datenstruktur Ihre Anwendung/Ihr Programm schneller machen. Werfen wir zunächst einen Blick auf die Datenstruktur und das interne Codierungsdiagramm von Redis:

Detaillierte Analyse, warum Redis so schnell ist?

SDS einfache dynamische Zeichenfolge

Detaillierte Analyse, warum Redis so schnell ist?

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

String-Längenverarbeitung

In C-Sprache, um den Kleinen Jungen zum Laufen zu bringen Schnecken< /code>Die Länge dieser Zeichenfolge muss von Anfang an durchlaufen werden und die Komplexität beträgt O(n); In Redis gibt es bereits ein <code>捡田螺的小男孩这个字符串的长度,需要从头开始遍历,复杂度为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的未使用空间。

惰性空间释放

当SDS缩短时,不是回收多余的内存空间,而是用free记录下多余的空间。后续再有修改操作,直接使用free中的空间,减少内存分配。

哈希

Redis 作为一个K-V的内存数据库,它使用用一张全局的哈希来保存所有的键值对。这张哈希表,有多个哈希桶组成,哈希桶中的entry元素保存了*key*value指针,其中*key指向了实际的键,*valuelen

-Feld, das die Länge der aktuellen Zeichenfolge aufzeichnet. Sie können es direkt abrufen und die Zeitkomplexität beträgt O(1).

Reduzieren Sie die Anzahl der SpeicherneuzuweisungenDetaillierte Analyse, warum Redis so schnell ist?

In der C-Sprache erfordert das Ändern einer Zeichenfolge eine Neuzuweisung von Speicher. Je häufiger die Änderung erfolgt, desto häufiger wird Speicher zugewiesen

Leistung verbrauchen . In Redis bietet SDS zwei Optimierungsstrategien: Speicherplatz-Vorzuweisung und verzögerte Speicherplatzfreigabe. Speicherplatz-Vorabzuweisung

Bei der einfachen dynamischen Zeichenfolgenänderung und Speicherplatzerweiterung von SDS wird zusätzlich zur Zuweisung des erforderlichen Speicherplatzes zusätzlicher ungenutzter Speicherplatz zugewiesen. Die Zuweisungsregeln sind lila:

  • Nachdem das Sicherheitsdatenblatt geändert wurde und die Länge von len weniger als 1 MB beträgt, wird zusätzlicher ungenutzter Speicherplatz mit der gleichen Länge wie len zugewiesen. Beispiel: len=100, nach der Neuzuweisung beträgt die tatsächliche Länge von buf 100 (benutzter Speicherplatz) + 100 (zusätzlicher Speicherplatz) + 1 (Nullzeichen) = 201.
  • Nachdem das SDS geändert wurde und die Len-Länge größer als 1 MB ist, weist das Programm 1 MB ungenutzten Speicherplatz zu.

Lazy Space Release

Wenn SDS gekürzt wird, wird „Free“ zum Aufzeichnen des überschüssigen Speicherplatzes verwendet, anstatt überschüssigen Speicherplatz zurückzugewinnen. Bei nachfolgenden Änderungsvorgängen wird der freie Speicherplatz direkt verwendet, um die Speicherzuweisung zu reduzieren.

HashRedis ist eine K-V-In-Memory-Datenbank, die einen globalen Hash verwendet, um alle Schlüssel-Wert-Paare zu speichern. Diese Hash-Tabelle besteht aus mehreren Hash-Buckets. Die Eintragselemente in den Hash-Buckets speichern *key- und *value-Zeiger, darunter *key zeigt auf den tatsächlichen Schlüssel und *value zeigt auf den tatsächlichen Wert.

Detaillierte Analyse, warum Redis so schnell ist?

Die Suchgeschwindigkeit der Hash-Tabelle ist sehr schnell, ähnlich wie

HashMap

in Java, wodurch wir Schlüssel-Wert-Paare in O(1) Zeitkomplexität schnell finden können. Berechnen Sie zunächst den Hash-Wert über den Schlüssel, suchen Sie den entsprechenden Hash-Bucket-Speicherort, suchen Sie dann den Eintrag und suchen Sie die entsprechenden Daten im Eintrag.

🎜Einige Freunde haben möglicherweise Fragen: Wenn Sie eine große Datenmenge in die Hash-Tabelle schreiben, tritt dann nicht das Problem des 🎜Hash-Konflikts🎜 auf, und dann nimmt die Effizienz ab. 🎜🎜🎜🎜Hash-Konflikt: 🎜 Derselbe Hash-Wert wird über verschiedene Schlüssel berechnet, was dazu führt, dass er in denselben Hash-Bucket fällt. 🎜🎜🎜Um Hash-Konflikte zu lösen, verwendet Redis 🎜Chain-Hashing🎜. Verkettetes Hashing bedeutet, dass mehrere Elemente im selben Hash-Bucket in einer verknüpften Liste gespeichert und nacheinander mithilfe von Zeigern verbunden werden. 🎜🎜🎜🎜🎜Einige Freunde haben möglicherweise noch Fragen: Elemente in der Hash-Konfliktkette können nur einzeln über Zeiger durchsucht und dann bearbeitet werden. Wenn viele Daten in die Hash-Tabelle eingefügt werden, wird die Konfliktverknüpfungsliste umso länger, je mehr Konflikte auftreten, und die Abfrageeffizienz wird verringert. 🎜🎜Um die Effizienz aufrechtzuerhalten, führt Redis „Rehash-Operationen“ für die Hash-Tabelle durch, was bedeutet, dass Hash-Buckets hinzugefügt und Konflikte reduziert werden. Um die Wiederaufbereitung effizienter zu gestalten, verwendet Redis außerdem standardmäßig zwei globale Hash-Tabellen, eine für die aktuelle Verwendung, die sogenannte Haupt-Hash-Tabelle, und eine für die Erweiterung, die sogenannte Backup-Hash-Tabelle. 🎜

跳跃表

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

Detaillierte Analyse, warum Redis so schnell ist?

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

压缩列表ziplist

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

Detaillierte Analyse, warum Redis so schnell ist?

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

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

合理的数据编码

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

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

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

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等命令。

什么是上下文切换?举个粟子:

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

Detaillierte Analyse, warum Redis so schnell ist?

I/O 多路复用

什么是I/O多路复用?

  • I/O: Netzwerk-I/O
  • Multiple: mehrere Netzwerkverbindungen
  • Multiplexing: Wiederverwendung desselben Threads.
  • IO-Multiplexing ist eigentlich ein synchrones E/A-Modell, das einen Thread implementiert, der mehrere Dateihandles überwachen kann. Sobald ein Dateihandle bereit ist, kann es die Anwendung benachrichtigen, entsprechende Lese- und Schreibvorgänge ohne Dateihandle durchzuführen Die Anwendung wird gesperrt und die CPU wird übergeben.

Detaillierte Analyse, warum Redis so schnell ist?

Die Multiple-I/O-Multiplexing-Technologie ermöglicht es einem einzelnen Thread, mehrere Verbindungsanforderungen effizient zu verarbeiten, und Redis verwendet Epoll als Implementierung der I/O-Multiplexing-Technologie. Darüber hinaus wandelt das eigene Ereignisverarbeitungsmodell von Redis Verbindungen, Lesevorgänge, Schreibvorgänge und Schließungen in Epoll in Ereignisse um, ohne zu viel Zeit mit Netzwerk-E/A zu verschwenden.

Virtueller Speichermechanismus

Redis baut den VM-Mechanismus direkt selbst auf. Es ruft keine Systemfunktionen wie normale Systeme auf, wodurch eine gewisse Zeit beim Verschieben und Anfordern verschwendet wird.

Was ist der virtuelle Speichermechanismus von Redis?

Der virtuelle Speichermechanismus verlagert Daten, auf die selten zugegriffen wird (kalte Daten), vorübergehend vom Speicher auf die Festplatte und gibt so wertvollen Speicherplatz für andere Daten frei, auf die zugegriffen werden muss (heiße Daten). Die VM-Funktion kann die Trennung von heißen und kalten Daten realisieren, sodass sich die heißen Daten noch im Speicher befinden und die kalten Daten auf der Festplatte gespeichert werden. Dadurch kann das Problem einer langsamen Zugriffsgeschwindigkeit vermieden werden, die durch unzureichenden Speicher verursacht wird.

Weitere Programmierkenntnisse finden Sie unter: Programmiervideo! !

Das obige ist der detaillierte Inhalt vonDetaillierte Analyse, warum Redis so schnell ist?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Verwandte Etiketten:
Quelle:掘金--捡田螺的小男孩
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
Web-Effekte
Quellcode der Website
Website-Materialien
Frontend-Vorlage