In diesem Artikel werden einige Interviewfragen zum verteilten Caching in Redis mit Ihnen geteilt, einschließlich der Analyse der Antworten. Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird für alle hilfreich sein.
Was ist der Unterschied zwischen Redis und Memcached? Was ist das Threading-Modell von Redis? Warum kann Redis eine hohe Parallelität mit einem einzelnen Thread unterstützen?
Interviewer-Psychologische Analyse
Dies ist die grundlegendste Frage, wenn es um Redis geht. Eines der grundlegendsten internen Prinzipien und Merkmale von Redis ist tatsächlich ein Single-Thread-Arbeitsmodell Wenn Sie das nicht wissen, wissen Sie dann nicht, wenn etwas schief geht, wenn Sie später mit Redis spielen?
Der Interviewer fragt Sie möglicherweise auch nach dem Unterschied zwischen Redis und Memcached. Memcached war jedoch in den Anfangsjahren eine gängige Caching-Lösung, die von großen Internetunternehmen verwendet wurde. In den letzten Jahren handelt es sich jedoch im Wesentlichen um Redis, und nur wenige Unternehmen verwenden Memcached. [Verwandte Empfehlungen: Redis-Video-Tutorial]
Analyse von Interviewfragen
Was ist der Unterschied zwischen Redis und Memcached?
Redis unterstützt komplexe Datenstrukturen
Im Vergleich zu Memcached verfügt Redis über mehr Datenstrukturen und kann umfangreichere Datenoperationen unterstützen. Wenn Sie den Cache benötigen, um komplexere Strukturen und Vorgänge zu unterstützen, wäre Redis eine gute Wahl.
redis unterstützt nativ den Cluster-Modus
In redis3.
Leistungsvergleich
Da Redis nur Single-Core verwendet, während Memcached Multi-Cores verwenden kann, weist Redis im Durchschnitt eine höhere Leistung als Memcached auf, wenn auf jedem Kern kleine Daten gespeichert werden. Bei Daten von mehr als 100.000 ist die Memcached-Leistung höher als bei Redis. Obwohl Redis kürzlich für die Speicherleistung großer Datenmengen optimiert wurde, ist es Memcached immer noch etwas unterlegen.
Threading-Modell von Redis
Redis verwendet intern den Dateiereignishandler Dateiereignishandler
. Dieser Dateiereignishandler ist Single-Threaded, daher wird Redis als Single-Threaded-Modell bezeichnet. Es verwendet einen E/A-Multiplexmechanismus, um mehrere Sockets gleichzeitig zu überwachen und den Socket, der das Ereignis generiert, in die Speicherwarteschlange zu verschieben. Der Ereignis-Dispatcher wählt den entsprechenden Ereignisprozessor zur Verarbeitung basierend auf dem Ereignistyp auf dem Socket aus. file event handler
,这个文件事件处理器是单线程的,所以 redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket,将产生事件的 socket 压入内存队列中,事件分派器根据 socket 上的事件类型来选择对应的事件处理器进行处理。
文件事件处理器的结构包含 4 个部分:
多个 socket 可能会并发产生不同的操作,每个操作对应不同的文件事件,但是 IO 多路复用程序会监听多个 socket,会将产生事件的 socket 放入队列中排队,事件分派器每次从队列中取出一个 socket,根据 socket 的事件类型交给对应的事件处理器进行处理。
来看客户端与 redis 的一次通信过程:
要明白,通信是通过 socket 来完成的,不懂的同学可以先去看一看 socket 网络编程。
首先,redis 服务端进程初始化的时候,会将 server socket 的 AE_READABLE
事件与连接应答处理器关联。
客户端 socket01 向 redis 进程的 server socket 请求建立连接,此时 server socket 会产生一个 AE_READABLE
事件,IO 多路复用程序监听到 server socket 产生的事件后,将该 socket 压入队列中。文件事件分派器从队列中获取 socket,交给连接应答处理器。连接应答处理器会创建一个能与客户端通信的 socket01,并将该 socket01 的 AE_READABLE
事件与命令请求处理器关联。
假设此时客户端发送了一个 set key value
请求,此时 redis 中的 socket01 会产生 AE_READABLE
事件,IO 多路复用程序将 socket01 压入队列,此时事件分派器从队列中获取到 socket01 产生的 AE_READABLE
事件,由于前面 socket01 的 AE_READABLE
事件已经与命令请求处理器关联,因此事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 socket01 的 key value
并在自己内存中完成 key value
的设置。操作完成后,它会将 socket01 的 AE_WRITABLE
AE_READABLE
-Ereignis des Server-Sockets dem Verbindungsantwortprozessor zugeordnet. 🎜🎜Client socket01 fordert den Server-Socket des Redis-Prozesses auf, eine Verbindung herzustellen. Zu diesem Zeitpunkt generiert der Server-Socket ein AE_READABLE
-Ereignis, nachdem der E/A-Multiplexer das vom Server-Socket generierte Ereignis abgehört hat , wird es in die Warteschlange verschoben. Der Dateiereignis-Dispatcher ruft den Socket aus der Warteschlange ab und übergibt ihn an den 🎜Verbindungsantworthandler🎜. Der Verbindungsantwort-Handler erstellt einen Socket01, der mit dem Client kommunizieren kann, und ordnet das AE_READABLE
-Ereignis des Socket01 dem Befehlsanforderungshandler zu. 🎜🎜Angenommen, der Client sendet zu diesem Zeitpunkt eine set key value
-Anfrage. Zu diesem Zeitpunkt generiert socket01 in Redis das AE_READABLE
-Ereignis und der IO-Multiplexer pusht socket01 Warteschlange, zu diesem Zeitpunkt ruft der Ereignis-Dispatcher das von socket01 generierte AE_READABLE
-Ereignis aus der Warteschlange ab. Da das vorherige AE_READABLE
-Ereignis von socket01 dem Befehlsanforderungsprozessor zugeordnet wurde Ereignis-Dispatcher Leitet das Ereignis zur Verarbeitung an den Befehlsanforderungshandler weiter. Der Befehl fordert den Prozessor auf, den Schlüsselwert
von socket01 zu lesen und die Einstellung des Schlüsselwerts
in seinem eigenen Speicher abzuschließen. Nachdem der Vorgang abgeschlossen ist, ordnet es das AE_WRITABLE
-Ereignis von socket01 dem Befehlsantworthandler zu. 🎜Wenn der Client zu diesem Zeitpunkt bereit ist, das Rückgabeergebnis zu empfangen, generiert socket01 in Redis ein AE_WRITABLE
事件,同样压入队列中,事件分派器找到相关联的命令回复处理器,由命令回复处理器对 socket01 输入本次操作的一个结果,比如 ok
,之后解除 socket01 的 AE_WRITABLE
-Ereignis, das dem Befehlsantwortprozessor zugeordnet ist.
Damit ist eine Kommunikation abgeschlossen. In Bezug auf den Kommunikationsprozess von Redis wird den Lesern zum systematischen Lernen die Lektüre von „Redis Design and Implementation – Huang Jianhong“ empfohlen.
Warum ist das Redis-Single-Threaded-Modell so effizient?
Was ist das Problem der Parallelitätskonflikte in Edis? Wie kann dieses Problem gelöst werden? Kennen Sie die CAS-Lösung für Redis-Transaktionen?
Interviewer-Psychologische Analyse
Dies ist auch ein sehr häufiges Problem im Internet, d ; Oder mehrere Clients erhalten gleichzeitig einen Schlüssel, ändern den Wert und schreiben ihn dann zurück. Solange die Reihenfolge falsch ist, sind die Daten falsch. Und Redis selbst verfügt über eine CAS-ähnliche optimistische Sperrlösung, die dieses Problem auf natürliche Weise löst.
Analyse von InterviewfragenZu einem bestimmten Zeitpunkt aktualisieren mehrere Systeminstanzen einen bestimmten Schlüssel. Verteilte Sperren können basierend auf Zookeeper implementiert werden. Jedes System erhält über zookeeper verteilte Sperren, um sicherzustellen, dass nur eine Systeminstanz gleichzeitig einen bestimmten Schlüssel bedienen kann und niemand sonst lesen oder schreiben darf.
Die Daten, die Sie in den Cache schreiben möchten, werden alle aus MySQL ausgecheckt und müssen in MySQL geschrieben werden. Beim Auschecken in MySQL muss ein Zeitstempel gespeichert werden auch raus.
Jedes Mal, wenn Sie
schreiben möchten, stellen Sie zunächst fest,ob der Zeitstempel des aktuellen Werts neuer ist als der Zeitstempel des Werts im Cache. Wenn dies der Fall ist, kann darauf geschrieben werden, andernfalls können die neuen Daten nicht mit den alten Daten überschrieben werden. Weitere Kenntnisse zum Thema Programmierung finden Sie unter:
ProgrammiervideosDas obige ist der detaillierte Inhalt vonTeilen Sie einige Interviewfragen zum verteilten Caching in Redis (mit Antwortanalyse). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!