需要执行的异步函数:有2种方式,普通带回调的函数,在函数之后最后必须调用回调函数传入err和result。如果err为空,则表明当前异步操作成功,将继续下一个异步执行,如果传入err不为空,则整个异步队列任务的状态即为false终止执行下面的任务。
另一种方式是es7的 async 函数,将return的值(即resolve的值)定义为此次的返回值,如果异常则自动将异常信息(即reject值)用于error信息
所有异步方法执行之后的回调函数,参数为err,results
如果方法中没有传入callback参数,则返回promise
方式一:传入callback
方式二:不传入callback,使用promise的then、catch方式
异步队列函数,同一时间并发执行的的函数的数量,仍属于异步,只不过做了每次执行的数量限制
异步串行执行,必须等到前一个异步任务状态sucess,才执行下一个任务。
MQ全称为MessageQueue,
消息队列(MQ)是一种应用程
序对应用程序的通信方法。应用程序通过读写出入队列的消息(针对应用程序的数据)来通信,而无需专用连接来链接它们>。消
息传递指的是程序之间通过在消息中发送数据进行通信,而不是通过直接调用彼此来通信,直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过
队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求。其中较为成熟的MQ产品有IBM
WEBSPHERE
MQ。
以上介绍仍旧来自百度百科.
消息队列产品对比
目前比较流行的MQ有2种,ActiveMQ
以及
RabbitMQ
,
RabbitMQ性能号称能够达到每秒10000,而REDIS官方的压力测试值在7-8万之间,而且是去掉了网络IO操作,真实情况我估计在每秒2-3
万的并发操作,但这个数目对于一般的应用应该足够了.
Redis如何支持消息队列?
在新版本的redis
v2.6以上以及以上版本开始支持
subscribe
以及
publish
操作,
subscribe订阅一个频道,publish可以像频道广播消息.
这个机制最老的应用应该是算是聊天室了.
Sub/Pub
模式固然很好用,但是同样有一个问题,就是如果有多个人订阅了同一频道,而这个频道的数据只能被一个接收方处理,不能够重复处理,这时该怎么办?
解决方法有2种,
1.
publish
将数据写入到一个list
or
sorted
list
队列,写完成后开始给终端广播消息,告诉大家,有新的数据等待处理,这个时候,谁能pop到数据,就是谁处理,这个操作是原子性的,也就是说不会被重复处理.
2.
使用阻塞模式,
redis提供了blpop
brpop这种操作,也就是一直阻塞一个队列,直到有数据来.
这种模式保证了数据的原子性,而且使应用程序可以支持分布式多台机器部署.
Sub/Pub模式
(sub.js):
var
redis
=
require("redis")
var
client
=
redis.createClient(6379,
‘127.0.0.1‘,
{connect_timeout:
1})
//订阅一个频道
var
sub
=
function(c)
{
var
c
=
c
||
‘roban:test:channel‘
client.subscribe(c,function(e){
console.log(‘starting
subscribe
channel:‘+c)
})
}
//订阅一个频道
sub()
//处理错误,如果出现错误,或者服务器断开了链接,等待恢复时,继续订阅这个频道
client.on(‘error‘,
function(error)
{
console.log(error)
sub()
})
//订阅处理函数
client.on(‘message‘,function(err,response){
console.log(response)
})
打开redis命令行,输入以下命令:
publish
roban:test:channel
hello
发布这条信息后,sub端会输出以下信息:
Robans-Pro:node
robanlee$
node
demo.js
starting
subscribe
channel:roban:test:channel
hello
说起JS的异步执行机制,如果百度一下,你首先会发现阮一峰的写过一篇关于异步机制的文章( http://www.ruanyifeng.com/blog/2014/10/event-loop.html ),等你津津有味又一头雾水的看完,然后继续看百度的其他结果,然后会发现,阮一峰的这篇被另一个大牛朴灵给批判了
( http://www.360doc.com/content/14/1011/13/15077656_416048738.shtml )。
由此可见,关于异步执行机制到底是怎么回事,因为涉及到浏览器底层机制,所以不容易彻底了解清楚,就算是大牛阮一峰,也只是通过英文文献来了解,而且一知半解。我的这篇文章只是试图尽可能简单的描述一下JS的异步执行机制,坦白说,我现在并不能完全弄懂这个机制,所以也不能完全解释清这个机制,所以,如果我写的越严谨,就越容易出错,我只能简单但是较模糊的描述一下:
JS的运行环境是一个很复杂的环境,它里面有非常多的复杂的名词事物,用简单又不严谨的说法来说,运行环境里至少有下面这些事物:
有一个国外的web app,专门用来讲解异步事件的门道 Loupe ,这个更接近真实情况。为什么我不讲解这个?因为更复杂了,我们并不打算研究浏览器的底层,不是么?
然后说一下任务队列里的任务。所有任务可以分成两种,一种是同步任务(synchronous),另一种是异步任务(asynchronous)。同步任务指的是,靠主线程自己就可以执行完成的任务;异步任务指的是,主线程执行开始之后,需要靠主线程之外的线程才能完成的任务。由主线程决定是否要动用其他线程。以下内容,不再提栈,只说主线程。
现在说重点:
异步任务的执行机制是:
当主线程遇到一个异步任务,比如一个ajax请求,当主线程执行到 xhr.send() 的时候,这个send命令是立即执行的, 并不会像一些人想象的,拖到所有同步任务的最后面。 然后主线程向http线程发送指令,要求http线程向服务器发送请求。这里强调一下http线程,显然它不是主线程的一部分,因为它可以并发,如果你有100个ajax请求,每个都需要1秒钟,是不是http线程要花100秒呢?并不是,它会并发100个请求,总共耗时大约1.01秒就完成了。
主线程向以http线程为代表的几个线程发送指令之后,主线程就暂时不再管这个ajax任务了,而是去看任务队列里的下一个任务。
http线程发送了请求之后接收反馈,收到之后,形成一个新的事件(可以叫做“我收到啦!”事件),然后插入到回调函数队列中,因为回调函数队列的优先级很低,所以会排到总队列的最后面,其结果就是:主线程把同步任务都完成了,才开始执行异步事件的 回调 。 注意,并不是异步任务在全体同步任务结束之后才开始,而是异步任务的回调通常在全体同步任务结束之后才开始!异步任务跟异步任务的回调是两回事!是两个任务!一个鲜明的例子就是 setTimeout(fn, 1000) ,计时是从主线程遇到 setTimeout() 任务,然后分配给计时器线程,计时器线程开始干活的时候就开始计时了!只不过要1秒之后 fn 才执行! setTimeout() 和 fn 是两个任务! setTimeout() 是立即执行, fn 才是1秒之后执行。但是 setTimeout() 的执行,人眼是感受不到的,因为并没有什么地方有一个秒表告诉你 setTimeout() 开始执行了;而fn的执行,人眼能感受到,所以人们会错误的以为fn才是异步任务,其实fn并不是, fn 是个回调任务,往往 fn 是同步任务,比如 fn 可能是 console.log(123) ,这怎么会是异步任务。
所以,异步机制是浏览器的两个或以上常驻线程共同完成的,异步请求是JS主线程和其他某个线程共同完成的,JS的执行线程发起异步请求(这时浏览器会开一条新的HTTP请求线程来执行请求,这时JS自己的任务已完成,继续执行线程队列中剩下的其他任务),然后在未来的某一时刻"任务队列"线程监视到之前的发起的HTTP请求已完成, "任务队列"就会把完成事件插入到JS执行队列的尾部等待JS处理 。
最后专门说说定时触发(settimeout和setinterval)。
定时触发是由浏览器的定时器线程执行的定时计数, 然后在定时时间到达之后,定时器线程把定时处理函数的执行请求插入到JS回调队列的尾端。
这个1到底是100毫秒之后弹出,还是1000毫秒(或更多时间)后弹出呢?又或是1100毫秒之后弹出?
答案是,1000毫秒多一点点之后弹出。
原因:浏览器会先执行setTimeout,也就是开始计时,然后开始执行sometask,执行了1000毫秒,然后去回调队列里看回调任务,alert(1)早就恭候了,因为定时100毫秒之后alert(1)就可以执行了。所以,等1000毫秒的任务完成,1就会立即弹出,所以答案是1000毫秒多一点点之后弹出。
所以用这两个函数的时候,实际的执行时间是大于或等于指定时间的,不保证能准确定时的。
最后强调一下setInterval。比如我希望每100毫秒打印一个1。然后,又有极端情况,就是sometask耗时1000毫秒。你以为sometask结束之后会打出10个1么?并不会,只会打出1个1,因为setInterval第一次读秒结束之后,回调队列出现了一个alert(1),根据之前的理论,并不会执行。又过了100毫秒之后,计时器线程会去观察回调队列是不是已经有了alert(1),如果有,就不再往回调队列里加alert(1),目的就是为了避免回调叠加执行。
总之,你需要记住,异步任务就是主线程在任务队列里看到了这个任务,看了一眼之后就然后安排别的线程帮忙,然后主线程就忙别的去了,别的线程帮忙完事之后,再在队列末尾放一个新任务叫“帮忙完毕”,到此异步任务本身就完事。主任务看到“帮忙完毕”任务之后,就去执行回调,回调执行完,这个异步任务连同回调就全都完事。然后,如果并没有回调。。。没有就没有呗。