㈠ 为什么要用nodejs
著作权归作者所有。
商业转载请联系作者获得授权，非商业转载请注明出处。
作者：FengqiAsia
链接：http://www.hu.com/question/19653241/answer/15993549
来源：知乎
要讲清楚这个问题，先讲讲整个Web应用程序架构（包括流量、处理器速度和内存速度）中的瓶颈。瓶颈在于服务器能够处理的并发连接的最大数量。Node.js解决这个问题的方法是：更改连接到服务器的方式。每个连接发射一个在Node.js引擎的进程中运行的事件，而不是为每个连接生成一个新的OS线程（并为其分配一些配套内存）。Node.js不会死锁，因为它根本不允许使用锁，它不会直接阻塞 I/O 调用。Node.js还宣称，运行它的服务器能支持数万个并发连接。
Node本身运行V8 JavaScript。V8 JavaScript引擎是Google用于其Chrome浏览器的底层JavaScript引擎。Google使用V8创建了一个用C++编写的超快解释器，该解释器拥有另一个独特特征：您可以下载该引擎并将其嵌入任何应用程序。V8 JavaScript引擎并不仅限于在一个浏览器中运行。因此，Node.js实际上会使用Google编写的V8 JavaScript引擎，并将其重建为可在服务器上使用。
Node.js优点：
1、采用事件驱动、异步编程，为网络服务而设计。其实Javascript的匿名函数和闭包特性非常适合事件驱动、异步编程。而且JavaScript也简单易学，很多前端设计人员可以很快上手做后端设计。
2、Node.js非阻塞模式的IO处理给Node.js带来在相对低系统资源耗用下的高性能与出众的负载能力，非常适合用作依赖其它IO资源的中间层服务。3、Node.js轻量高效，可以认为是数据密集型分布式部署环境下的实时应用系统的完美解决方案。Node非常适合如下情况：在响应客户端之前，您预计可能有很高的流量，但所需的服务器端逻辑和处理不一定很多。
Node.js缺点：
1、可靠性低
2、单进程，单线程，只支持单核CPU，不能充分的利用多核CPU服务器。一旦这个进程崩掉，那么整个web服务就崩掉了。
不过以上缺点可以可以通过代码的健壮性来弥补。目前Node.js的网络服务器有以下几种支持多进程的方式：
#1 开启多个进程，每个进程绑定不同的端口，用反向代理服务器如 Nginx 做负载均衡，好处是我们可以借助强大的 Nginx 做一些过滤检查之类的操作，同时能够实现比较好的均衡策略，但坏处也是显而易见——我们引入了一个间接层。
#2 多进程绑定在同一个端口侦听。在Node.js中，提供了进程间发送“文件句柄” 的功能，这个功能实在是太有用了（貌似是yahoo 的工程师提交的一个patch） ，不明真相的群众可以看这里： Unix socket magic
#3 一个进程负责监听、接收连接，然后把接收到的连接平均发送到子进程中去处理。
在Node.js v0.5.10+ 中，内置了cluster 库，官方宣称直接支持多进程运行方式。Node.js 官方为了让API 接口傻瓜化，用了一些比较tricky的方法，代码也比较绕。这种多进程的方式，不可避免的要牵涉到进程通信、进程管理之类的东西。
此外，有两个Node.js的mole：multi-node 和 cluster ，采用的策略和以上介绍的类似，但使用这些mole往往有一些缺点：
#1 更新不及时
#2 复杂庞大，往往绑定了很多其他的功能，用户往往被绑架
#3 遇到问题难以解决
Node表现出众的典型示例包括：
1、RESTful API
提供RESTful API的Web服务接收几个参数，解析它们，组合一个响应，并返回一个响应（通常是较少的文本）给用户。这是适合Node的理想情况，因为您可以构建它来处理数万条连接。它仍然不需要大量逻辑；它本质上只是从某个数据库中查找一些值并将它们组成一个响应。由于响应是少量文本，入站请求也是少量的文本，因此流量不高，一台机器甚至也可以处理最繁忙的公司的API需求。
2、Twitter队列
想像一下像Twitter这样的公司，它必须接收tweets并将其写入数据库。实际上，每秒几乎有数千条tweet达到，数据库不可能及时处理高峰时段所需的写入数量。Node成为这个问题的解决方案的重要一环。如您所见，Node能处理数万条入站tweet。它能快速而又轻松地将它们写入一个内存排队机制（例如memcached），另一个单独进程可以从那里将它们写入数据库。Node在这里的角色是迅速收集tweet，并将这个信息传递给另一个负责写入的进程。想象一下另一种设计（常规PHP服务器会自己尝试处理对数据库本身的写入）：每个tweet都会在写入数据库时导致一个短暂的延迟，因为数据库调用正在阻塞通道。由于数据库延迟，一台这样设计的机器每秒可能只能处理2000条入站tweet。每秒处理100万条tweet则需要500个服务器。相反，Node能处理每个连接而不会阻塞通道，从而能够捕获尽可能多的tweets。一个能处理50000条tweet的Node机器仅需20台服务器即可。
3、电子游戏统计数据
如果您在线玩过《使命召唤》这款游戏，当您查看游戏统计数据时，就会立即意识到一个问题：要生成那种级别的统计数据，必须跟踪海量信息。这样，如果有数百万玩家同时在线玩游戏，而且他们处于游戏中的不同位置，那么很快就会生成海量信息。Node是这种场景的一种很好的解决方案，因为它能采集游戏生成的数据，对数据进行最少的合并，然后对数据进行排队，以便将它们写入数据库。使用整个服务器来跟踪玩家在游戏中发射了多少子弹看起来很愚蠢，如果您使用Apache这样的服务器，可能会有一些有用的限制；但相反，如果您专门使用一个服务器来跟踪一个游戏的所有统计数据，就像使用运行Node的服务器所做的那样，那看起来似乎是一种明智之举。
总的来说，Node.js的应用场景
1) 适合
JSON APIs——构建一个Rest/JSON API服务，Node.js可以充分发挥其非阻塞IO模型以及JavaScript对JSON的功能支持(如JSON.stringfy函数)
单页面、多Ajax请求应用——如Gmail，前端有大量的异步请求，需要服务后端有极高的响应速度
基于Node.js开发Unix命令行工具——Node.js可以大量生产子进程，并以流的方式输出，这使得它非常适合做Unix命令行工具
流式数据——传统的Web应用，通常会将HTTP请求和响应看成是原子事件。而Node.js会充分利用流式数据这个特点，构建非常酷的应用。如实时文件上传系统transloadit
准实时应用系统——如聊天系统、微博系统，但Javascript是有垃圾回收机制的，这就意味着，系统的响应时间是不平滑的(GC垃圾回收会导致系统这一时刻停止工作)。如果想要构建硬实时应用系统，Erlang是个不错的选择
2) 不适合
CPU使用率较重、IO使用率较轻的应用——如视频编码、人工智能等，Node.js的优势无法发挥
简单Web应用——此类应用的特点是，流量低、物理架构简单，Node.js无法提供像Ruby的Rails或者Python的Django这样强大的框架
NoSQL + Node.js——如果仅仅是为了追求时髦，且自己对这两门技术还未深入理解的情况下，不要冒险将业务系统搭建在这两个漂亮的名词上，建议使用MySQL之类的传统数据库
如果系统可以匹配Node.js的适用场景，那么是时候采取具体的措施来说服老板了。
说服自己老板采用Node.js的方式
构建一个简单的原型——花一周时间构建系统某一部分的原型是非常值得的，同时也很容易和老板在某一点达成一致，等到系统真的在某一部分应用了Node.js，就是打开局面的时候
寻找开发者——首先JavaScript语言的普及度很高，一般公司都不乏Web前端工程师，而此类工程师的学习门槛也非常低。这就意味着Node.js很容易招人，或者公司就隐藏了一些高手
强大的社区支持——Node.js社区非常活跃，吸引很多优秀的工程师，这就意味着公司可以很容易从社区得到免费或者付费的支持
系统性能考虑——JavaScript引擎Google V8，加之原生异步IO模型，使得Node.js在性能的表现非常出色，处理数以千计的并发请求非常轻松
专业公司的支持——使用开源技术的最大问题是，原作者不承诺对其产品进行技术支持或者质量保证。现在Node.js已经得到Joyent公司的赞助，这就保证了未来Node.js的发展是可持续性的
㈡ Nodejs是不是会阻塞
如果mongodb与node不竞争CPU的话，光是数据查询网络传输部分是非阻塞的，但是查询过来对数据再处理，这个部分是同步的，如果计算量大就会阻塞。如果存在竞争CPU的情况，那说明计算资源不够，得加PU。异步的本质是让别人做事情，如果没有别人了，都自己干，本质上其实还是同步的，还是一个接一个干，而且还要付出进程的代价。
回调函数内执行的内容除了异步命令函数，其他的都是同步的，如果计算量大，肯定是阻塞的。
㈢ nvidianodejslauncher32位占用率高
主要原因如下：一、硬件方面导致的CPU使用率高
1、其实硬件方面决定着比较大的关系，可能是由于硬件已经有一段时间没有更新，性能比较一般，如果是运行新出的大型软件会导致CPU长时间处于高负荷的运行状态，遇到这种情况只能够更新硬件。
二、软件方面导致的CPU使用率高
这方面主要涉及到的是系统问题，比如系统过于臃肿，开启过多程序以及电脑中病毒木马等等都会产生CPU使用率过高，而导致电脑速度慢。解决办法主要是围绕系统优化，优化开机启动项、尽量避免开启太多程序等等。
CPU常见故障检修：
故障现象：CPU温度高
1、检查一下机箱内的风扇是否正常运转。
2、清理机箱内的灰尘（可以使用吹风筒）。
3、在CPU与散热片间一定要加导热硅脂。（均匀涂抹，不宜太厚）
4、在散热风扇轴承处滴上一滴缝纫机油，这样可有效降低噪音！
5、必要时可以加装大功率CPU风扇，购买散热效果更好的散热器，带铜管散热的塔式散热器等。
6、加装机箱散热风扇（一定要买双滚珠轴承的）。（机箱内有很强的电磁辐射，对人体有害，建议不要打开机箱盖散热）。
㈣ NodeJS会是昙花一现吗
在用了一年以后，我感觉node.js有一点不对劲。它很有意思，但是我觉得我应该用另外一个视角去审视它。
网络编程真的可以更容易吗？
node.js无疑有一些设计非常好的地方。前段时间我写了一个性能非常高的Syslog Collector系统，它可以每秒处理25万个日志，可以同时处理数千个TCP并发连接。它还支持UDP，HTTP和SSL.它是C++写的，使用了
Boost.Asio 架构。它几乎从来不会崩溃。 很少会内存泄露。但是它花了我5个月的时间去编辑（然后重写），测试还有布署。所以，你要知道，写相似的node程序真的不会让你加快开发进度。
需要一个HTTP服务器？require（导入）
http 模块，如果你想要一台socket服务器的话，还需要net模块。node是一个事件驱动的框架。相对于为每个链接创始一个线程模型相比有极大的性能优势，node.js取得了
twisted无法能取得的成功。 （注* twisted 基于python的异步驱动框架）
node.js的问题是什么？
JavaScript
让我们先说JavaScript －
我喜欢用它的闭包，但是这个语言太扯蛋了。甚至是JavaScriptr的铁杆粉丝都知道它有多可笑。JavaScript the Good
Parts （JavaScript好的方面） 真的是一本很簿的书，对比一下你会觉得很有趣。
你会发现下面的代码根本不会报错：
undefined=42
然后你输入这个看看？
> [] + []
''
为什么1个空数组加上另外一个空数组会等于空字符串？
然后这个呢？
> [] + [] * 5
'0'
解释JavaScript为什么会这样其实挺困难的。就像为
无数个猴子设计的语言。 所以在线编程是非常重要，你得经常打印一下看看到底会输出什么。
调试
我看到的大多数node.js程序员都在用一种非常原始的方式在调试，并不断地对他们用的工具表示失望。跟踪回调里不该招聘的异常，在类似Mocha和
Chai的测试框架中，经常会像恶梦一样。时间不断地花在寻找为什么会出错上面。console.log也许是开发者最常使用的调试工具。
回调地狱
大多数程序员，只要在node上面写了36个小时的代码，就会发现callback hell。有些
文章 介绍了一些避免的方法。具有讽刺意味的是，这是node的异步和事件驱动所天生的。它带来了很多性能上的优势，但导致了这种难看和不可靠代码的产生。
但是我们有
Promises。
是的，我同意。不过如果不是用Bluebird这样的模块，我估计大多数node程序员马上就会放弃。我非常喜欢用Promise模式，它写出的代码非常
优美。Promise的链式写法是非常好的实践。但是它让你放弃了彻底修复回调地狱的想法。我严重怀疑这一点会破坏NodeJS在生产环境应用的可能性。
我只会占用一个核，但只能用一个核。
node.js总是运行在一个进程里。这让他进行跨函数和跨模块的调用更加的简单。但这并不意味着是没有代价的，你必须确保你在做出更改的时侯进程不被打断。但是当你使用多核CPU时，你就无法发挥出其它处理器的性能。你就开始骂娘了。当然node里面有集群
Cluster 模块，但是它还处在实验阶段，而且用它你还得重写你程序的逻辑。你最初的设计可能很少考虑到需要分布式处理的情况。
那么该怎么办？
写高性能的网络和分布式程序是当代程序员应有的基本素质。框架应该降低内容的切换——像node一样，允许我们创建高性能的服务器。但是还有比node.js更好的框架。
Go 是一个很好的侯选对象。它基于一个健壮的库，为网络编程而设计。而且编写服务器像node一样容易。
Goroutines 允许程序员不必担心回调式的书写方式，让程序员以更自然的，线性的思维去思考。而且Goroutines真的非常轻量级而且内容切换比操作系统的线程间切换更轻量，这种系统级的线程操作正是node.js想要避免的。
Go可以最大可能地发挥多核的优势。这是它的基因。我写了很多Go的代码，而且它的体验要比node要好很多。
不要把我的话当回事
我的node和JavaScript经验并不像C/C++或Python那样丰富。但是我的直觉告诉我node.js只是我们朝着向更好的网络编程迈进的一步。它已经解决很多问题了，但是应该还有更好的方法。
转载
㈤ 为什么nodejs 不适合cpu 密集型任务
我并没有尝试过用Node去CPU密集计算，所以不乱作评价。
猜测大概是2点：
1.Node还没有简单易用的多核计算接口。Cluster并不是那么好用。
2.Node的单核效率虽然比传统脚本语言高，但是和C，C++，Java比并没有优势。
㈥ 两个英特尔nodejslauncher进程占了我CPUP,有什么办法可以解决吗
你可以用进程管理软件把这两个进程关闭试试。
㈦ nodejs的IO性能体现在哪
IO的操作很耗时,所以有时候线程阻塞在某个IO操作上.
传统的方式,如果有新的请求过来则内会有建立新的线程来处容理请求.请求多的时候CPU会花很多时间来切换这些线程操作.虽然现在传统的方式看起来也像是异步的
Nodejs是单线程异步IO的.有IO操作的时候,把IO操作放到其他线程执行,其他跟IO结果有关的代码写在回调函数中等IO完成后再执行.当前线程继续执行后面的事情.在这个线程中,有个事件循环的队列,里面就放着不断要执行的任务,而且是一个完了到一个分别占着CPU来的执行的,不是并行每个占一会一直到运行完.CPU不用不花费在过多的线程上下文切换中.
但这样不好的就是一旦代码出错,线程挂了整个站点就挂了.或是如果有某个任务运算量很大,队列后面运行的东西要等很久.
可能说得还不是很清楚,可以这篇写的:
http://cnodejs.org/topic/518b679763e9f8a5424406e9
㈧ nodejs怎么监控内存和cpu使用情况
const os = require('os');
console.log('你的内存/M:'+os.totalmem()/1024/1024);
console.log('你的剩余内存/M:'+os.freemem()/1024/1024);
CPU使用率正内在研究容。
㈨ 两个英特尔nodejslauncher进程占了我CPU%50,有什么办法可以解决吗付我是电脑小白
两个英特尔这些个音符进程占了我这么50%，有什么办法可以解决？应该加大你的力度。让客户认可就可以办到了。
㈩ 为什么会出现nodejs这个产品
1. 处理高并发场景性能更高
在用 http://socket.io 之前，推送服务是用 ajax polling 做的。我们用 Tornado 和 Node.js 做过两个版本的推回送服务。在答当时的测试环境下，Node.js 的 CPU 时间是 Tornado 的三分之一，内存使用是 Tornado 的一半，代码行数只有 Tornado 的三分之一（Node.js 版是用 coffee 写的）。后来我们使用了 http://socket.io，CPU 开销进一步降低。
2. 函数式编程非常适合写异步回调链
用 Node.js 配合 CoffeeScript 写异步操作链非常便利，相比之下 Tornado 无论是写命名函数的回调，还是 yield 一个 Task 都没那么自然。