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