Node 是一个服务器端 JavaScript 解释器javascript
nodejs他是用C++开发的一种运行于服务器端的语言(在服务器端运行的javascript)，能够写网站后台程序，能够作服务端应用开发。html
NODEJS，区别于，普通JS是脚本运行客户端，而NODEJS中的JS是运行于服务器端，这么说吧，NODEJS的做用至关PHP,ASP等语言。java
1.node.js是一个构建在Chrome JavaScript运行环境的平台，这是很重要的一点，node.js并非一门语言，而是一个平台node
2.node.js致力于使构建速度快、稳定的网络程序更简单web
3.node.js具备事件驱动和非阻塞I/O的特点，使之轻量级而且高效率数据库
4.node.js很是适合在分布式设备运行数据密集型实时应用程序apache
服务器端运行的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 在客户端上监听服务端来的推送（例如，其余用户发送的消息）。
当有一个客户端发送消息的时候，发生的事情是：
这是一个最简单的例子。若是要更好的解决方案，你可使用 Redis 数据库作一个简单的缓存。在一个更高级的解决方案中，你可能须要一个消息路由来专门处理消息队列，而且须要一个更强健的发送机制，好比发送的时候覆盖上暂时离线的用户或者为离线的注册用户存储还没有接收的消息等等。可是不论你作了怎么样的改进，Node.js 都将遵循一个基本原则：响应事件，处理多个并发链接，并保持流动性的用户体验。
尽管，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，打开网页就能进行语音视频的功能。）