1 00:00:01,150 --> 00:00:02,580 ‫Kursleiter: Willkommen zurück. 2 00:00:02,580 --> 00:00:05,000 ‫Lassen Sie uns nun alles über die Ereignisschleife erfahren, 3 00:00:05,000 --> 00:00:08,150 ‫die das Herzstück der Node. js-Architektur. 4 00:00:08,150 --> 00:00:10,580 ‫Und dies ist wahrscheinlich der wichtigste Vortrag 5 00:00:10,580 --> 00:00:13,500 ‫in diesem Abschnitt, also stellen Sie sicher, dass Sie 6 00:00:13,500 --> 00:00:16,510 ‫wirklich alles verstehen, was ich Ihnen in diesem Video zeige. 7 00:00:16,510 --> 00:00:17,813 ‫Also lasst uns anfangen. 8 00:00:18,800 --> 00:00:21,880 ‫Also, hier ist ein Diagramm ähnlich wie in der 9 00:00:21,880 --> 00:00:25,170 ‫letzten Vorlesung, damit wir genau wissen, wovon wir hier sprechen. 10 00:00:25,170 --> 00:00:28,240 ‫Wir befinden uns also immer noch in einem Node-Prozess in dem einzelnen 11 00:00:28,240 --> 00:00:30,810 ‫Thread, in dem die Ereignisschleife ausgeführt wird, in Ordnung? 12 00:00:30,810 --> 00:00:32,530 ‫Als erstes müssen Sie 13 00:00:32,530 --> 00:00:34,750 ‫wissen, dass in der Ereignisschleife 14 00:00:34,750 --> 00:00:36,350 ‫der gesamte Anwendungscode 15 00:00:36,350 --> 00:00:39,550 ‫ausgeführt wird, der sich in Callback-Funktionen befindet. 16 00:00:39,550 --> 00:00:43,640 ‫Grundsätzlich wird also jeder Code, der kein Top-Level-Code ist, in 17 00:00:43,640 --> 00:00:45,250 ‫der Ereignisschleife ausgeführt. 18 00:00:45,250 --> 00:00:48,450 ‫Einige Teile werden möglicherweise in den Thread-Pool ausgelagert, wie wir in 19 00:00:48,450 --> 00:00:50,140 ‫der letzten Vorlesung gesehen haben, 20 00:00:50,140 --> 00:00:53,430 ‫aber es ist die Ereignisschleife, die sich um all das kümmert. 21 00:00:53,430 --> 00:00:56,370 ‫Wie ich bereits sagte, ist es wirklich 22 00:00:56,370 --> 00:00:58,360 ‫das Herz der Node-Architektur. 23 00:00:58,360 --> 00:01:01,660 ‫Okay, wie ich im ersten Teil des Kurses schon oft 24 00:01:01,660 --> 00:01:04,300 ‫erwähnt habe, Node. js 25 00:01:04,300 --> 00:01:05,860 ‫basiert auf Callback-Funktionen. 26 00:01:05,860 --> 00:01:08,160 ‫Also Funktionen, die aufgerufen werden, 27 00:01:08,160 --> 00:01:11,700 ‫sobald eine Arbeit irgendwann in der Zukunft abgeschlossen ist. 28 00:01:11,700 --> 00:01:12,960 ‫Erinnere dich daran? 29 00:01:12,960 --> 00:01:15,310 ‫Und das funktioniert so, weil 30 00:01:15,310 --> 00:01:17,750 ‫Node eine ereignisgesteuerte Architektur verwendet, 31 00:01:17,750 --> 00:01:20,480 ‫worüber wir in einem der nächsten 32 00:01:20,480 --> 00:01:22,100 ‫Videos sprechen werden. 33 00:01:22,100 --> 00:01:24,180 ‫Aber was Sie vorerst wissen 34 00:01:24,180 --> 00:01:26,020 ‫müssen, ist, dass Dinge wie 35 00:01:26,020 --> 00:01:31,020 ‫unsere Anwendung, die eine HTTP-Anfrage auf unserem Server erhält oder ein Timer abläuft oder 36 00:01:31,130 --> 00:01:34,860 ‫eine Datei zum Lesen beendet wird, alle diese Ereignisse ausgeben, 37 00:01:34,860 --> 00:01:37,350 ‫sobald sie mit ihrer Arbeit fertig sind, 38 00:01:37,350 --> 00:01:40,150 ‫und unser Ereignis loop nimmt dann diese Ereignisse 39 00:01:40,150 --> 00:01:41,880 ‫auf und ruft 40 00:01:41,880 --> 00:01:44,750 ‫die Callback-Funktionen auf, die jedem Ereignis zugeordnet sind. 41 00:01:44,750 --> 00:01:46,520 ‫Okay, sinnvoll? 42 00:01:46,520 --> 00:01:49,680 ‫Auch hier empfängt die Ereignisschleife jedes Mal Ereignisse, wenn 43 00:01:49,680 --> 00:01:51,800 ‫etwas Wichtiges passiert, und ruft dann 44 00:01:51,800 --> 00:01:54,440 ‫die erforderlichen Rückrufe auf, wie wir sie 45 00:01:54,440 --> 00:01:56,443 ‫in unserem Code definieren. 46 00:01:57,300 --> 00:01:59,690 ‫Zusammenfassend heißt es normalerweise, dass 47 00:01:59,690 --> 00:02:02,600 ‫die Ereignisschleife die Orchestrierung übernimmt, was 48 00:02:02,600 --> 00:02:05,310 ‫einfach bedeutet, dass sie Ereignisse empfängt, 49 00:02:05,310 --> 00:02:07,330 ‫ihre Rückruffunktionen aufruft 50 00:02:07,330 --> 00:02:11,290 ‫und die teureren Aufgaben in den Thread-Pool auslagert. 51 00:02:11,290 --> 00:02:14,670 ‫Wie funktioniert das alles eigentlich hinter den Kulissen? 52 00:02:14,670 --> 00:02:17,960 ‫In welcher Reihenfolge werden diese Callbacks ausgeführt? 53 00:02:17,960 --> 00:02:20,543 ‫Nun, das werden wir als nächstes herausfinden. 54 00:02:21,460 --> 00:02:24,630 ‫Denken Sie also daran, dass die Ereignisschleife sofort 55 00:02:24,630 --> 00:02:27,430 ‫ausgeführt wird, wenn wir unsere Node-Anwendung starten. 56 00:02:27,430 --> 00:02:29,720 ‫Jetzt hat die Ereignisschleife mehrere Phasen, 57 00:02:29,720 --> 00:02:32,330 ‫und jede Phase hat eine Rückrufwarteschlange, die 58 00:02:32,330 --> 00:02:35,060 ‫die Rückrufe sind, die von den Ereignissen stammen, 59 00:02:35,060 --> 00:02:36,690 ‫die die Ereignisschleife empfängt, 60 00:02:36,690 --> 00:02:39,830 ‫genau wie wir auf der letzten Folie besprochen haben. 61 00:02:39,830 --> 00:02:41,830 ‫Nun werden Sie an 62 00:02:41,830 --> 00:02:45,520 ‫manchen Stellen lesen, dass es nur eine Rückrufwarteschlange oder eine 63 00:02:45,520 --> 00:02:49,290 ‫Ereigniswarteschlange gibt, aber tatsächlich hat die Ereignisschleife, wie gesagt, viele 64 00:02:49,290 --> 00:02:52,290 ‫Phasen, wobei jede Phase ihre eigene Rückrufwarteschlange hat. 65 00:02:52,290 --> 00:02:56,090 ‫Werfen wir nun einen Blick auf die vier wichtigsten Phasen. 66 00:02:56,090 --> 00:02:58,090 ‫Es gibt ein oder zwei andere Phasen, 67 00:02:58,090 --> 00:02:59,890 ‫die intern von Node verwendet werden, 68 00:02:59,890 --> 00:03:01,360 ‫aber diese sind nicht 69 00:03:01,360 --> 00:03:03,530 ‫so wichtig und ich werde nicht darüber sprechen. 70 00:03:03,530 --> 00:03:05,230 ‫Die erste Phase 71 00:03:05,230 --> 00:03:07,860 ‫kümmert sich also um Rückrufe 72 00:03:07,860 --> 00:03:10,880 ‫abgelaufener Timer, beispielsweise aus der Funktion setTimeout(). 73 00:03:10,880 --> 00:03:13,210 ‫Wenn es also Callback-Funktionen von gerade 74 00:03:13,210 --> 00:03:15,750 ‫abgelaufenen Timern gibt, werden diese als erstes 75 00:03:15,750 --> 00:03:18,010 ‫von der Ereignisschleife verarbeitet. 76 00:03:18,010 --> 00:03:21,040 ‫Wenn ein Timer später während der Verarbeitung 77 00:03:21,040 --> 00:03:23,370 ‫einer der anderen Phasen 78 00:03:23,370 --> 00:03:26,860 ‫abläuft, wird der Callback dieses Timers nur aufgerufen, 79 00:03:26,860 --> 00:03:30,450 ‫sobald die Ereignisschleife zu dieser ersten Phase zurückkehrt. 80 00:03:30,450 --> 00:03:31,580 ‫Sinn ergeben? 81 00:03:31,580 --> 00:03:34,520 ‫Und das funktioniert in allen vier Phasen so. 82 00:03:34,520 --> 00:03:37,250 ‫Rückrufe in jeder Warteschlange werden also 83 00:03:37,250 --> 00:03:40,810 ‫nacheinander verarbeitet, bis sich keine mehr in der Warteschlange befinden, 84 00:03:40,810 --> 00:03:44,630 ‫und erst dann tritt die Ereignisschleife in die nächste Phase ein. 85 00:03:44,630 --> 00:03:49,180 ‫Als nächstes haben wir das E/A-Polling und die Ausführung von E/A-Callbacks. 86 00:03:49,180 --> 00:03:52,840 ‫Denken Sie auch hier daran, dass I/O für Input/Output steht. 87 00:03:52,840 --> 00:03:56,040 ‫Polling bedeutet also im Grunde, nach neuen I/O-Ereignissen zu 88 00:03:56,040 --> 00:03:58,060 ‫suchen, die zur Verarbeitung bereit 89 00:03:58,060 --> 00:04:00,890 ‫sind, und diese in die Callback-Warteschlange zu stellen. 90 00:04:00,890 --> 00:04:04,110 ‫Und denken Sie daran, dass I/O im 91 00:04:04,110 --> 00:04:08,710 ‫Kontext einer Node-Anwendung hauptsächlich Dinge wie Netzwerk- und Dateizugriff bedeutet. 92 00:04:08,710 --> 00:04:12,150 ‫In dieser Phase werden wahrscheinlich 99% unseres Codes 93 00:04:12,150 --> 00:04:14,270 ‫ausgeführt, einfach weil 94 00:04:14,270 --> 00:04:16,640 ‫in einer typischen Node-App der 95 00:04:16,640 --> 00:04:20,500 ‫Großteil Was wir tun müssen, bezieht sich auf die 96 00:04:20,500 --> 00:04:23,170 ‫Vernetzung und auch auf den Dateizugriff. 97 00:04:23,170 --> 00:04:26,490 ‫Die nächste Phase ist für setImmediate-Callbacks und setImmediate 98 00:04:26,490 --> 00:04:29,250 ‫ist eine spezielle Art von 99 00:04:29,250 --> 00:04:32,810 ‫Timer, die wir verwenden können, wenn wir Callbacks unmittelbar 100 00:04:32,810 --> 00:04:36,130 ‫nach der E/A-Polling- und Ausführungsphase verarbeiten möchten, was 101 00:04:36,130 --> 00:04:39,173 ‫in einigen fortgeschritteneren Anwendungsfällen wichtig sein kann. 102 00:04:40,110 --> 00:04:40,943 ‫Gut. 103 00:04:40,943 --> 00:04:44,940 ‫Und schließlich ist die vierte Phase für enge Rückrufe, die für 104 00:04:44,940 --> 00:04:47,530 ‫uns wiederum nicht so wichtig sind, 105 00:04:47,530 --> 00:04:50,820 ‫aber der Vollständigkeit halber schreibe ich dies trotzdem hier. 106 00:04:50,820 --> 00:04:54,450 ‫Grundsätzlich werden in dieser Phase alle Close-Events 107 00:04:54,450 --> 00:04:58,920 ‫verarbeitet, beispielsweise wenn ein Webserver oder ein WebSocket heruntergefahren wird. 108 00:04:58,920 --> 00:05:01,920 ‫Das sind also die vier Phasen in der 109 00:05:01,920 --> 00:05:05,400 ‫Ereignisschleife, aber neben diesen vier Callback-Warteschlangen, die wir gerade 110 00:05:05,400 --> 00:05:08,330 ‫gesehen haben, gibt es tatsächlich noch 111 00:05:08,330 --> 00:05:11,600 ‫zwei weitere Warteschlangen, die nextTick()-Warteschlange und die andere 112 00:05:11,600 --> 00:05:14,780 ‫Microtasks-Warteschlange, die hauptsächlich für aufgelöste Promises gedacht ist. 113 00:05:14,780 --> 00:05:16,890 ‫Wenn Sie mit Versprechen nicht vertraut 114 00:05:16,890 --> 00:05:20,240 ‫sind, werden wir in einem späteren Abschnitt ein wenig darüber sprechen. 115 00:05:20,240 --> 00:05:22,620 ‫Wenn in einer dieser beiden Warteschlangen 116 00:05:22,620 --> 00:05:24,750 ‫Callbacks verarbeitet werden müssen, werden 117 00:05:24,750 --> 00:05:27,840 ‫diese jedoch direkt nach Abschluss der aktuellen Phase 118 00:05:27,840 --> 00:05:30,250 ‫der Ereignisschleife ausgeführt, anstatt auf das Ende 119 00:05:30,250 --> 00:05:32,380 ‫der gesamten Schleife zu warten. 120 00:05:32,380 --> 00:05:33,370 ‫Okay? 121 00:05:33,370 --> 00:05:36,680 ‫Mit anderen Worten, nach jeder dieser vier 122 00:05:36,680 --> 00:05:40,340 ‫Phasen werden alle Rückrufe in diesen beiden 123 00:05:40,340 --> 00:05:42,880 ‫speziellen Warteschlangen sofort ausgeführt. 124 00:05:42,880 --> 00:05:46,030 ‫Stellen Sie sich nun beispielsweise vor, dass ein 125 00:05:46,030 --> 00:05:49,730 ‫Promise aufgelöst wird und einige Daten von einem API-Aufruf zurückgibt, 126 00:05:49,730 --> 00:05:52,690 ‫während der Rückruf eines abgelaufenen Timers läuft. 127 00:05:52,690 --> 00:05:56,050 ‫In diesem Fall wird der Promise-Callback also direkt 128 00:05:56,050 --> 00:05:59,230 ‫nach dem Ablauf des Timers ausgeführt. 129 00:05:59,230 --> 00:06:00,490 ‫Okay? 130 00:06:00,490 --> 00:06:03,480 ‫Und die gleiche Logik gilt auch für die nextTick()-Warteschlange, über 131 00:06:03,480 --> 00:06:05,290 ‫die wir noch nicht gesprochen haben. 132 00:06:05,290 --> 00:06:09,060 ‫Im Grunde ist process the nextTick() also eine Funktion, die 133 00:06:09,060 --> 00:06:11,610 ‫wir verwenden können, wenn wir wirklich, 134 00:06:11,610 --> 00:06:13,740 ‫wirklich einen bestimmten Callback direkt 135 00:06:13,740 --> 00:06:16,290 ‫nach der aktuellen Ereignisschleifenphase ausführen müssen. 136 00:06:16,290 --> 00:06:18,810 ‫Es ist setImmediate ähnlich, mit dem 137 00:06:18,810 --> 00:06:21,540 ‫Unterschied, dass setImmediate erst nach der 138 00:06:21,540 --> 00:06:23,400 ‫I/O-Callback-Phase ausgeführt wird. 139 00:06:23,400 --> 00:06:24,600 ‫Was jedoch ähnlich 140 00:06:24,600 --> 00:06:27,930 ‫ist, ist, dass beide für wirklich fortgeschrittene Anwendungsfälle gedacht sind 141 00:06:27,930 --> 00:06:30,080 ‫und wir sie in diesem Kurs wahrscheinlich 142 00:06:30,080 --> 00:06:31,580 ‫nicht einmal benötigen werden. 143 00:06:31,580 --> 00:06:34,660 ‫Aber wie auch immer, ich wollte auch diese komplexeren 144 00:06:34,660 --> 00:06:36,700 ‫Dinge hier einschließen, damit Sie die 145 00:06:36,700 --> 00:06:38,940 ‫Werkzeuge haben, die Sie brauchen, wenn Sie 146 00:06:38,940 --> 00:06:42,980 ‫wirklich tief in Node. js, wenn Sie möchten. 147 00:06:42,980 --> 00:06:46,210 ‫In Ordnung, und damit haben wir tatsächlich einen Tick 148 00:06:46,210 --> 00:06:50,360 ‫der Ereignisschleife beendet, und ein Tick ist im Grunde nur ein Zyklus 149 00:06:50,360 --> 00:06:51,580 ‫in dieser Schleife. 150 00:06:51,580 --> 00:06:54,840 ‫Jetzt ist es also an der Zeit zu entscheiden, ob die Schleife 151 00:06:54,840 --> 00:06:58,520 ‫bis zum nächsten Tick fortgesetzt werden soll oder ob das Programm beendet werden soll. 152 00:06:58,520 --> 00:07:00,720 ‫Und wie macht Node das? 153 00:07:00,720 --> 00:07:02,310 ‫Nun, es ist ganz einfach. 154 00:07:02,310 --> 00:07:05,100 ‫Node prüft einfach, ob noch 155 00:07:05,100 --> 00:07:08,440 ‫Timer oder I/O-Aufgaben im Hintergrund laufen, und 156 00:07:08,440 --> 00:07:12,180 ‫wenn keine vorhanden sind, wird die Anwendung beendet. 157 00:07:12,180 --> 00:07:15,430 ‫Aber wenn es irgendwelche ausstehenden Timer oder I/O-Aufgaben gibt, 158 00:07:15,430 --> 00:07:17,870 ‫dann wird es die Ereignisschleife weiter 159 00:07:17,870 --> 00:07:20,500 ‫ausführen und direkt zum nächsten Tick gehen. 160 00:07:20,500 --> 00:07:22,030 ‫Wenn wir also beispielsweise 161 00:07:22,030 --> 00:07:24,740 ‫auf eingehende HTTP-Anforderungen lauschen, wie wir es 162 00:07:24,740 --> 00:07:27,770 ‫in unserem Node-Farmprojekt in einem vorherigen Abschnitt getan haben, 163 00:07:27,770 --> 00:07:30,600 ‫haben wir im Grunde eine E/A-Aufgabe ausgeführt, und 164 00:07:30,600 --> 00:07:32,320 ‫deshalb haben die Ereignisschleife und 165 00:07:32,320 --> 00:07:34,640 ‫damit Node. js, laufen 166 00:07:34,640 --> 00:07:38,600 ‫Sie weiter und hören Sie auf neue HTTP-Anforderungen, die 167 00:07:38,600 --> 00:07:41,920 ‫eintreffen, anstatt nur die Anwendung zu beenden. 168 00:07:41,920 --> 00:07:44,450 ‫Wenn wir im Hintergrund eine Datei 169 00:07:44,450 --> 00:07:47,480 ‫schreiben oder lesen, ist das auch eine E/A-Aufgabe, und 170 00:07:47,480 --> 00:07:50,210 ‫daher ist es sinnvoll, dass die App nicht 171 00:07:50,210 --> 00:07:53,260 ‫beendet wird, während sie mit dieser Datei arbeitet, oder? 172 00:07:53,260 --> 00:07:55,780 ‫Okay, und das ist im Grunde das, was Sie über 173 00:07:55,780 --> 00:07:57,930 ‫den Node wissen sollten. js-Ereignisschleife. 174 00:07:57,930 --> 00:08:00,260 ‫Wenn Sie noch mehr Details benötigen, können 175 00:08:00,260 --> 00:08:01,760 ‫Sie jederzeit versuchen, 176 00:08:01,760 --> 00:08:04,860 ‫die offizielle Node-Dokumentation zu lesen, die für Sie an 177 00:08:04,860 --> 00:08:07,060 ‫dieser Stelle recht leicht verständlich sein 178 00:08:07,060 --> 00:08:10,570 ‫sollte, da Sie ohnehin den größten Teil der Ereignisschleife verstehen. 179 00:08:10,570 --> 00:08:12,830 ‫Und ich möchte nur betonen, 180 00:08:12,830 --> 00:08:15,940 ‫dass es wirklich sehr wichtig für Sie ist, die 181 00:08:15,940 --> 00:08:18,280 ‫Ereignisschleife richtig zu verstehen, damit Sie Ihren 182 00:08:18,280 --> 00:08:21,390 ‫eigenen Leistungscode schreiben und auch Ihren eigenen Code debuggen 183 00:08:21,390 --> 00:08:24,173 ‫können, wenn etwas auf unerwartete Weise schief geht. 184 00:08:25,720 --> 00:08:27,770 ‫Und jetzt, zum Abschluss, lassen Sie uns einige der Dinge, über 185 00:08:27,770 --> 00:08:29,810 ‫die wir hier gesprochen haben, noch einmal Revue passieren lassen. 186 00:08:29,810 --> 00:08:32,490 ‫Kurz gesagt, das Wichtigste, was Sie in dieser 187 00:08:32,490 --> 00:08:34,620 ‫Vorlesung und vielleicht auch in diesem 188 00:08:34,620 --> 00:08:36,740 ‫gesamten Kurs verstehen sollten, ist, dass 189 00:08:36,740 --> 00:08:38,560 ‫die Ereignisschleife die asynchrone Programmierung 190 00:08:38,560 --> 00:08:41,630 ‫in Node ermöglicht. js, was es 191 00:08:41,630 --> 00:08:45,190 ‫zum wichtigsten Feature im Design von Node macht 192 00:08:45,190 --> 00:08:47,580 ‫und Node. js völlig 193 00:08:47,580 --> 00:08:49,050 ‫anders als andere Plattformen. 194 00:08:49,050 --> 00:08:51,600 ‫Es kümmert sich um alle eingehenden 195 00:08:51,600 --> 00:08:55,120 ‫Ereignisse und führt die Orchestrierung durch, indem es schwerere Aufgaben 196 00:08:55,120 --> 00:08:58,840 ‫in den Thread-Pool auslagert und die einfachste Arbeit selbst erledigt. 197 00:08:58,840 --> 00:09:01,520 ‫Denken Sie auch daran, dass wir die Ereignisschleife 198 00:09:01,520 --> 00:09:05,260 ‫benötigen, da in Node. js funktioniert alles in 199 00:09:05,260 --> 00:09:07,260 ‫einem einzigen Thread, und so 200 00:09:07,260 --> 00:09:11,230 ‫können Tausende oder Millionen von Benutzern gleichzeitig auf denselben Thread zugreifen. 201 00:09:11,230 --> 00:09:13,690 ‫Dies macht Node so leicht und skalierbar, 202 00:09:13,690 --> 00:09:16,290 ‫birgt aber gleichzeitig die Gefahr, dass unser 203 00:09:16,290 --> 00:09:17,930 ‫einzelner Thread blockiert 204 00:09:17,930 --> 00:09:20,140 ‫wird, was die gesamte App verlangsamen 205 00:09:20,140 --> 00:09:25,140 ‫oder sogar für alle Ihre Benutzer, die auf die App zugreifen, stoppen würde, richtig? 206 00:09:25,340 --> 00:09:28,110 ‫In anderen Sprachen wie PHP, das 207 00:09:28,110 --> 00:09:31,300 ‫auf einem Apache-Server läuft, wird im Grunde genommen für 208 00:09:31,300 --> 00:09:35,200 ‫jeden neuen Benutzer ein neuer Thread erstellt, was viel ressourcenintensiver ist. 209 00:09:35,200 --> 00:09:37,180 ‫Auf der anderen Seite besteht 210 00:09:37,180 --> 00:09:39,160 ‫aber keine Blockierungsgefahr, oder? 211 00:09:39,160 --> 00:09:41,430 ‫Dieses ganze Modell macht es Anfängern etwas 212 00:09:41,430 --> 00:09:44,340 ‫einfacher, PHP zu verwenden, aber es hat natürlich auch 213 00:09:44,340 --> 00:09:46,540 ‫seine eigenen Nachteile, auf die 214 00:09:46,540 --> 00:09:48,890 ‫ich an dieser Stelle nicht eingehen werde. 215 00:09:48,890 --> 00:09:50,690 ‫Wie auch immer, lassen Sie 216 00:09:50,690 --> 00:09:54,860 ‫mich Sie noch einmal daran erinnern, dass es in Ihrer Verantwortung liegt, die Ereignisschleife 217 00:09:54,860 --> 00:09:58,150 ‫nicht zu blockieren, und deshalb hier ein paar Richtlinien dafür. 218 00:09:58,150 --> 00:10:00,490 ‫Verwenden Sie zunächst nicht 219 00:10:00,490 --> 00:10:02,850 ‫die Sync-Versionen der Funktionen in den 220 00:10:02,850 --> 00:10:06,450 ‫Modulen fs, crypto oder zlib in Ihren Callback-Funktionen, okay? 221 00:10:06,450 --> 00:10:09,210 ‫In unserem ersten Projekt haben wir also tatsächlich 222 00:10:09,210 --> 00:10:12,610 ‫die synchrone Version verwendet, aber sie war im Code der 223 00:10:12,610 --> 00:10:15,000 ‫obersten Ebene, also außerhalb jedes Rückrufs. 224 00:10:15,000 --> 00:10:18,520 ‫Und da dieser Code ausgeführt wird, bevor die Ereignisschleife überhaupt 225 00:10:18,520 --> 00:10:22,200 ‫beginnt, ist es kein Problem, dort die synchrone Version zu verwenden. 226 00:10:22,200 --> 00:10:24,910 ‫Außerdem, und das ist wahrscheinlich ziemlich offensichtlich, 227 00:10:24,910 --> 00:10:28,140 ‫führen Sie keine sehr komplexen Berechnungen in der Ereignisschleife durch. 228 00:10:28,140 --> 00:10:29,730 ‫Also, Sachen wie das 229 00:10:29,730 --> 00:10:33,890 ‫Knirschen von Millionen von Zahlen in Schleifen innerhalb von Schleifen oder so ähnlich. 230 00:10:33,890 --> 00:10:37,550 ‫Seien Sie als Nächstes vorsichtig mit JSON in sehr großen 231 00:10:37,550 --> 00:10:40,480 ‫Objekten, da das Parsen oder Stringifizieren von 232 00:10:40,480 --> 00:10:43,440 ‫JSON zu einem bestimmten Zeitpunkt lange dauern kann. 233 00:10:43,440 --> 00:10:47,170 ‫Und schließlich sollten Sie keine allzu komplexen regulären Ausdrücke 234 00:10:47,170 --> 00:10:49,840 ‫verwenden, beispielsweise mit mehreren verschachtelten Quantoren 235 00:10:49,840 --> 00:10:52,130 ‫oder Rückverweisen, da diese 236 00:10:52,130 --> 00:10:54,810 ‫wiederum länger dauern können als erwartet. 237 00:10:54,810 --> 00:10:56,680 ‫Dies sind natürlich nur ein paar 238 00:10:56,680 --> 00:10:59,700 ‫allgemeine Richtlinien, aber sie werden Sie auf den richtigen 239 00:10:59,700 --> 00:11:00,803 ‫Weg bringen. 240 00:11:01,650 --> 00:11:03,490 ‫Nun gibt es einige 241 00:11:03,490 --> 00:11:06,390 ‫mögliche Lösungen für diese Blockierungsprobleme, wie das manuelle Auslagern 242 00:11:06,390 --> 00:11:09,750 ‫in den Thread-Pool oder die Verwendung von untergeordneten Prozessen, und wir 243 00:11:09,750 --> 00:11:12,070 ‫könnten am Ende des Kurses oder irgendwann 244 00:11:12,070 --> 00:11:14,370 ‫in der Zukunft darüber sprechen, aber 245 00:11:14,370 --> 00:11:17,460 ‫im Moment ist es wichtig, dass Sie verstehen und befolgen 246 00:11:17,460 --> 00:11:20,110 ‫diesen Rat, die Ereignisschleife wirklich nicht zu blockieren. 247 00:11:20,110 --> 00:11:21,600 ‫Gut. 248 00:11:21,600 --> 00:11:24,520 ‫Als nächstes werde ich Ihnen ein kleines Beispiel geben, um Ihnen einige 249 00:11:24,520 --> 00:11:25,990 ‫der Dinge zu zeigen, über 250 00:11:25,990 --> 00:11:27,640 ‫die wir in der Praxis gesprochen haben.