使用Java编写的应用, 可以编程开启多线程处理高并发业务场景.
而JS处理高并发场景使用的是 : 队列机制, 事件机制
因为JS在网页中运行时单线程模式, 在服务端nodejs中运行是单进程模式, 都无法像JAVA那样开启多个线程或者协程来处理高并发任务.
但是这不意味着JS无法处理高并发任务, 单进程的程序在使用队列机制(就是待处理任务一个个排队)处理高并发场景也仍然是非常高效的, 而且避免了开启多个线程的内存消耗.但是其缺点也是很明显的 : 不适合处理单个任务计算非常复杂消耗时间的场景.
举个栗子 :
想象一下生活中排队的场景, 如果前面有一个人磨磨唧唧, 半天赖在窗口各种问问题, 后面的人都要排队等着, 很着急.
而如果开启多个窗口(多线程/进程), 那些难缠的人分到一个窗口, 速度快的人分到一个窗口, 效率就大大提升了.
一个接口需要控制判断某个资源的可用额度
express接口中使用mongodb处理高并发请求
1、document中添加资源数量属性used
2、使用mongoose中自带原子属性的操作进行查询更新used字段 Model.findOneAndUpdate()
2.1、注意第二点的match字段需要带上used的筛选条件
3、判断used是否超出可用数量，然后记录已超额的对象ID
4、使用定时操作从已超额的记录中归零对应的基础对象
同一套业务逻辑，实现一个webservice中间接口，中间涉及memcached和mogodb的一些操作。分别在Node.js和JAVA平台实现，java代码部署在Tomcat 7.0上，用Apache jmeter进行压力测试。
得到的测试结果很是出乎意料，Node.js的高并发优势为什么没有体现出来呢？？？
操作系统：CentOS 6.4（虚拟机）
内存：1.5G
CPU：单核
并发数 100
ramp-up period(in seconds)1
执行次数 10
以下是测试结果：
Lable #Sample Average Median 90%LineMin Max Error% Throughput KB/sec
Node.js HTTP请求 1000333 369 485 1 956 0.0 183.3180568285976 40.995932630614114
Tomcat HTTP请求 1000489 1882563 0.0 183.4862385321101 58.414564220183486
可以看到Node.js的平均执行时间为333毫秒，Tomcat的执行时间为48毫秒，Tomcat比Node.js快了近7倍！
补充1：即使是测试接口直接返回，不涉及后续的操作，Tomcat也比Node.js快了很多，求各位大神给个解释。
补充2：修改jmeter 的 ramp-up period的测试条件，比如这个值增大（如10秒），node.js的执行效率变高了，但这么想来也是违背了高并发的特性
抛砖引玉，一起探讨问题。如果你也感兴趣，不妨拿出点时间来写一段程序测试一下，我希望能得到不一样的结果。
