NODE.JS是什么
1、一个连接一个进程
2、能处理很多的并发连接
3、使用的场景：
What it's good for
As you've seen so far, Node is extremely well designed for situations where you are expecting a high amount of traffic and the server-side logic and processing required isn't necessarily large before responding to the client. Good examples of where Node would excel include:
A RESTful API
A web service that provides a RESTful API takes in a few parameters, interprets them, pieces together a response, and flushes a response (usually a relatively small amount of text) back to the user. This is an ideal situation for Node, because you can build it to handle tens of thousands of connections. It also doesn't require a large amount of logic; it just looks up values from a database and pieces together a response. Since the response is a small amount of text, and the incoming request is a small amount of text, the traffic volume isn't high, and one machine can likely handle the API demands of even the busiest company's API.
Twitter queue
Think about a company like Twitter that has to receive tweets and write them to a database. There are literally thousands of tweets arriving every second, and the database can't possibly keep up with the number of writes required during peak usage times. Node becomes an important cog in the solution to this problem. As we've seen, Node can handle tens of thousands of incoming tweets. It can write them quickly and easily to an in-memory queuing mechanism (memcached for example), from which another separate process can write them to the database. Node's role in this is to quickly gather the tweet and pass this information off to another process responsible for writing it. Imagine another design — a normal PHP server that tries to handle writes to the database itself — every tweet would cause a small delay as its written to the database since the database call would be blocking. A machine with this design may only be able to handle 2000 incoming tweets a second, due to the database latency. A million tweets per second requires 500 servers. Node, instead, handles every connection and doesn't block, enabling it to capture as many tweets as possible. A node machine able to handle 50,000 tweets per second requires only 20 servers.
Image file server
A company that has a large distributed website (think Facebook or Flickr), could decide to devote entire boxes to simply serving up images. Node would be a good solution for this problem because the company can use it to code an easy file retriever and then handle tens of thousands of connections. Node would look for the image file, return it or a 404 error, and do nothing else. This setup would allow these types of distributed websites to reduce the number of server boxes they need to serve static files such as images, .js files, and .css files.
What it's bad for
Of course, Node is not the ideal choice in some situations. Here are scenarios where Node would not excel:
Dynamically created pages
Currently, Node doesn't provide a default way to create dynamic pages. For example, when using JavaServer Pages (JSP) technology you can create an index.jsp page that contains loops in JSP snippets like <% for (int i=0; i<20; i++) { } %>. Node doesn't enable these types of dynamic HTML-driven pages. Again, Node isn't ideally suited to be a web page server, as Apache and Tomcat are. Therefore, if you wanted to provide a server-side solution for this in Node, you'd have to code the entire solution yourself. A PHP programmer wouldn't want to program a PHP converter for Apache every time they deployed a web application, but at this point, that's what Node would require you to do.
Relational database heavy applications
Node is designed to be fast, asynchronous, and non-blocking. Databases don't necessarily share these goals. They are synchronous and blocking, as calls to the database on writes and reads block until a result is generated. So, a web application that requires a lot of database calls, a lot of reads, and a lot of writes with every request would be a bad match for Node, since the relational database itself would be negating many of the strengths of Node. (The new NoSQL databases are a better match for Node, but that's another topic entirely.)
Node accomplishes its goals of providing highly scalable servers. It doesn't allocate a thread-per-connection model, but instead uses a process-per-connection model, creating only the memory that is required for each connection. It uses an extremely fast JavaScript engine from Google, the V8 engine. It uses an event-driven design to keep code minimal and easy-to-read. All of these factors lead to Node's desired goal — it's relatively easy to write a massively scalable solution.
http://www.ibm.com/developerworks/opensource/library/os-nodejs/index.html
2、能处理很多的并发连接
3、使用的场景：
What it's good for
As you've seen so far, Node is extremely well designed for situations where you are expecting a high amount of traffic and the server-side logic and processing required isn't necessarily large before responding to the client. Good examples of where Node would excel include:
A RESTful API
A web service that provides a RESTful API takes in a few parameters, interprets them, pieces together a response, and flushes a response (usually a relatively small amount of text) back to the user. This is an ideal situation for Node, because you can build it to handle tens of thousands of connections. It also doesn't require a large amount of logic; it just looks up values from a database and pieces together a response. Since the response is a small amount of text, and the incoming request is a small amount of text, the traffic volume isn't high, and one machine can likely handle the API demands of even the busiest company's API.
Twitter queue
Think about a company like Twitter that has to receive tweets and write them to a database. There are literally thousands of tweets arriving every second, and the database can't possibly keep up with the number of writes required during peak usage times. Node becomes an important cog in the solution to this problem. As we've seen, Node can handle tens of thousands of incoming tweets. It can write them quickly and easily to an in-memory queuing mechanism (memcached for example), from which another separate process can write them to the database. Node's role in this is to quickly gather the tweet and pass this information off to another process responsible for writing it. Imagine another design — a normal PHP server that tries to handle writes to the database itself — every tweet would cause a small delay as its written to the database since the database call would be blocking. A machine with this design may only be able to handle 2000 incoming tweets a second, due to the database latency. A million tweets per second requires 500 servers. Node, instead, handles every connection and doesn't block, enabling it to capture as many tweets as possible. A node machine able to handle 50,000 tweets per second requires only 20 servers.
Image file server
A company that has a large distributed website (think Facebook or Flickr), could decide to devote entire boxes to simply serving up images. Node would be a good solution for this problem because the company can use it to code an easy file retriever and then handle tens of thousands of connections. Node would look for the image file, return it or a 404 error, and do nothing else. This setup would allow these types of distributed websites to reduce the number of server boxes they need to serve static files such as images, .js files, and .css files.
What it's bad for
Of course, Node is not the ideal choice in some situations. Here are scenarios where Node would not excel:
Dynamically created pages
Currently, Node doesn't provide a default way to create dynamic pages. For example, when using JavaServer Pages (JSP) technology you can create an index.jsp page that contains loops in JSP snippets like <% for (int i=0; i<20; i++) { } %>. Node doesn't enable these types of dynamic HTML-driven pages. Again, Node isn't ideally suited to be a web page server, as Apache and Tomcat are. Therefore, if you wanted to provide a server-side solution for this in Node, you'd have to code the entire solution yourself. A PHP programmer wouldn't want to program a PHP converter for Apache every time they deployed a web application, but at this point, that's what Node would require you to do.
Relational database heavy applications
Node is designed to be fast, asynchronous, and non-blocking. Databases don't necessarily share these goals. They are synchronous and blocking, as calls to the database on writes and reads block until a result is generated. So, a web application that requires a lot of database calls, a lot of reads, and a lot of writes with every request would be a bad match for Node, since the relational database itself would be negating many of the strengths of Node. (The new NoSQL databases are a better match for Node, but that's another topic entirely.)
Node accomplishes its goals of providing highly scalable servers. It doesn't allocate a thread-per-connection model, but instead uses a process-per-connection model, creating only the memory that is required for each connection. It uses an extremely fast JavaScript engine from Google, the V8 engine. It uses an event-driven design to keep code minimal and easy-to-read. All of these factors lead to Node's desired goal — it's relatively easy to write a massively scalable solution.
http://www.ibm.com/developerworks/opensource/library/os-nodejs/index.html