Apache服务器的缺点： 阻塞 线程是可以独立运行的最小的CPU单位， 可以在一个进程里并发运行， 共享该进程下的内存地址空间。 我们可以看到同一个进程下的线程是会共享相同的文件和内存的（内存地址空间），所以大家可以想象，当不同的线程需要占用同一个变量时，根据先到先得的原则，先到的线程在运作时，后来的线程只能在旁边等待，也就是加入到了阻塞排队序列。所以这就是造成线程阻塞的原因。 因此，虽说进程可以支持多个线程，它们看似同时执行，但互相之间并不同步。一个进程中的多个线程共享相同的内存地址空间，这就意味着它们可以访问相同的变量和对象，而且它们从同一堆中分配对象。尽管这让线程之间共享信息变得更容易，因为程序设计者必须小心，确保它们不会妨碍同一进程里的其它线程。 了解了多线程并行的缺陷后，我们就可以更好地理解NodeJS的强大所在了。因为NodeJS是异步单线程的！ 服务端取数据实例： 代码执行到第一行的时候线程会阻塞，等待query返回结果，然后继续处理。由于数据库查询、磁盘读写、网络通信等原因（所谓的I/O）阻塞时间会非常大（相对于CPU始终频率）。对于高并发的访问，一方面线程长期阻塞等待，另一方面为了应付新情求而不断添加新线程，会浪费大量系统资源，同时线程的增加也会也会占用大量的CPU时间来处理内存上下文切换。看看node.js怎么处理。 看到没，就四个字：异步回调。query的第二个参数是一个回调函数，进程执行到db.query的时候不会等待结果返回，而是直接继续执行下面的语句，直到进入事件循环。当数据库执行结果返回的时候会将事件发送到事件队列，等到线程进入事件循环后才会调用之前的回调函数。更专业的说法是异步I/O。只要单线程就可以。 工作原理： NodeJS的工作原理其实就是事件循环。可以说每一条NodeJS的逻辑都是写在回调函数里面的，而回调函数都是有返回之后才异步执行的！ 你可以想象一下，NodeJS在寒风中面对着10万并发大军，OK，没问题，上来敌人一个扔到城里，上来一个又扔到城里。城里全民皆兵，可以很好地消化这些敌人。但如果上来一个类似于张飞赵云这样的人物，老Node心里一惨，和张飞大战300回合，把他打残了，再扔到城里。那后面的10万大军就得等这300回合。。。 所以这说明什么？说明NodeJS不是没有阻塞，而是阻塞不发生在后续回调的流程，而会发生在NodeJS本身对逻辑的计算和处理。我们已经知道，NodeJS的分发能力无比强大，可以循环事件进行异步回调。但如果在循环事件时遇到复杂的逻辑运算，那么单薄的单线程怎么支撑得起上百万的逻辑+并发呢？NodeJS它的所有I/O、网络通信等比较耗时的操作，都可以交给worker threads执行再回调，所以很快。但CPU的正常操作，它就只能自己抗了。? 说到这里，各位对NodeJS的特性估计也大概有个谱了。所以说适用的场景基本是呼之欲出了~！ 解决了什么问题： 1. 并发连接 单线程-->多线程 多线程问题： 服务端与客户端每建立一个连接，都要为这个连接分配一套配套的资源，主要体现为系统内存资源 以PHP为例，维护一个连接可能需要20M的内存。这就是为什么一般并发量一大，就需要多开服务器 我们同样是要发起请求，等待服务器端响应；但是与银行例子不同的是，这次我们点完餐后拿到了一个号码，拿到号码，我们往往会在位置上等待，而在我们后面的请求会继续得到处理，同样是拿了一个号码然后到一旁等待，接待员能一直进行处理。 等到饭菜做号了，会喊号码，我们拿到了自己的饭菜，进行后续的处理（吃饭）。这个喊号码的动作在NodeJS中叫做回调（Callback），能在事件（烧菜，I/O）处理完成后继续执行后面的逻辑（吃饭），这体现了NodeJS的显著特点，异步机制、事件驱动整个过程没有阻塞新用户的连接（点餐），也不需要维护已经点餐的用户与厨师的连接。 基于这样的机制，理论上陆续有用户请求连接，NodeJS都可以进行响应，因此NodeJS能支持比Java、PHP程序更高的并发量虽然维护事件队列也需要成本，再由于NodeJS是单线程，事件队列越长，得到响应的时间就越长，并发量上去还是会力不从心。 更改连接到服务器的方式，每个连接发射（emit）一个在NodeJS引擎进程中运行的事件（Event），放进事件队列当中，而不是为每个连接生成一个新的OS线程（并为其分配一些配套内存）。 2. I/O阻塞 Java、PHP也有办法实现并行请求（子线程），但NodeJS通过回调函数（Callback）和异步机制会做得很自然。 优缺点： 1. 高并发（最重要的优点） 2. 适合I/O密集型应用 缺点：1. 不适合CPU密集型应用；CPU密集型应用给Node带来的挑战主要是： 由于JavaScript单线程的原因，如果有长时间运行的计算（比如大循环）， 将会导致CPU时间片不能释放，使得后续I/O无法发起； 解决方案：分解大型运算任务为多个小任务，使得运算能够适时释放，不阻塞I/O调用的发起； 2. 只支持单核CPU，不能充分利用CPU 3. 可靠性低，一旦代码某个环节崩溃，整个系统都崩溃 原因：单进程，单线程 解决方案：（1）Nnigx反向代理，负载均衡，开多个进程，绑定多个端口； （2）开多个进程监听同一个端口，使用cluster模块； 4. 开源组件库质量参差不齐，更新快，向下不兼容 5. Debug不方便，错误没有stack trace 适合场景 1. RESTful API 这是NodeJS最理想的应用场景，可以处理数万条连接，本身没有太多的逻辑，只需要请求API，组织数据进行返回即可。它本质上只是从某个数据库中查找一些值并将它们组成一个响应。由于响应是少量文本，入站请求也是少量的文本，因此流量不高，一台机器甚至也可以处理最繁忙的公司的API需求。 2. 统一Web应用的UI层 目前MVC的架构，在某种意义上来说，Web开发有两个UI层，一个是在浏览器里面我们最终看到的，另一个在server端，负责生成和拼接页面。 不讨论这种架构是好是坏，但是有另外一种实践，面向服务的架构，更好的做前后端的依赖分离。如果所有的关键业务逻辑都封装成REST调用，就意味着在上层只需要考虑如何用这些REST接口构建具体的应用。那些后端程序员们根本不操心具体数据是如何从一个页面传递到另一个页面的，他们也不用管用户数据更新是通过Ajax异步获取的还是通过刷新页面。 3. 大量Ajax请求的应用 例如个性化应用，每个用户看到的页面都不一样，缓存失效，需要在页面加载的时候发起Ajax请求，NodeJS能响应大量的并发请求。　　总而言之，NodeJS适合运用在高并发、I/O密集、少量业务逻辑的场景。 既然NodeJS处理并发的能力强，但处理计算和逻辑的能力反而很弱，因此，如果我们把复杂的逻辑运算都搬到前端（客户端）完成，而NodeJS只需要提供异步I/O，这样就可以实现对高并发的高性能处理。情况就很多啦，比如：RESTFUL API、实时聊天、客户端逻辑强大的单页APP，具体的例子比如说：本地化的在线音乐应用，本地化的在线搜索应用，本地化的在线APP等。 顺便提一下Apache，打压了这么多，给颗甜枣。Apache由于其多线程高并发共享内存地址空间的特性，那就意味着如果服务器足够强大，处理器足够高核，Apache的运作将会非常良好，所以适用于（并发）异步处理相对较少，后台计算量大，后台业务逻辑复杂的应用程序