常見併發伺服器模型

1）短連線（如果是長連線則需要在read與write之間增加乙個迴圈，那樣的話外層迴圈無法退出，接收不到其它連線請求，即只能服務乙個客戶端）；

2）單執行緒，無法充分利用多核cpu；

3）不適合執行時間較長的服務（encode->compute->decode執行時間過長會影響其他客戶端連線的響應速度）。

1）長連線；

2）one connection per process（主程序每次fork 後要關閉connfd，子程序要關閉listenfd），one connection per thread（執行緒間共享檔案描述符，因此不用也不能關閉socket，否則會影響主線程的監聽和子執行緒與客戶端之間的通訊）；

3）適合執行時間較長的服務。

1）預先建立程序/執行緒；

2）可以提高連線的響應速度；

3）多個子程序阻塞於accept時，若有乙個客戶端連線請求到來，則多個子程序都會被喚醒，但只有乙個程序的accept能成功返回，這種現象稱為「驚群」。

2）併發處理多個請求，實際上是在乙個執行緒中完成的，無法充分利用多核cpu的效能；

3）不適合執行時間較長的服務（為了讓客戶端感覺是在「併發」處理而不是「迴圈」處理，每個請求必須在相對較短時間內執行完成）。

每個連線都在乙個工作執行緒中完成，能充分利用多核cpu的效能。

第五、第六種方法的改進。

muduo庫的/example/suduku/中有乙個reactor + threadpool的例子，因為數獨求解是計算密集型任務。

在實踐中，為了使reactor能快速返回事件迴圈中去響應請求，經常將讀到的資料put到乙個環形記憶體佇列（一般記憶體or共享記憶體），而threadpool的執行緒則從這個環形記憶體佇列中讀取資料進行計算。

1）reactors in threads（one loop per thread） memcached就是這種模型，乙個主線程，多個工作執行緒，主線程reactor負責接收客戶端連線，每個執行緒有各自的reactor負責執行任務佇列中的任務。

2）reactors in processes；

3）round robin（輪詢）；

4）一般來說乙個subreactor適用於乙個千兆網口。

muduo庫主推的一種併發伺服器模型！！！

多個subreactor共享乙個執行緒池。

1）理論上proactor比reactor效率要高一些；

2）非同步i/o能夠讓i/o操作與計算重疊，充分利用dma特性；

3）linux非同步i/o：

glibc aio (aio_*)，有bug；

kernel native aio (io_*)，也不完美。目前僅支援o_direct方式來對磁碟讀寫，跳過系統快取。要自己實現快取，難度不小。

4）boost asio實現的proactor，實際上不是真正意義上的非同步i/o，底層是用epoll來實現的，模擬非同步i/o。