從IIS按期重啓服務開始

 

• 原由

　　手上的項目是.NET 作的，運行在Windows服務器的IIS上。消息推送的時候有利用WebSocket像客戶端推送消息，因爲IIS定時會從新服務回收資源，會致使WebScoket服務重啓，期間一些消息會收到影響。暫時的解決方案可使用定時計劃在非高峯期回收資源（能夠參考：https://www.cnblogs.com/Fishwood/p/3602041.html）

　　前端忽然問我：爲何IIS會回收資源？我查了下資料說是爲了保持系統的穩定性，但仍是不甚理解。

• 緣由

　　晚上看nginx服務器的Web請求處理機制的時候忽然獲得瞭解答，摘抄以下：

　　Web服務器和客戶端是一對多的關係，Web服務器必須有能力同時爲多個客戶端提供服務。通常來講，完成並行處理請求工做有三種方式可供選擇：多進程方式、多線程方式和異步方式。

　　1.多進程方式

　　　多進程方式是指，服務器每當接收到一個客戶端時，就由服務器主進程生成一個子進程出來和該客戶端創建鏈接進行交互，直到鏈接斷開，該子進程就結束了。

　　　多進程方式的優勢在於，設計和實現相對簡單，各個子進程之間相互獨立，處理客戶端請求的過程彼此不受干擾，而且當一個子進程出現問題時，不容易將影響擴散到其餘進程中，保證了提供服務大的穩定性。當子進程退出的時候，其佔用的資源就會被操做系統回收，也不會留下垃圾。而其缺點也是很明顯的。操做系統中生成一個子進程須要進行內存複製等操做，在資源和時間上會產生必定的額額外開銷，所以若是Web服務器接受大量併發請求，就會對系統資源形成壓力，致使系統性能降低。

　　　初期的Apache服務器就是採用的這種方式對外提供服務的。爲了應用大量的併發請求，Apache服務器採用了「預生成進程」的機制對多進程方式僅從了改進。「預生成進程」的工做方式是將生成子進程的時機提早，在請求還沒到達前就預先生成哈，當請求到達時，主進程就分配一個子進程和該客戶端進行交互，交互完成後，該進程也不結束，而是被主進程管理起來等待下一個客戶端請求的到來。改進的多進程方式在必定成都上緩解了大量併發請求情形下Web服務器對系統資源形成的壓力。可是因爲Apache服務器在最初的架構上採用了多進程方式，所以這不能從根本上解決問題。　

　　2.多線程方式

　　　多線程方式是指，服務器每當接收到一個客戶端時，就由服務器主進程派生出一個線程出來和該客戶端進行交互。

　　　因爲操做系統產生一個線程的開銷遠小於產生一個進程的開銷，因此多線程方式在很大程度上減輕了Web服務器對系統資源的要求。該方式使用線程進行任務調度，開發方面能夠遵循必定的標準，這相對來講比較規範和有利於協做。但在線程管理方面，該方式喲必定的不足。多個線程位於同一個進程內，能夠訪問一樣的內存空間，彼此之間相互影響；同時在開發的過程當中不可避免的須要開發者本身對內存進行管理，其增長了出錯的風險。服務器系統須要長時間連續不停地運轉，錯誤的逐漸積累可能最終對整個服務器產生重大影響。

　　　IIS服務器使用了多線程方式對外提供服務，它的穩定性相對來講仍是不錯的，可是一般仍是會按期檢查和重啓服務器，以預防不可預料的故障發生。

　　3.異步方式

　　　首先從同步、異步以及阻塞、非阻塞的概念開始：

　　　網絡通訊中的同步機制和異步機制是描述通訊模式的概念。同步機制，是指發送方發送請求後，須要等待接收到接收方返回的響應後，才接着發送下一個請求；異步機制，和同步機制相反，發送方發出一個請求後，不等待接收方響應這個請求，就繼續發送下一個請求。在同步機制中，全部的請求都在服務器端獲得同步，發送方和接收方對請求的處理步調是一直的；在異步機制中，全部來自發送方的請求造成一個隊列，接收方處理完成後通知發送方/

　　　阻塞和非阻塞用了描述進程處理調用的方式，在網絡通訊中，主要指網絡套接字Socket的阻塞和非阻塞方式，而Socket的實質也是IO操做。Socket的阻塞調用方式爲，在結果返回以前，以前線程從運行狀態被掛起，一直等到調用結果返回以後，才進入就緒狀態，獲取CPU後繼續急性；Socket的非阻塞調用方式中，若是調用結果不能立刻返回執行下一個調用。

　　　事實上同步和阻塞，異步和非阻塞這兩對概念存在必定的區別，不能混淆。兩隊概念的組合，就會產生四個新的概念：同步阻塞，異步阻塞，同步非阻塞，異步非阻塞。

　　　1）同步阻塞方式，發送方向接收方發送請求後，一直等待響應；接收方處理請求時進行的IO操做若是不能立刻獲得結果，就一直等到返回結束後，才響應發送方，期間不能進行其餘工做。這種方式實現簡單，可是效率不高。

　　　2）同步非阻塞方式，發送方向向接收方發送請求後，不用等待響應；接收方處理請求時進行的IO操做若是不能立刻獲得結果，就當即返回，去作其餘事情，但因爲沒有獲得請求處理結果，不響應發送方，發送方一直等待。一直到IO操做完成後，接收方得到結果響應發送方後，接受方纔進行下一請求過程。在實際中不實用這種方式。

　　　3）異步阻塞方式，發送方向接收方發起請求後，不用等待響應，能夠接着進行其餘工做；接收方處理請求時進行的IO操做，若是不能立刻獲得結果，就一直等到返回結果後，才響應發送方。這種方式在世實際中也不實用。

　　　4）異步非阻塞方式，發送方向接收方發送請求後，不用等待響應，能夠繼續其餘工做，接收方處理請求時進行的IO操做若是不能立刻獲得結果，也不等待，而是立刻返回去作其餘事情。當IO操做完成之後，將完成狀態和結果通知接收方，接收方再響應發送方。在四種方式中，這種方式是發送方和接收方通行效率最高的一種。

　　　而Nginx採用的是機制是結合多進程機制和異步機制對外提供服務，採用異步非阻塞方式，能夠同時處理大量併發請求。