Node.JS

Node 是一个服务器端 JavaScript 解释器

nodejs他是用C++开发的一种运行于服务器端的语言(在服务器端运行的javascript)，可以写网站后台程序，可以做服务端应用开发。

NODEJS，区别于，普通JS是脚本运行客户端，而NODEJS中的JS是运行于服务器端，这么说吧，NODEJS的作用相当PHP,ASP等语言。

1.node.js是一个构建在Chrome JavaScript运行环境的平台，这是很重要的一点，node.js并不是一门语言，而是一个平台

2.node.js致力于使构建速度快、稳定的网络程序更简单

3.node.js具有事件驱动和非阻塞I/O的特色，使之轻量级并且高效率

4.node.js非常适合在分布式设备运行数据密集型实时应用程序

服务器端运行的JavaScript？

Chrome JavaScript runtime也就是我们常说的 Chrome的V8 JavaScript Engine，也就是Goole开发的一个用于Chrome浏览器的底层JavaScript引擎，用于解析JavaScript语句创建

其运行环境，保证我们写的语句在浏览器上的表现和我们预期的一致。

那么为什么说node.js是服务器端运行的JavaScript？好好地nodejs干嘛要和V8扯上关系？除了Google搞的V8解释JavaScript十分的快，十分重要的一个原因是V8 JavaScript 引擎

并不仅限于在浏览器中运行，可以嵌入任何应用程序中运行。Node.js 和.net framework类似是一个平台，但它没有像.net一样创造了一门语言——C#在这个平台上运行，而是很巧妙的借用了web开发人员已经非常熟悉的JavaScript语法，使用V8引擎来解析语句，并将其重建可在服务器上使用。

所以严格上说node.js并不是服务器端运行的Javascript，而是可以在服务器端运行JavaScript语法的平台。

Node 旨在解决什么问题？

Node 公开宣称的目标是 “旨在提供一种简单的构建可伸缩网络程序的方法”。当前的服务器程序有什么问题？我们来做个数学题。在 Java™ 和 PHP 这类语言中，每个连接都会生成一个新线程，每个新线程可能需要 2 MB 配套内存。在一个拥有 8 GB RAM 的系统上，理论上最大的并发连接数量是 4,000 个用户。随着您的客户端基础的增长，您希望您的web 应用程序支持更多用户，这样，您必须添加更多服务器。当然，这会增加业务成本，尤其是服务器成本、运输成本和人工成本。除这些成本上升外，还有一个技术问 题：用户

可能针对每个请求使用不同的服务器，因此，任何共享资源都必须在所有服务器之间共享。例如，在 Java 中，静态变量和缓存需要在每个服务器上的 JVMs 之间共享。这就是整个 web 应用程序架构中的瓶颈：一个服务器能够处理的并发连接的最大数量。

Node 解决这个问题的方法是：更改连接连接到服务器的方式。每个连接都创建一个进程，该进程不需要配套内存块，而不是为每个连接生成一个新的 OS 线程（并向其分配一些配套内存）。Node 声称它绝不会死锁，因为它根本不允许使用锁，它不会直接阻塞 I/O 调用。Node 还宣称，运行它的服务器能支持数万个并发连接。事实上，Node 通过将整个系统中的瓶颈从最大连接数量更改到单个系统的流量来改变服务器面貌。

现在您有了一个能处理数万条并发连接的程序，那么您能通过 Node 实际构建什么呢？如果您有一个 web 应用程序需要处理这么多连接，那将是一件很 “恐怖” 的事！那是一种 “如果您有这个问题，那么它根本不是问题” 的问题。在回答上面的问题之前，我们先看看 Node 如何工作以及它被设计的如何运行。

它对什么有好处？

正如您此前所看到的，Node 非常适合以下情况：在响应客户端之前，您预计可能有很高的流量，但所需的服务器端逻辑和处理不一定很多。Node 表现出众的典型示例包括：

RESTful API

提供 RESTful API 的 Web 服务接收几个参数，解析它们，组合一个响应，并返回一个响应（通常是较少的文本）给用户。这是适合 Node 的理想情况，因为您可以构建它来处理数万条连接。它仍然不需要大量逻辑；它本质上只是从某个数据库中查找一些值并将它们组成一个响应。由于响应是少量文本，入站请求也是少量的文本，因此流量不高，一台机器甚至也可以处理最繁忙的公司的 API 需求。

Twitter 队列

想像一下像 Twitter 这样的公司，它必须接收 tweets 并将其写入数据库。实际上，每秒几乎有数千条 tweet 达到，数据库不可能及时处理高峰时段所需的写入数量。Node 成为这个问题的解决方案的重要一环。如您所见，Node 能处理数万条入站 tweet。它能快速而又轻松地将它们写入一个内存排队机制（例如 memcached），另一个单独进程可以从那里将它们写入数据库。Node 在这里的角色是迅速收集 tweet，并将这个信息传递给另一个负责写入的进程。想象一下另一种设计（常规 PHP 服务器会自己尝试处理对数据库本身的写入）：每个 tweet 都会在写入数据库时导致一个短暂的延迟，因为数据库调用正在阻塞通道。由于数据库延迟，一台这样设计的机器每秒可能只能处理 2000 条入站 tweet。每秒处理 100 万条 tweet 则需要 500 个服务器。相反，Node 能处理每个连接而不会阻塞通道，从而能够捕获尽可能多的 tweets。一个能处理 50,000 条 tweet 的 Node 机器仅需 20 台服务器即可。

电子游戏统计数据

如果您在线玩过《使命召唤》这款游戏，当您查看游戏统计数据时，就会立即意识到一个问题：要生成那种级别的统计数据，必须跟踪海量信息。这样，如果有数百万玩家同时在线玩游戏，而且他们处于游戏中的不同位置，那么很快就会生成海量信息。Node 是这种场景的一种很好的解决方案，因为它能采集游戏生成的数据，对数据进行最少的合并，然后对数据进行排队，以便将它们写入数据库。使用整个服务器来跟踪玩家在游戏中发射了多少子弹看起来很愚蠢，如果您使用 Apache 这样的服务器，可能会 有一些有用的限制；但相反，如果您专门使用一个服务器来跟踪一个游戏的所有统计数据，就像使用运行 Node 的服务器所做的那样，那看起来似乎是一种明智之举。 

Node.js 的优势是「高并发」，所以很适合用来做 IO 调度，但不太适合用来做复杂计算。 

1. NodeJS作为web server是一个相当出色的IO服务器，而Nodejs性能之所以如此高是依赖于joyent自己搞的libuv，而开发效率之所以高是因为v8，所以如果你觉得js不好调试，大可以直接使用libuv，然后各种断点，当然这是在你不会使用nodejs自带的debug模块的前提下

2. NodeJS真的就只能做做web server，其他免谈。问题来源主要是v8与内存问题，之前做过一个类似爬虫的程序，需要支持万级别用户，用NodeJS写的话，效率没有问题，但内存问题严重，500个任务就需要消耗差不多700-800M空间，后台用libuv+c重写，业务逻辑类似，已经可以单机支持4w-5w的用户量了。因此如果是对内存有非常严格的要求，就建议不要使用node了

很多公司已经尝试使用nodejs做些实时的并发后端。盲目将nodejs来做web框架使用，并不一定可以发挥其优势，而且现在大多数公司不会贸然将新兴的技术用在核心的业务上，比如说web框架。但在其真正有优势的领域，有技术前瞻性的技术领头人，还是会合理采用。我所知道的使用nodejs做生产级别应用的，包括搜狐，搜狐小纸条后端就是用nodejs来处理消息的推送的，之前跟其负责人有过交流。并不像很多人所言，nodejs会首先在web前段业务层上取代PHP等语言，相反，我认为，其最有可能会首先在服务器端取代原有的很多mq，server做某些工作，而这也应该是正确的方向。

它的工作原理是相当有趣的。传统的网络服务技术，是每个新增一个连接（请求）便生成一个新的线程，这个新的线程会占用系统内存，最终会占掉所有的可用内存。而 Node.js 仅仅只运行在一个单线程中，使用非阻塞的异步 I/O 调用，所有连接都由该线程处理，在 libuv 的加分下，可以允许其支持数万并发连接（全部挂在该线程的事件循环中）。

Node.js 应该用在什么地方

聊天

聊天是最典型的多用户实时交互的应用。从 IRC 开始，有许多开源或者不开源的协议都运行在非标准端口上，而现在，使用 Node.js 则可以解决这些问题——在标准的80端口运行 WebSockets。

聊天应用程序是最能体现 Node.js 优点的例子：轻量级、高流量并且能良好的应对跨平台设备上运行密集型数据（虽然计算能力低）。同时，聊天也是一个非常值得学习的用例，因为它很简单，并且涵盖了目前为止一个典型的 Node.js 会用到的大部分解决方案。

让我们试着来描绘它如何工作。

在最简单的情况下，我们布置了一个聊天室在我们的网站上，用户可以在上面发消息，当然是一对多的形式。例如，假设总共有三个人连接到我们的网站上。

在服务端这边， 我们有一个使用 Express.js 搭建的简单站点，该站点实现了两件事 1) 处理路径为 ‘/’ 的GET请求时，下发包括一个留言板以及一个发送信息的 ‘发送’ 按钮的页面 2) 一个监听客户端发送新消息的 websockets 服务。

在客户端这边，我们有一个 HTML 页面，上面有个两个 js 方法，一个是用于触发事件的 “发送” 按钮，这会把把输入的消息通过 webscoket 发送，另一个方法是用 webscoket 在客户端上监听服务端来的推送（例如，其他用户发送的消息）。

当有一个客户端发送消息的时候，发生的事情是：

1. 浏览器上，点击发送按钮触发了 js 函数，将输入框中的文字通过 websocket 消息发送到服务器的 websocket 客户端（页面初始化加载的时候连接的）。
2. 服务端的 websocket 组件收到 消息，然后通过广播方法转发到其他所有连接的客户端。
3. 通过页面上运行的 websocket 客户端组件，所有的客户端都能收到这条推送的新消息。接着 js 处理函数可以把这个消息添加到文字框内。

这是一个最简单的例子。如果要更好的解决方案，你可以使用 Redis 数据库做一个简单的缓存。在一个更高级的解决方案中，你可能需要一个消息路由来专门处理消息队列，并且需要一个更强健的发送机制，比如发送的时候覆盖上暂时离线的用户或者为离线的注册用户存储尚未接收的消息等等。但是不论你做了怎么样的改进，Node.js 都将遵循一个基本原则：响应事件，处理多个并发连接，并保持流动性的用户体验。

对象数据库接口（API ON TOP OF AN OBJECT DB）

尽管，Node.js 确实非常擅长实时交互的应用，同时它也十分适合通过对象数据库（object DB）来查询数据（如 MongoDB）。以 JSON 格式存储的数据允许 Node.js 直接处理，不需要纠结数据转换和匹配的问题。

举个例子，如果你正在使用 Rails，你会将 JSON 数据转成 二进制的 model，当数据再被 Backbone.js, Angular.js 或者 jQuery AJAX 之类的调用又要转回 JSON。如果是 Nodejs 的话，你可以通过一个 REST API 简单的导出 JSON 对象以供客户端使用。另外，从数据库读写时候如果使用的是 MongoDB 的话，你也不用担心的 JSON 与任何数据之间的格式问题。总之，你可以避免多元的数据转换问题，不论是在客户端、服务端还是数据库。

队列输入

如果你正在接收一个高量并发的数据，你的数据库可能会成为你处理的瓶颈。正如上面的描述，Node.js 可以轻松的处理并发连接。 但是，由于数据库操作是一个阻塞的操作（在这种情况下），这就是麻烦的地方。Node.js的解决方案是，在数据真正的写入之前就承认客户端的数据是真实的。

用这种方法，在高负载的时候系统继续维持它的响应，这在当客户端不需要严格确认一个数据是否成功的被写入时特别有用。典型的例子包括：日志记录或者用户跟踪数据（user-tracking data）的记录，这会被分批处理并且在稍后才使用；同时也包括最终一致性（so, 常用于 NoSQL）可以接受，不需要立即反应的操作（例如 Facebook 上更新点赞的数目）。

数据通过某些缓存或者消息队列的基础组件（例如 RabbitMQ, ZeroMQ）进入队列，并且通过一个独立的数据库批量写入进程来一一消化，或者通过一个更高性能的计算密集型后端服务来进行处理。其他的语言/框架也可以实现相似的操作，但在相同的配置下是达不到 nodejs 的高吞吐量与高并发。

简单的说：使用 Node，你可以把数据库操作扔到一边并在稍后处理它们，假设他们成功了一样继续执行下去。（笔者注：在开发中通常的情况通常是，种耗时的操作通过回调函数来异步处理，主线程继续往下执行）

数据流

在较为传统的网络平台上，HTTP 的请求和响应更像是孤立的事件；然而事实上，他们都是数据流。这一观察结果在 Nodejs 上可以用来建立一些很酷的功能。因为数据通以流的形式接收，而我们可以在网站上在线处理正在上传中的文件。这样的话，就可以实现实时的音频和视频编码，以及在不同数据源之间进行代码（代理见下一段）。

（笔者注：Node 有代替如 apache 这样的 webserver 处理数据，所以开发者可以直接收到客户端一份一份上传的数据，并实时处理。上面这段话听起来有点抽象，不过各位可以简单的想象一下不需要开 YY 或者 QQ，打开网页就能进行语音视频的功能。）