簡單說下SO_REUSEPORT的應(yīng)用場景， 為什么會用他？ 然而在講解SO_REUSEPORT之前，需要先說下我們常用的網(wǎng)絡(luò)模型。

在多核時代，一般主流的web服務(wù)器都使用 SO_REUSEADDR模式。 以下是比較典型的多進程/多線程服務(wù)器模型。

首先需要單線程/單進程listen一個端口上，然后由多個工作進程/線程去accept()在同一個服務(wù)器套接字上。

簡單說就是，一個linten, 多個accept

性能瓶頸：

第一個性能瓶頸，單線程listener，在處理高速率海量連接時，一樣會成為瓶頸

第二個性能瓶頸，多線程訪問server socket鎖競爭嚴重。

那么怎么解決？ 這里先別扯什么分布式調(diào)度,集群xxx的 , 就拿單機來說問題。在Linux kernel 3.9帶來了SO_REUSEPORT特性，她可以解決上面(單進程listen，多工作進程accept() )的問題.

多個listen.每個對應(yīng)一個accept. 由內(nèi)核去負載均衡將鏈接分不到具體的一個服務(wù)器socket上。

看圖說話，對比SO_REUSADDR的模型，我想你應(yīng)該看懂SO_REUSEPORT是個什么東西了。SO_REUSEPORT是支持多個進程或者線程綁定到同一端口，提高服務(wù)器程序的吞吐性能，具體來說解決了下面的幾個問題：

? ? ? ? ? 允許多個套接字 bind()/listen() 同一個TCP/UDP端口

? ? ? ? ? 每一個線程/進程擁有自己的服務(wù)器套接字

? ? ? ? ? 在服務(wù)器套接字上沒有了鎖的競爭，因為每個進程一個服務(wù)器套接字

? ? ? ? ? 內(nèi)核層面實現(xiàn)負載均衡

? ? ? ? ? 安全層面，監(jiān)聽同一個端口的套接字只能位于同一個用戶下

我這邊用python做了一個關(guān)于pythonSO_REUSEPORT服務(wù)端測試.? 測試之前，已經(jīng)要確定你的linux內(nèi)核版本是3.9, 在mac下進行so_reuseport測試，貌似不會提示端口被綁定，但是后啟動的進程會阻塞.

file:pythonreuseport.py

nohup ? pythonreuseport.py&

nohup ? pythonreuseport.py&

nohup ? pythonreuseport.py&

nohup ? pythonreuseport.py&

nohup ? pythonreuseport.py&

有些文章說，在python下多進程綁定同一個端口，也就是有人常說的prefork，他其實也是單個進程去listen監(jiān)聽端口，剩余的worker去accept獲取用戶請求而已.? 如果想用python實現(xiàn)真正的多進程綁定在多一個端口，那只能是用so_reuseport模式 。