Heim > Artikel > Web-Frontend > So beheben Sie das Problem: Der NodeJS-Dienst stürzt immer ab
In diesem Artikel erfahren Sie, wie Sie das Problem lösen können, dass der NodeJS-Dienst ständig abstürzt. Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird für alle hilfreich sein.
Viele Leute haben ein solches Image. NodeJS ist schneller. Da es jedoch Single-Threaded ist, ist es instabil, etwas unsicher und nicht für die Abwicklung komplexer Geschäfte geeignet Einfaches Geschäftsszenario.
Tatsächlich hat NodeJS eine „fragile“ Seite. Eine „unbehandelte“ Ausnahme, die irgendwo in einem einzelnen Thread generiert wird, führt tatsächlich dazu, dass das gesamte Node.JS abstürzt. Schauen wir uns ein Beispiel an -error.js-Datei:
var http = require('http'); var server = http.createServer(function (req, res) { //这里有个错误,params 是 undefined var ok = req.params.ok; res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello World '); }); server.listen(8080, '127.0.0.1'); console.log('Server running at http://127.0.0.1:8080/');
Starten Sie den Dienst, testen Sie ihn in der Adressleiste und suchen Sie nach http://127.0.0.1:8080/. Wie erwartet ist der Knoten abgestürzt.
$ node node-error Server running at http://127.0.0.1:8080/ c:githubscript ode-error.js:5 var ok = req.params.ok; ^ TypeError: Cannot read property 'ok' of undefined at Server.<anonymous> (c:githubscript ode-error.js:5:22) at Server.EventEmitter.emit (events.js:98:17) at HTTPParser.parser.onIncoming (http.js:2108:12) at HTTPParser.parserOnHeadersComplete [as onHeadersComplete] (http.js:121:23) at Socket.socket.ondata (http.js:1966:22) at TCP.onread (net.js:525:27)
Wie kann ich das Problem lösen?
Tatsächlich wird Node.JS mit der heutigen Entwicklung, wenn es dieses Problem nicht einmal lösen kann, wahrscheinlich schon vor langer Zeit niemand mehr verwenden.
Wir können uncaughtException verwenden, um nicht erfasste Fehler global zu erfassen. Gleichzeitig können Sie auch den Aufrufstapel dieser Funktion ausdrucken. Nach der Erfassung kann dadurch effektiv verhindert werden, dass der Knotenprozess beendet wird.
process.on('uncaughtException', function (err) { //打印出错误 console.log(err); //打印出错误的调用栈方便调试 console.log(err.stack); });
Dies entspricht Guard innerhalb des Node-Prozesses, aber viele Leute befürworten diese Methode nicht, was bedeutet, dass Sie die Ausnahmen von Node.JS nicht vollständig kontrollieren können.
Wir können try/catch auch vor dem Rückruf hinzufügen, um auch die Thread-Sicherheit zu gewährleisten.
var http = require('http'); http.createServer(function(req, res) { try { handler(req, res); } catch(e) { console.log(' ', e, ' ', e.stack); try { res.end(e.stack); } catch(e) { } } }).listen(8080, '127.0.0.1'); console.log('Server running at http://127.0.0.1:8080/'); var handler = function (req, res) { //Error Popuped var name = req.params.name; res.writeHead(200, {'Content-Type': 'text/plain'}); res.end('Hello ' + name); };
Der Vorteil dieser Lösung besteht darin, dass der Fehler- und Aufrufstapel direkt auf der Webseite ausgegeben werden kann, auf der er gerade auftritt.
Die Standard-HTTP-Antwortverarbeitung durchläuft eine Reihe von Middleware (HttpModule) und erreicht schließlich den Handler, wie in der folgenden Abbildung dargestellt:
Diese Middleware und dieser Handler verfügen über eine Funktion in NodeJS , Sie sind alle Rückruffunktionen, und die Rückruffunktion ist der einzige Ort, an dem Node zur Laufzeit abstürzt. Gemäß dieser Funktion müssen wir nur einen Try/Catch in das Framework integrieren, um das Ausnahmeproblem relativ perfekt zu lösen, und die Anforderungen anderer Benutzer werden dadurch nicht beeinträchtigt.
Tatsächlich tun dies fast alle aktuellen NodeJS-WEB-Frameworks. Zum Beispiel hat WebSvr, auf dem unser Open-Source-Blog basiert,
einen solchen Ausnahmebehandlungscode:
Line: 207 try { handler(req, res); } catch(err) { var errorMsg = ' ' + 'Error ' + new Date().toISOString() + ' ' + req.url + ' ' + err.stack || err.message || 'unknow error' + ' ' ; console.error(errorMsg); Settings.showError ? res.end('<pre class="brush:php;toolbar:false">' + errorMsg + '') : res.end(); }
Was soll ich also tun, wenn dies nicht der Fall ist? in Rückrufen generiert? Keine Sorge, tatsächlich kann ein solches Knotenprogramm überhaupt nicht gestartet werden.
Darüber hinaus weist der eigene Cluster auch eine gewisse Fehlertoleranz auf. Er ist dem Worker von Nginx sehr ähnlich, verbraucht jedoch etwas mehr Ressourcen (Speicher) und ist nicht sehr bequem zu programmieren.
Angesichts dieser Situation sollten wir der NodeJS-Anwendung einen Daemon-Prozess hinzufügen, damit NodeJS nach einem ungewöhnlichen Absturz sofort wiederbelebt werden kann.
Außerdem sollten diese Ausnahmen im Protokoll aufgezeichnet werden, damit sie nie wieder vorkommen.
Knoten zum Schutz des Knotens verwenden
Zum Beispiel die in Debian abgelegte ourjs-Startdatei: /etc/init.d/ourjs
Diese Datei ist sehr einfach und enthält nur Startoptionen. Die Kernfunktion des Wächters wird durch eine Endlosschleife implementiert Um zu verhindern, dass zu viele Fehler den Prozess blockieren, starten Sie den Dienst alle 1 Sekunde nach jedem Fehler neu.
[sudo] npm install foreverDie Fehlerprotokollierung ist auch sehr einfach. Sie können die Fehler direkt in der Prozesskonsole in der Datei error.log ausgeben ;> $WEB_DIR/error.log In dieser Zeile steht 2 für Fehler.
Empfohlenes Lernen: Javascript-Video-Tutorial
Das obige ist der detaillierte Inhalt vonSo beheben Sie das Problem: Der NodeJS-Dienst stürzt immer ab. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!