一套網(wǎng)絡(luò)框架的杯具

之前設(shè)計了一套網(wǎng)絡(luò)框架，持續(xù)改進了很多年，使用在很多項目上，綜合效率還行，也很穩(wěn)定，一直以來對這套東西信心滿滿，總以為啥問題都好解決，但最近就有個需求讓我選擇還是改了下這個框架。

之前的框架是這樣的，可以開一組N個io線程，可以開一組N個同步線程（默認1個），可以開一組N個異步線程（默認1個），可以開一組N個timer線程（默認1個），可以開一組N個異步線程（默認cpu個），每組可獨立受控，每組可支持自定義消息，可支持timer，一組N個如果N大于1則無法直接給這組里面的特定線程發(fā)消息，只能給一組發(fā)消息，這個組里面會選擇某個合適的線程處理這個消息，這也是iocp高效和典型的用法了，但這也正是問題的結(jié)癥所在。

Linux下的多線程服務(wù)器更常見的做法跟這個不大相似，一般都是將某些socket分配到某些線程epoll，分好之后就是固定的，不再變化，跟Iocp將socket綁定到一組線程的做法不同，由于某個socket直接綁定到了某個線程，所以有些問題就變得簡單了，如同一個連接的在同一個線程內(nèi)消息進行了同步，要跟io線程綁定私有化數(shù)據(jù)也簡單了，而且每個線程可獨立受控，所以很容易實現(xiàn)一組io各自掛tls（線程局部存儲）數(shù)據(jù)，而我現(xiàn)在做的這套框架就是這方面不好控了，其實也很難說這兩種意義上的框架到底誰更優(yōu)，如用在web型應(yīng)用上這種socket被一組io線程管理的模式很方便效率也高，但我現(xiàn)在的需求需要某個socket使用線程相關(guān)數(shù)據(jù)，以避免數(shù)據(jù)之間的鎖，我用內(nèi)存換時間，由于在原來的框架上增邏輯難以實現(xiàn)可直接控制io線程的框架的，所以花了一個晚上重新改寫了一套框架，在原來iocpframe的基礎(chǔ)上派生了一組帶2名稱的類，除替換類名之外只修改了幾十行代碼就做好了，總的來說花的時間還是比較少的。修改后io線程一組，但獨立受控，外部可對這組線程中的某一個直接發(fā)消息，基本滿足了需求，現(xiàn)在要給每個io線程綁定私有數(shù)據(jù)并觸發(fā)特定消息比之前簡單多了，而且絕對無鎖。