Posted on 2011-11-20 22:35
冷鋒 閱讀(3010)
評論(11) 編輯 收藏 引用 所屬分類:
linux
最近想寫個多線程模型的服務器，但是一直糾結要選哪種方式，參考了memcached，但是覺得不完美.
備選方案，當然這些都是NIO
1.一個IO線程，專門處理連接讀寫數據，一個邏輯線程，專門處理數據。
2.一個IO線程，一個線程池，可任意配置線程池的數量。
先考慮1，假設連接層用epoll的ET模式實現，當IO線程發生可讀事件時，必須把接收緩沖區的數據全部收完，一直read直到發生EAGAIN錯誤，否則就必須自己在上層維護一個可讀隊列。
方法a:每收到一個協議包，就轉發給邏輯處理.處理完再接著收取剩下的包。但是TCP是無邊界的，有可能收到0.5個或者2.5個包，這時你得為每個連接準備個buf,并且每收到個包都要跟邏輯線程同步加鎖一次,還有個很大的弊端就是，連接層已經跟邏輯協議相關了，這似乎不是很好。
方法b:IO線程把所有數據都收完再通知邏輯線程。當然這樣也無法避免收到半個協議包的情況，所以我是想維護一個recv到的數據隊列，IO線程把每次收到的包都丟到這個隊列。
a,b2種方法都面臨著send的麻煩，現在send也有以下方案.
方法a.每次需要write的時候就直接send發不完的就加到發送隊列中去。在發送前必須要先判斷一下隊列是不是空，如果不為空就必須先處理隊列，剩余數據待可讀事件發生時再處理， 于是腦子中又出現一大堆鎖了。有2個線程可能對socket進行寫操作。
方法b.每次需要send的時候都直接把數據丟到發送隊列去，等到可讀事件到來時再盡量把隊列都發送完。但是響應可能沒那么迅速了。
這兩種方法都必須為每個數據包增加一個標識TCP連接的字段，因為socket fd是可以重復使用的，比如用戶A連接分配的socket是100，邏輯線程正在為A處理數據，但是用戶A斷開連接了，同時立即有另外個用戶連接進來并且分配的socket是100，這時悲劇就發生了。
再考慮下線程池的2種情況.
a.主線程負責IO，包括處理連接，讀寫，把讀到的數據加入recv隊列，子線程把需要寫的加入send隊列.
這個方案有個很大的缺陷：無法保證先到的請求先返回，這是很致命的，只能通過客戶端來確保收到前一個請求的結果以后再發送下一個請求。
b.主線程只負責監聽連接，收到連接到來事件后，通知線程池去accept連接，因此每個連接的數據都會由同一個線程處理，也就保證了順序，但是這樣的話子線程就必須承擔起IO的任務了，這樣好像就有些分工不清了，這個是memcached中用的方案.
PS:用epoll的ET模式需要一直recv,這樣有可能是使得活躍的連接占用了全部帶寬，因此需要在上層對連接進行限速，因此也就需要維護可讀事件了。
糾結好幾天了，第一次寫多線程服務器，一直為選方案糾結啊，我本人傾向于線程池，畢竟可以利用多核的優勢啊。不知道大家實際上用的都是什么方案呢，非常想知道，請指教。
再PS：做了個小測試，nginx+memcached,下載一個700多K的文件，開100個線程，每個線程下載100次，全部命中跟全部不命中的情況幾乎沒有差別，這是為什么呢？難道linux系統本身就已經有cached了嗎？