node处理理论

在 Java、PHP 或者.net 等服务器端语言中,会为每一个客户端连接创建一个新的线程。
而每个线程需要耗费大约 2MB 内存。也就是说,理论上,一个 8GB 内存的服务器可以同时
连接的最大用户数为 4000 个左右。要让 Web 应用程序支持更多的用户,就需要增加服务器
的数量,而 Web 应用程序的硬件成本当然就上升了。
Node.js 不为每个客户连接创建一个新的线程,而仅仅使用一个线程。当有用户连接了,
就触发一个内部事件,通过非阻塞 I/O、事件驱动机制,让 Node.js 程序宏观上也是并行的。
使用 Node.js,一个 8GB 内存的服务器,可以同时处理超过 4 万用户的连接。

上代码

let events= require('events');
//实例化对象5
let eventEmitter=new events.EventEmitter();
//监听事件
eventEmitter.on('on_day1',(e)=>{
    console.log(e);
    eventEmitter.emit('on_day2','我是on_day1,发送消息到on_day2')
});
eventEmitter.on('on_day2',(e)=>{
   console.log(e);
});
//发送消息
eventEmitter.emit('on_day1','发送消息给on_day1');

我的理解

其实通过上面咱们可以看到是通过on方法监听事件也叫监听广播,然后通过emit方法发送广播。我的理解其实是和js中的自定义事件其实是差不多的,当然也可以看成监听的时候传了个id和一个方法,触发的时候根据id来判断调用哪个方法。

疑问

以上不得不提出几个疑问,本身事件驱动是用来解决异步回调问题,我在想既然这样为什么不能直接用callback方式呢,那样起步更方便,其实也不对,可以想想一下我同时多个callback的时候这个时候用到事件驱动就很方便了。
第二个疑问就是事件驱动如果重复监听会发生什么事情?
假设:
1.报错
2.覆盖,第二次监听相同的事件会覆盖第一次监听的
3.依次都执行
提出假设了,那咱们稍微改造一下代码运行一下看看

let events= require('events');
//实例化对象5
let eventEmitter=new events.EventEmitter();
//监听事件
eventEmitter.on('on_day1',(e)=>{
    console.log('我是1');
    console.log(e);
});
eventEmitter.on('on_day1',(e)=>{
    console.log('我是2');
   console.log(e);
});
//发送消息
eventEmitter.emit('on_day1','发送消息给on_day1');

a.png
可以看到我同时监听了2个on_day1,然后我运行后是都执行了的,由此可以看出他的设计模式了,如果有相同的事件监听就按照监听顺序依次执行的,想这也对,万一咱们有多个回调需要在同时触发对吧。

总结

看完上面我觉得我可以使用一个数组来搞一个这玩意,但是这个东西不可能这么简单吧,要是这么简单咱们直接一个对象就解决的为啥为搞这么麻烦,去查一下资料看看。查完资料后看看下面这一段,可以说是说明的很清楚了,事件驱动优化了线程的操作。我就知道官方大大不会随便看玩笑的。

事件驱动概念

事件驱动编程主要思想是通过事件或状态的变化来进行应用程序的流程控制,一般通过事件监听完成,一旦事件被检测到,则调用相应的回调函数。事件驱动主要执行过程是当进来的一个新的请求的时候,请求将会被压入队列中,然后通过一个循环来检测队列中的事件状态变化,如果检测到有状态变化的事件,那么就执行该事件对应的处理代码,一般都是回调函数。

线程驱动是当收到一个请求的时候,将会为该请求开一个新的线程来处理请求。而线程主要是由线程池来管理的。当线程池中有空闲的线程,会从线程池中拿取线程来处理,如果线程池中没有空闲的线程,新来的请求将会进入队列排队,直到线程池中空闲线程

标签: nodejs笔记

添加新评论