Ho esaminato Node.JS e tutta la documentazione e i blog parlano di come utilizza un ciclo di eventi piuttosto che un modello per richiesta.Che cos'è un ciclo di eventi e in che modo è diverso dall'utilizzo di altri modelli?
Sto avendo un po 'di confusione nel capire la differenza. Mi sento come se fossi l'80% a comprenderlo, ma non lo ha ancora pienamente capito.
Un modello filettato genera un nuovo thread per ogni richiesta. Ciò significa che si ottiene un po 'di overhead in termini di calcolo e memoria. Un ciclo di eventi viene eseguito in un singolo thread, il che significa che non si ottiene il sovraccarico.
Il risultato di ciò è che è necessario modificare il modello di programmazione. Poiché tutte queste cose diverse stanno accadendo nella stessa discussione, non puoi bloccare. Questo significa che non puoi aspettare che succeda qualcosa perché ciò bloccherebbe l'intero thread. Invece si definisce un callback che viene chiamato una volta completata l'azione. Di solito viene indicato come I/O non bloccante.
Pseudo esempio per il blocco di I/O:
row = db_query('SELECT * FROM some_table');
print(row);
Pseudo esempio per i non-blocking I/O:
db_query('SELECT * FROM some_table', function (row) {
print(row);
});
Questo esempio utilizza lambda (funzioni anonime) come essi sono utilizzati in JavaScript tutto il tempo. JS fa un uso pesante degli eventi, e questo è esattamente ciò che riguarda i callback. Una volta completata l'azione, viene attivato un evento che attiva la richiamata. Questo è il motivo per cui viene spesso indicato come modello evocato o modello asincrono.
L'implementazione di questo modello utilizza un ciclo che elabora e attiva questi eventi. Ecco perché è chiamata la coda eventi o .
Tra i primi quadri coda di eventi includono:
Penso che sia importante delineare che una coda di eventi non implica l'assenza di pool di thread. Ad esempio, node.js utilizza pesantemente i pool di thread per bloccare le operazioni internamente. Ciò che l'event queue model cahnges è il modo in cui interagire con azioni così lunghe. –
Pensare alle richieste in arrivo o ai callback come eventi, che vengono accodati ed elaborati.
Questo è esattamente lo stesso cosa viene fatto nella maggior parte dei sistemi GUI. Il sistema non può sapere quando un utente fa clic su un pulsante o effettua alcune interazioni. Ma quando lo fa, l'evento si propagherà al ciclo degli eventi, che è fondamentalmente un ciclo che controlla i nuovi eventi in coda e li elabora.
Il vantaggio è che non è necessario attendere i risultati. Invece, si registrano le funzioni di callback che vengono eseguite quando l'evento viene attivato. Ciò consente al framework di gestire le operazioni di I/O e si può facilmente fare affidamento sulla sua efficienza interna quando si tratta di azioni lunghe invece di bloccare i processi da soli.
In breve, tutto funziona in parallelo ma il tuo codice. Non ci saranno mai due frammenti di funzioni di callback in esecuzione contemporaneamente - il ciclo degli eventi è un singolo thread. I processi che eseguono roba esternamente e infine propagano eventi possono tuttavia essere distribuiti in più thread/processi.
"I processi che eseguono roba esterna e infine propagano eventi possono tuttavia essere distribuiti in più thread/processi." Questo vale anche per il motore JS vaniglia (cioè non Nodo)? Perché ho pensato la stessa cosa io stesso ... la propagazione degli eventi e le richieste esterne DEVONO essere gestite da thread separati, anche se il thread che esegue il codice JS effettivo è solo uno. Ma tutto quello che ho letto dice che anche il motore JS ** ** è single-threaded, il che mi sembra incredibile. – The111
Un ciclo evented permette a gestire il tempo necessario per parlare al disco rigido o alla rete. prendere questa lista di tempo:
Source | CPU Cycles
L1 | 3 Cycles
L2 | 14 Cycles
RAM | 250 Cycles
Disk | 41,000,000 Cycles
Network| 240,000,000 Cycles
Quella volta si sta eseguendo ricciolo in PHP è solo sprecando CPU.
Forse sii un po 'più specifico su cosa non stai capendo? – igorw