網(wǎng)站制作同步擴展，還是異步擴展？發(fā)布者：本站     時(shí)間：2019-11-12 13:11:49

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

這也就意味著(zhù)用戶(hù)的查詢(xún)會(huì )被阻塞，等待監控查詢(xún)完成，從而導致用戶(hù)查詢(xún)堆積起來(lái)。當用戶(hù)查詢(xún)變慢或者暫時(shí)停止等待超時(shí)時(shí)，它仍然會(huì )占用一個(gè)用戶(hù)數據庫的數據庫連接，而且應用服務(wù)器上執行的線(xiàn)程依然會(huì )消耗服務(wù)器上的內存。隨著(zhù)越來(lái)越多的用戶(hù)線(xiàn)程開(kāi)始停止，等待它們的監控調用超時(shí)，用戶(hù)數據的連接數可能會(huì )被耗盡，這樣其他非監控類(lèi)的查詢(xún)就不能再連接到用戶(hù)數據庫上。并且應用服務(wù)器上的線(xiàn)程需要把數據寫(xiě)回硬盤(pán)來(lái)釋放內存，這樣就會(huì )造成服務(wù)器上的內存交換。這種交換會(huì )使所有的處理變慢，還可能會(huì )使應用服務(wù)器的TCP堆棧達到上限，以致拒絕之后的連接。最后，新的用戶(hù)請求將得不到處理，用戶(hù)只能坐等瀏覽器或應用超時(shí)。從本質(zhì)上來(lái)說(shuō)，你的應用或平臺已經(jīng)停止工作了。如你所見(jiàn)，究竟是采用同步調用還是異步調用，這樣-一個(gè)小疏忽就會(huì )輕松地造成一系列糟糕的事件。 這個(gè)場(chǎng)景當中最精糕的一點(diǎn)在于，造成問(wèn)題的根本原因很隱蔽。由于我們是逐步探討了這一系列事件，所以要理解問(wèn)題所在相對比較容易，但如果系統的癥狀表現為系統載人Web頁(yè)面開(kāi)始變慢，在接下來(lái)的15分鐘內，這種情況越來(lái)越嚴重，直到最后整個(gè)系統停止了運行，要診斷這個(gè)問(wèn)題是非常困難的?；蛟S你有足夠的監控信息來(lái)幫助你診斷這些類(lèi)型的問(wèn)題，但是當你的站點(diǎn)停機了，而你又急于讓它恢復服務(wù)時(shí)，要搞清楚這一系列事件的真相是倍有壓力的。
 
盡管使用同步調用不當或過(guò)度會(huì )造成問(wèn)題，但方法調用還是常常采用同步方式實(shí)現。為什么會(huì )這樣?答案在于，同步調用比異步調用簡(jiǎn)單。你或許會(huì )補充說(shuō)，“等等，同步調用的確更簡(jiǎn)單一些，不過(guò)更經(jīng)常情況的是，我們的某些方法需要其他的方法先被調用才能成功完成。因此，我們不能在系統中使用大量的異步調用”。是的，的確如此。許多時(shí)候，你的確需要等待被調用的方法完成，并需要知道某些狀態(tài)才能讓線(xiàn)程繼續運行。我們不是要告訴你所有的同步調用都不好，事實(shí)上，許多同步調用都是必需的，它們會(huì )讓開(kāi)發(fā)人員的日子簡(jiǎn)單得多。但也有許多時(shí)候，即使存在上述的依賴(lài)性，也是可以使用異步調用，并且應該使用異步調用來(lái)代替同步調用的。如果主線(xiàn)程不太關(guān)心被調用的線(xiàn)程是否完成了，例如監控調用，那么只需用一個(gè)簡(jiǎn)單的異步調用即可。如果你需要被調用的線(xiàn)程提供一些信息， 又不想妨礙主線(xiàn)程的執行，那么可以采用回調來(lái)獲取這些信息。關(guān)于回調的詳細介紹已經(jīng)不在本書(shū)的范圍之內了?；卣{功能的一個(gè)示例是，操作系統中用于報告硬件狀況的中斷處理例程。
 
異步協(xié)調
 
原方法與被調用的方法之間的異步協(xié)調和通信需要一種機制，以便原方法確認被調用的方法何時(shí)執行完畢或者是否執行完畢了?；卣{是一種方法，它們會(huì )以參數的形式傳遞給其他方法，
 
以便去除代碼中不同層之間的耦合。在C和C+中，這是通過(guò)函數指針實(shí)現的；在Java中， 則是通過(guò)對象引用實(shí)現的。有許多設計模式都使用了回調，例如委托設計模式和觀(guān)察者設計模式。高層的進(jìn)程會(huì )充當低層的客戶(hù)，通過(guò)傳遞引用來(lái)調用低層的方法。一個(gè)回調方法被調用的示例可以是像文件系統改變這樣的同步事件。
 
在.NET框架中，異步通信的特征是使用了BeginBlah，其中Blah就是該方法的同步版本的名字。判斷一個(gè)異步調用是否完成了的方法有四種:
 
第一種是輪詢(xún)(IsCompleted屬性)；
 
第二種是回調方法Delegate；
 
第三種是方法AsyncWaitHandle，等待調用完成；第四種是方法EndBlah，也是等待調用完成。
 
不同的語(yǔ)言提供了不同的方案來(lái)解決異步通信和協(xié)調問(wèn)題。你需要了解你的語(yǔ)言和框架提供了什么解決方案，這樣才能在需要的時(shí)候實(shí)現它們。
 
在上段中我們說(shuō)過(guò)網(wǎng)站制作同步調用簡(jiǎn)單，因此使用同步調用的情況比使用異步調用的I彩得名。雖然這是事實(shí)，但它只是工程師忽視了同步調用的影響的部分原因。另部分原因是開(kāi)發(fā)人員通常只看到小部分。在一個(gè)組織中，只有非常少的幾個(gè)人能夠覽應用的全貌。你的架構師肯定應該他看到個(gè)局的應川，同樣地，管理團隊應該也可以看到。你必須依靠他們來(lái)解決難題，并解釋同步調川會(huì )造成哪些擴展問(wèn)題。