首先說明,對於網路引擎的編寫,我自己現在還是屬於入門級階段,所以下面的觀點只是我自己的心得體會.
首先來談下我對網路引擎的認識過程.相信很多人剛開始的時候都跟我一樣,看了socket就覺得自己已經大概知道如何進行網路程式設計了,以為網路很簡單,就是簡單的收與發.但是在這個階段,你真的去下手,就會發現,你的想象完全只是乙個想象.想編寫乙個伺服器,僅知道socket和基本的一些知識是遠遠不夠的.
伺服器本身而言,是乙個狀態自動機,接受到請求,並返回處理結果.是的,說起來就是這麼簡單.但是乙個好的伺服器,需要考慮的東西要多的多,比如,如何去支援同時能夠處理的連線數量,如何加快處理速度,如何使其結構更加合理,以加快上層的開發等.並且,對於目前而言,伺服器系統經常可能是乙個伺服器組而不是單一的伺服器.所以,不可能只是去簡單的編寫乙個狀態機.
乙個網路引擎,首先要考慮的就應該是他的資料收發機制,或者說是要採用什麼樣的io模式.我目前而言感覺,比較好的io模式對於windows而言就是iocp(完成埠),而對於linux而言就是epoll了.iocp用起來感覺比epoll麻煩一些,iocp需要用到重疊io,epoll用起來更像select.這兩種方式的效能差不多,只是平台不同.
使用了高效率的io模式,同一臺伺服器就可以管理較多的連線了,但是,對資料報如何處理對於伺服器的效能也是十分重要的.當資料到達接收快取後,我們需要把它拆成乙個乙個有意義的資料報傳給程式上層.但是上層如何處理這些資料報,卻直接決定著伺服器的效能.例如,可以先將資料報快取在乙個佇列中,然後在對這個佇列中,然後用乙個單執行緒的處理模組去順序的處理這些資料報.不過這樣的話,可想而之,使用者數量對伺服器的效能的影響非常大,一般到8000左右的連線就到極限了,但是很顯然,這樣的處理不容易出錯,而且控制相對容易.當然,也可以讓處理模組是乙個多執行緒的,這樣顯然可以增多最大連線數,因為可以不被會掛起一定時間的邏輯浪費時間.
但是並不是說執行緒越多越好,執行緒越多,就會造成越多的上下文切換,這樣事實上會影響效能.在理想狀態下,應該保證機器有幾個cpu就建立幾個執行緒,這樣可以進行並行的處理,達到最高的效率,但是如果上層邏輯有阻塞的情況的話,則應適當的多開一些執行緒,以便在某些執行緒掛起的時候有別的任務補上,以充分了利用cpu的能力.
接下來乙個非常重要的問題就是記憶體管理.
為何要使用記憶體管理,我是這樣理解的.使用系統自帶的預設記憶體管理的話,可能回造成過多的換頁進而影響了效率,浪費了系統的時間(也就是說用new,delete,calloc,malloc,free這些)
不過到底用何種記憶體管理對效能的提公升比較高,這個我還沒有仔細研究過~~
最後一點就是伺服器的容錯性問題.作為乙個伺服器,容錯性肯定是非常關鍵的,不然,一出錯就down,那肯定是不行了.如何提供良好的容錯性呢.我感覺首選就是借助於指令碼語言.我們可以用指令碼語言封裝低層引擎,例如用python,lua這類語言.這樣即可以提高開發效率,有可能提公升伺服器的容錯性,一舉兩得.不過使用指令碼也是有一些缺點的,肯定會占用一些額外的資源.速度問題等.不過畢竟是得有所取捨的.
當然,也可以直接用c++或者c直接寫上層邏輯,但是這樣的話,嚴密的考慮就是非常必要的了.而且開發時間和耗費都被指令碼開發需要的時間長.
就說這麼多了,最近準備自己做乙個,哈哈
簡談自己對redux的理解
redux描述 通過 react redux 中的 provider 將store總分支注入根元件，其原理就是所謂的context原始碼如下 export function createprovider storekey store subkey constructor props,context ...
談測試 5 測試人員對自己的定位
按照我的理解，測試人員對自己的定位，對測試工作的認知高度，直接決定了自己能到達的水平。第乙個層次 找bug 軟體開發人員交付給測試之後，測試人員開始針對該軟體版本進行測試驗證，尋找其中的問題。在這個階段，能夠源源不斷找出問題，摸索出自己的測試思路，能夠借助自動化工具進行規模和壓力測試，都可以獲得一定...
如何從0構造自己的系統？
1 抄，當然是個非常快捷的方式，但由於抄很多時候只能看到其表面，很難形成乙個體系，而構造自己的系統，是一定要成體系的 2 借鑑，跟抄差不多，是集合眾之長，這種方式如果產品設計者沒有非常深刻的理解，往往到最後就是什麼都不像 3 產品需求 ui設計 架構設計 程式設計.這是目前很多公司，特別是創業公司最...