现在我们理解了同步调用和异步调用之间的区别。为什么要了解它们呢?答案在可扩展性当中。如果过度使用同步调用,或者使用不当,会给系统造成过度的负担,妨碍它扩展。让我们维续使用那个queryexec的例子,尝试执行一个用户查询。如果根据以下理由,即(1)监控很重要,(2)监控方法运行得很快,(3)最坏的情况不过是用户查询变慢了,我们实现了两个同步调用的监控方法。这些理由虽然意图是好的,但它们却是错误的。如前所述,虽然监控很重要,但是也没有返回给用户的查询结果重要。当被监控的数据库在运行时,监控方法也许运行得很快,但是当发生了硬件故障,或者被监控数据库不能访问时,又会怎样呢?这样来,监控查询就会被堆积起来,等待超时。
这也就意味着用户的查询会被阻塞,等待监控查询完成,从而导致用户查询堆积起来。当用户查询变慢或者暂时停止等待超时时,它仍然会占用一个用户数据库的数据库连接,而且应用服务器上执行的线程依然会消耗服务器上的内存。随着越来越多的用户线程开始停止,等待它们的监控调用超时,用户数据的连接数可能会被耗尽,这样其他非监控类的查询就不能再连接到用户数据库上。并且应用服务器上的线程需要把数据写回硬盘来释放内存,这样就会造成服务器上的内存交换。这种交换会使所有的处理变慢,还可能会使应用服务器的TCP堆栈达到上限,以致拒绝之后的连接。最后,新的用户请求将得不到处理,用户只能坐等浏览器或应用超时。从本质上来说,你的应用或平台已经停止工作了。如你所见,究竟是采用同步调用还是异步调用,这样-一个小疏忽就会轻松地造成一系列糟糕的事件。这个场景当中最精糕的一点在于,造成问题的根本原因很隐蔽。由于我们是逐步探讨了这一系列事件,所以要理解问题所在相对比较容易,但如果系统的症状表现为系统载人Web页面开始变慢,在接下来的15分钟内,这种情况越来越严重,直到最后整个系统停止了运行,要诊断这个问题是非常困难的。或许你有足够的监控信息来帮助你诊断这些类型的问题,但是当你的站点停机了,而你又急于让它恢复服务时,要搞清楚这一系列事件的真相是倍有压力的。
尽管使用同步调用不当或过度会造成问题,但方法调用还是常常采用同步方式实现。为什么会这样?答案在于,同步调用比异步调用简单。你或许会补充说,“等等,同步调用的确更简单一些,不过更经常情况的是,我们的某些方法需要其他的方法先被调用才能成功完成。因此,我们不能在系统中使用大量的异步调用”。是的,的确如此。许多时候,你的确需要等待被调用的方法完成,并需要知道某些状态才能让线程继续运行。我们不是要告诉你所有的同步调用都不好,事实上,许多同步调用都是必需的,它们会让开发人员的日子简单得多。但也有许多时候,即使存在上述的依赖性,也是可以使用异步调用,并且应该使用异步调用来代替同步调用的。如果主线程不太关心被调用的线程是否完成了,例如监控调用,那么只需用一个简单的异步调用即可。如果你需要被调用的线程提供一些信息,又不想妨碍主线程的执行,那么可以采用回调来获取这些信息。关于回调的详细介绍已经不在本书的范围之内了。回调功能的一个示例是,操作系统中用于报告硬件状况的中断处理例程。
异步协调
原方法与被调用的方法之间的异步协调和通信需要一种机制,以便原方法确认被调用的方法何时执行完毕或者是否执行完毕了。回调是一种方法,它们会以参数的形式传递给其他方法,
以便去除代码中不同层之间的耦合。在C和C+中,这是通过函数指针实现的;在Java中,则是通过对象引用实现的。有许多设计模式都使用了回调,例如委托设计模式和观察者设计模式。高层的进程会充当低层的客户,通过传递引用来调用低层的方法。一个回调方法被调用的示例可以是像文件系统改变这样的同步事件。
在.NET框架中,异步通信的特征是使用了BeginBlah,其中Blah就是该方法的同步版本的名字。判断一个异步调用是否完成了的方法有四种:
第一种是轮询(IsCompleted属性);
第二种是回调方法Delegate;
第三种是方法AsyncWaitHandle,等待调用完成;第四种是方法EndBlah,也是等待调用完成。
不同的语言提供了不同的方案来解决异步通信和协调问题。你需要了解你的语言和框架提供了什么解决方案,这样才能在需要的时候实现它们。
在上段中我们说过网站制作同步调用简单,因此使用同步调用的情况比使用异步调用的I彩得名。虽然这是事实,但它只是工程师忽视了同步调用的影响的部分原因。另部分原因是开发人员通常只看到小部分。在一个组织中,只有非常少的几个人能够览应用的全貌。你的架构师肯定应该他看到个局的应川,同样地,管理团队应该也可以看到。你必须依靠他们来解决难题,并解释同步调川会造成哪些扩展问题。
>>> 查看《网站制作同步扩展,还是异步扩展?》更多相关资讯 <<<
本文地址:http://nlpc.cn/news/html/3900.html