网站制作同步扩展，还是异步扩展

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

网站制作同步扩展，还是异步扩展

相关行业资讯

相关视频推荐