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