服務器程序設計的一點體會

一個高效，穩定的服務器對於項目的成功至關重要，是不間斷地對用戶提供服務，創造美好
體驗的關鍵。而架構良好服務器程序需要良好的程序功底，需要處理好幾個方面的問題。

併發問題

現在服務器程序都是跑在多核，甚至多CPU主機上，如果充分利用強大的CPU是程序員面對的挑戰。
現在主要使用線程池技術，程序啓動時創建好特定數量的線程，使其能夠併發處理接收到的請求，
以此利用多核CPU，提高系統吞吐量。但同時也引入了併發性問題，給程序構造帶來複雜性，不得
不引入鎖，這也要求合理的利用鎖，注意鎖的方式和範圍，使鎖對性能的開銷降到最低。

另外，也通常將服務器功能分散到多個Server上，既多進程，如此每個Server可以單獨設計，簡化
了實現的難度，同時一部分服務器宕機時不至於影響其他服務。但是多Server的方式也有弊端：
系統調試困難，網絡環境並不是總是可靠，正確高效管理多個連接對程序員也是挑戰，部署困難等，
同時Server之間太多的Round Trip對性能的影響也不容小覷！

內存問題

對於使用託管代碼(Manage Code,像Java, C#)寫的服務器一般沒有這個方面的問題，而使用本地代碼
(Native Code,主要是C/C++)寫的服務器，內存問題對於很多程序員都是一場噩夢，沒有因內存問題
而喫大苦頭的程序員也不算真正強大。主要有幾種方法：使用內存池技術，避免過於頻繁地向系統
申請和釋放小塊的內存，造成大量的內存碎片；對於內存泄露，有專門的檢查工具，比如Win32的
umdh, 可以清晰顯示出某段時間內申請的內存是由那些調用棧申請的，這對於檢查Memory Leak
非常重要；對於內存的越界訪問，只有提高程序員的自身專業素質了。

IO問題

IO最容易程序服務器程序的性能瓶頸，特別是對於經驗不足的服務器程序員。完成良好的IO處理模塊
着實不易。對於網絡IO，Win32提供了完成端口(completion port), Linux提供了select, pool, epool
等機制，這些都可以用來處理大量的網絡接入，得到很高的數據吞吐量，特別是Win32提供的完成端口
機制，可謂是絕佳的處理網絡IO的機制，同時配之於網絡連接池機制，IO問題可迎刃而解；對於數據庫IO，
一般使用數據庫連接池機制，避免每次數據庫操作都要建立數據庫連接，以此提高性能，同時優化業務
邏輯和SQL語句；服務器程序一般不會大量地寫文件，因爲數據庫比文件更優越，如果日誌數據要寫入文件，
可以採用異步的方式，使日誌信息進入隊列，再由一個單獨的線程把日誌最終寫入文件，從而不影響
工作線程。

容錯處理

服務器程序遇到錯誤時要自我恢復，要以合理的方式報告給請求者，並且不能影響後續的請求。在多
Server的情況下，每一個Server都不能太依賴於其他Server，永遠不能相信其他Server總是能正常的
工作。發往其他Server的請求，需要建立重試和超時機制。

轉載：http://www.cnblogs.com/genuping/archive/2010/08/24/1807432.html