伺服器技術縱橫談

     好久沒有在csdn上發過什麼文了，實在沒有什麼好寫的是一方面，另外，我的大部分時間都在閱讀中渡過，等到我意識到我應該寫點什麼的時候，已經到了現在.現在,我確實想整理思路寫點什麼出來，這不是一個強加給自己的任務，確實是有點想要噴薄出的想法而已。如果只是本能的向大腦裡面塞什麼東西進去，其實只是使用了他一部分的功能而已難道不是嗎 ？大腦我覺得應該更像一個麵包機，我們放進去麵粉，蘇打，它產生髮泡以後的結果給我們；存在因為我們思考，有哲人是這麼說的。所以，不管什麼時候，不要讓自己的思考能力閑置，長期這樣，確實會讓人回到智力萎縮的狀態。

     我回想最近所做的事，所吸收的想法都是關於：“伺服器”，不錯，是這個東西。隨著進入ipv5的年代，它會成為一個司空見慣的東西。其實，不用ipv5，目前你在網頁上做的一切事情，背後都有伺服器的支援。但ip5的年代，會讓每一個家庭都至少擁有一個伺服器 ，隨著智能家居概念的普及，所有家電的“cpu”化，它們將擁有常規家電之外的能力--計算，以及資料共用。這樣一個未來預示著，家用資料共用平台（伺服器）存在的必然性，也許未來有一天，你可以直接通過互連網給自己做一頓晚餐，或者跟自己的貓咪餵食等。

這應該是全球進入智能電器化社會的一個必然階段。。。未來，你或許可以跟你的瓦斯灶說：我明天需要買早上8點的飛機票。

    其實，對於伺服器這個領域，我知之甚少。所以這篇文，將隨著我知識的深化而逐漸擴充。看這篇文的性急觀眾請不要罵我。。。我其實與你們一樣，都是處於學習，或者研究階段。。。。希望我能早日完成這個文吧。另外，我可能囉囉嗦嗦說一些跟主題無關的話，都是一些我個人的不成熟見解，如果錯誤遺漏，請大家教我。

     我們從組建伺服器最根本的東西說起吧：線程，不錯，就是這個東西。目前所有偉大的伺服器，都是基於多線程的，但有些系統平台可能沒有多線程概念，比如linux,它是基於多進程的，但基於posix標準線程庫的應用，我想，使用“多線程”來描述一切伺服器，應該是勉強可以吧。長期以來，多線程 的控制，是一項比較難以掌握的技術。線程的同步，非同步，並發，等問題，屬於考慮不周，使用不當就會犯嚴重錯誤，特別對伺服器的“負載平衡”而言，好的線程應用模式是成功的一半。臨界這個概念，是設計線程式控制制結構必要先考慮的問題，儘管現在已經進入oo設計的年代，彷彿一切都是可以化為獨立的對象，不用考慮其內容相關的相關性。但對線程而言，還是一個需要“啟，承，轉，和”的完美狀態機器。其實，作為電腦的這個機器，本身就是一個純粹的“符號”系統，或者說，電腦，已經它上面啟動並執行作業系統，就是一個龐大的符號系統。所以，對於線程的操作，還是要首先對需要完成的任務進行流程化的考慮，然後可以進一步進行基於任何方式的抽象。我所說“臨界”這個概念與常規不同，是基於時間，而不僅僅是資源。指的是線程之間需要同時運作的時刻，這個時刻，它們可能同時去訪問同樣一個結構，或者變數，因此帶來互相影響的相關性。我常見的一種線程式控制制退出方式：一個線程通過改變一個符號的值，去控制另外一個線程退出。當一個線程開始去改變符號時，這個符號其實也時常在另外一個線程的訪問之中，在這個時刻，兩個線程就處於“臨界訪問”狀態。處於“臨界”的兩個線程，必須要進行狀態機器的同步，如果一個線程退出，析構了一些資源，而另外一個線程繼續訪問，顯然會讓程式痛快的crash掉。因此，這個控制線程，需要有目的的等待另外一個線程退出，而繼續進行下一步操作。而這一切都需要時間，比之“簡單一層”的
ui程式，伺服器如果要退出自己，是相當的艱難。我個人認為，半分鐘內完全退出伺服器應該是可以接受的。如果在10秒鐘內，不是過於簡單，就是設計的太棒了。對於等待這方面，window下常規的api 提供了一組：waitfor*系列的函數，能夠等待的物件控點包括：1.thread 2.mutex  3.semphore  4.event 等。這些api介面的設計方法論，基本上來自常規的作業系統設計理論，可以放心大膽的使用。但使用方法需要特別注意，這裡需要特別提出2個問題1.線程互鎖 2.線程自鎖  對於線程互鎖，指的是線程因為互相等待，而進入deadlock狀態，線程自鎖，指的是線程進入遞迴式等待，造成自身deadlock。對於線程互鎖問題，其實，沒有什麼好的解決方案，這一切取決你在代碼之初的規劃，對於此，我只能給出一個建議：盡量讓線程自己處理自己，減少控制的互動，比較好的方法是用通知或者訊息的方式進行通訊，而不是直接的操控控制代碼或者資料結構。對於自鎖定，幸好，作業系統已經給出了一種解決方案：可以遞迴鎖定的核心對象這樣的對象有二個，一個是critical_section（臨界區），一個是mutex。使用critical_section來做遞迴鎖，是一種通用的方式，已知的應用程式套件括boost庫的實現。所以，沒有必要大家不必要去做這件工作，使用boost庫即可。對於mutex它是window的特有核心對象，與critical_section的不同之處在於它可以在進程之間被開啟使用，而critical_section,只可在一個進程的線程之間使用。對於linux系統，critical_section仍然支援遞迴，我想這也許是boost庫選擇其作為可遞迴鎖的理由之二吧。

        建立一個線程很簡單，有n多的介面可用，window平台提供了 CreateThread,這個函數。調用很簡單，你可以在其參數中顯式指明線程堆棧大小，入口函數地址，預設的函數傳入參數，以及幾個可以完全設定為NULL的參數。另外，posix線程庫，以及常規的c執行階段程式庫也提供了幾個對應的調用封裝，比如_beginThread, _beginThreadEx ,pthread_create 等。在window平台上，很多人認為這幾個函數其實與win32 CreateThread沒什麼不同。確實，這幾個函數最終還是調用了CreateThread,在系統平台上，產生線程，其實是一個作業系統核心功能的調度過程。但基於c運行時得_begin*系列函數，還是有些略微的不同。最大的不同在於TLS（
Thread Local Storage）機制的使用。TLS這個東西其實很好理解，如果把每個線程當作頑皮孩子的話，TLS就相當於給他穿上了帶口袋的衣服，然後他就可以帶著口袋到處玩耍。而這個口袋，成為這個線程專屬的一個使用空間，他可以放各種各樣的東西進去--當然，這個口袋數量可以不僅僅是一個的。TLS 的應用執行個體，開發中大家可能直接使用的比較少，但其實，很多庫，或者工業架構的實現廣泛使用了TLS，比如大名鼎鼎的MFC,c執行階段程式庫等。但也由此帶來了一些負面效應，比如 MFC表單類缺乏多執行緒安全性，調用一些c運行函數可能造成記憶體流失等。對於MFC的非多執行緒安全性，這個問題知道的人很多，真正明白的人比較少，經常看到很多半懂不懂的程式員因此詬病MFC，不將之幹掉毫不罷休。其實你在一個線程裡面操作它所建立的表單對象是沒有問題的，在另外的線程裡面，直接使用原生控制代碼發訊息怎可以避過不安全問題。至於詳細為什麼，只要瞭解下MFC
基於TLS 做了什麼事，馬上就一目瞭然。所以一般的原則是，你如果只使用win32完成工作，使用createthread即可，如果你需要線上程中調度執行階段程式庫，就去使用_begin*系列的函數吧。但基於為未知的安全因素的考慮，還是建議大家多使用_begin*系列函數。還有一個重要的使用它的理由就是工業層級MFC中的AfxBeginThread,CWndThread等，都是使用_begin*系列的函數封裝，微軟尚且如此，你還有什麼理由不拋棄CreateThread ?
      談論完 thread,接下來我們要說一說網路通訊的基本技術api:socket,這一塊相關的介紹資料很多,我就不多論述,只是簡單說下工作模式相關的東西: 阻塞,非阻塞模式.這2種基本模式是網路api的2種工作方式,它決定了上層邏輯的實現方式.所謂阻塞,指的是線程進行網路傳輸應答動作時,一定要等待一個應答周期完成,其實就是你send一個資料出去後,要馬上進行wait動作,直到伺服器發來響應的資料.非阻塞呢,一個線程發資料到伺服器後,不進行等待,甚至也不去接受資料,而另外有一個線程專門進行資料收發工作,它收到相應資料後,就去處理資料.這是一種將send動作,和receive動作放在2個線程進行處理的行為.我個人認為這種非阻塞行為方式較好.它可以在介面線程裡面工作,但又不會因此而掛起介面,另外,基於執行緒模式的考慮,這種方式邏輯架構更為清晰.它的主要缺點在於具體的網路互動動作可能出現"交疊"或者"亂序"的行為,也就是如果存在幾個線形關係的命令,可能會產生命令發送次序混亂的問題,這個問題需要在用戶端,或者伺服器進行一定邏輯上的限定.阻塞方式中,當前線程會被掛起,直到伺服器響應為止.如果在ui線程中做這件事情,ui就會經常性的不能響應使用者操作,整個程式處於假死狀態.

 

未完,待續...