網(wǎng)站制作同步擴(kuò)展，還是異步擴(kuò)展？

發(fā)布：2018-10-01 17:51:06 瀏覽：4460

現(xiàn)在我們理解了同步調(diào)用和異步調(diào)用之間的區(qū)別。為什么要了解它們呢?答案在可擴(kuò)展性當(dāng)中。如果過度使用同步調(diào)用，或者使用不當(dāng)，會給系統(tǒng)造成過度的負(fù)擔(dān)，妨礙它擴(kuò)展。讓我們維續(xù)使用那個queryexec的例子，嘗試執(zhí)行一個用戶查詢。如果根據(jù)以下理由，即(1)監(jiān)控很重要，(2)監(jiān)控方法運行得很快，(3)最壞的情況不過是用戶查詢變慢了，我們實現(xiàn)了兩個同步調(diào)用的監(jiān)控方法。這些理由雖然意圖是好的，但它們卻是錯誤的。如前所述，雖然監(jiān)控很重要，但是也沒有返回給用戶的查詢結(jié)果重要。當(dāng)被監(jiān)控的數(shù)據(jù)庫在運行時，監(jiān)控方法也許運行得很快，但是當(dāng)發(fā)生了硬件故障，或者被監(jiān)控數(shù)據(jù)庫不能訪問時，又會怎樣呢?這樣來，監(jiān)控查詢就會被堆積起來，等待超時。

這也就意味著用戶的查詢會被阻塞，等待監(jiān)控查詢完成，從而導(dǎo)致用戶查詢堆積起來。當(dāng)用戶查詢變慢或者暫時停止等待超時時，它仍然會占用一個用戶數(shù)據(jù)庫的數(shù)據(jù)庫連接，而且應(yīng)用服務(wù)器上執(zhí)行的線程依然會消耗服務(wù)器上的內(nèi)存。隨著越來越多的用戶線程開始停止，等待它們的監(jiān)控調(diào)用超時，用戶數(shù)據(jù)的連接數(shù)可能會被耗盡，這樣其他非監(jiān)控類的查詢就不能再連接到用戶數(shù)據(jù)庫上。并且應(yīng)用服務(wù)器上的線程需要把數(shù)據(jù)寫回硬盤來釋放內(nèi)存，這樣就會造成服務(wù)器上的內(nèi)存交換。這種交換會使所有的處理變慢，還可能會使應(yīng)用服務(wù)器的TCP堆棧達(dá)到上限，以致拒絕之后的連接。最后，新的用戶請求將得不到處理，用戶只能坐等瀏覽器或應(yīng)用超時。從本質(zhì)上來說，你的應(yīng)用或平臺已經(jīng)停止工作了。如你所見，究竟是采用同步調(diào)用還是異步調(diào)用，這樣-一個小疏忽就會輕松地造成一系列糟糕的事件。這個場景當(dāng)中最精糕的一點在于，造成問題的根本原因很隱蔽。由于我們是逐步探討了這一系列事件，所以要理解問題所在相對比較容易，但如果系統(tǒng)的癥狀表現(xiàn)為系統(tǒng)載人Web頁面開始變慢，在接下來的15分鐘內(nèi)，這種情況越來越嚴(yán)重，直到最后整個系統(tǒng)停止了運行，要診斷這個問題是非常困難的。或許你有足夠的監(jiān)控信息來幫助你診斷這些類型的問題，但是當(dāng)你的站點停機了，而你又急于讓它恢復(fù)服務(wù)時，要搞清楚這一系列事件的真相是倍有壓力的。

盡管使用同步調(diào)用不當(dāng)或過度會造成問題，但方法調(diào)用還是常常采用同步方式實現(xiàn)。為什么會這樣?答案在于，同步調(diào)用比異步調(diào)用簡單。你或許會補充說，“等等，同步調(diào)用的確更簡單一些，不過更經(jīng)常情況的是，我們的某些方法需要其他的方法先被調(diào)用才能成功完成。因此，我們不能在系統(tǒng)中使用大量的異步調(diào)用”。是的，的確如此。許多時候，你的確需要等待被調(diào)用的方法完成，并需要知道某些狀態(tài)才能讓線程繼續(xù)運行。我們不是要告訴你所有的同步調(diào)用都不好，事實上，許多同步調(diào)用都是必需的，它們會讓開發(fā)人員的日子簡單得多。但也有許多時候，即使存在上述的依賴性，也是可以使用異步調(diào)用，并且應(yīng)該使用異步調(diào)用來代替同步調(diào)用的。如果主線程不太關(guān)心被調(diào)用的線程是否完成了，例如監(jiān)控調(diào)用，那么只需用一個簡單的異步調(diào)用即可。如果你需要被調(diào)用的線程提供一些信息，又不想妨礙主線程的執(zhí)行，那么可以采用回調(diào)來獲取這些信息。關(guān)于回調(diào)的詳細(xì)介紹已經(jīng)不在本書的范圍之內(nèi)了?；卣{(diào)功能的一個示例是，操作系統(tǒng)中用于報告硬件狀況的中斷處理例程。

異步協(xié)調(diào)

原方法與被調(diào)用的方法之間的異步協(xié)調(diào)和通信需要一種機制，以便原方法確認(rèn)被調(diào)用的方法何時執(zhí)行完畢或者是否執(zhí)行完畢了?；卣{(diào)是一種方法，它們會以參數(shù)的形式傳遞給其他方法，

以便去除代碼中不同層之間的耦合。在C和C+中，這是通過函數(shù)指針實現(xiàn)的；在Java中，則是通過對象引用實現(xiàn)的。有許多設(shè)計模式都使用了回調(diào)，例如委托設(shè)計模式和觀察者設(shè)計模式。高層的進(jìn)程會充當(dāng)?shù)蛯拥目蛻?，通過傳遞引用來調(diào)用低層的方法。一個回調(diào)方法被調(diào)用的示例可以是像文件系統(tǒng)改變這樣的同步事件。

在.NET框架中，異步通信的特征是使用了BeginBlah，其中Blah就是該方法的同步版本的名字。判斷一個異步調(diào)用是否完成了的方法有四種:

第一種是輪詢(IsCompleted屬性)；

第二種是回調(diào)方法Delegate；

第三種是方法AsyncWaitHandle，等待調(diào)用完成；第四種是方法EndBlah，也是等待調(diào)用完成。

不同的語言提供了不同的方案來解決異步通信和協(xié)調(diào)問題。你需要了解你的語言和框架提供了什么解決方案，這樣才能在需要的時候?qū)崿F(xiàn)它們。

在上段中我們說過網(wǎng)站制作同步調(diào)用簡單，因此使用同步調(diào)用的情況比使用異步調(diào)用的I彩得名。雖然這是事實，但它只是工程師忽視了同步調(diào)用的影響的部分原因。另部分原因是開發(fā)人員通常只看到小部分。在一個組織中，只有非常少的幾個人能夠覽應(yīng)用的全貌。你的架構(gòu)師肯定應(yīng)該他看到個局的應(yīng)川，同樣地，管理團(tuán)隊?wèi)?yīng)該也可以看到。你必須依靠他們來解決難題，并解釋同步調(diào)川會造成哪些擴(kuò)展問題。