業務起來了，併發上來了，高峯時期也達到1.6wrps了，長連接數量達到了5w，爲了生存，才研究如何提高併發。
1. net.core.netdev_max_backlog
net.core.netdev_max_backlog參數表示網卡接受數據包的隊列最大長度，在阿里雲服務器上，默認值是1000，可以適當調整。
2. net.core.somaxconn
net.core.somaxconn參數決定了端口監聽隊列的最大長度，存放的是已經處於ESTABLISHED而沒有被用戶程序（nginx）接管的TCP連接，默認是128，對於高併發的，或者瞬發大量連接，必須調高該值，否則會直接丟棄連接。
3. net.ipv4.tcp_max_orphans
net.ipv4.tcp_max_orphans參數決定孤立連接的最大數量。阿里雲服務器默認16384，個人感覺沒啥鳥用。
4. net.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_max_syn_backlog參數決定已經收到syn包，但是還沒有來得及確認的連接隊列，這是傳輸層的隊列，在高併發的情況下，必須調整該值，提高承載能力。
5. net.ipv4.tcp_synack_retries
net.ipv4.tcp_synack_retries參數決定了發送SYN+ACK確認包重試的次數（數量），默認是5，可以調整爲2或者3，使其快速失敗。
6. net.ipv4.tcp_syn_retries
net.ipv4.tcp_syn_retries參數，作爲客戶端，主動建立連接時發送syn包重試的次數，默認6次，可以調整爲2次或者三次，快速失敗。
7. net.ipv4.tcp_abort_on_overflow
net.ipv4.tcp_abort_on_overflow參數，當TCP連接已經建立，並塞到程序監聽backlog隊列時，如果檢測到backlog隊列已經滿員後，TCP連接狀態會回退到SYN+ACK狀態，假裝TCP三次握手第三次客戶單的ACK包沒收到，讓客戶端重傳ACK，以便快速進入ESTABLISHED狀態。如果設置了net.ipv4.tcp_abort_on_overflow參數，那麼在檢測到監聽backlog 隊列已滿時，直接發 RST 包給客戶端終止此連接，此時客戶端程序會收到104 Connection reset by peer錯誤。這個參數很暴力，慎用。參考這裏
8. net.ipv4.tcp_syncookies
net.ipv4.tcp_syncookies參數，在TCP三次握手過程中，當服務端收到最初的SYN請求時，會檢查應用程序的syn_backlog隊列是否已滿。若已滿，通常行爲是丟棄此SYN包。若未滿，會再檢查應用程序的監聽backlog隊列是否已滿。若已滿並且系統根據歷史記錄判斷該應用程序不會較快消耗連接時，則丟棄此 SYN 包。如果啓用tcp_syncookies則在檢查到syn_backlog隊列已滿時，不丟棄該SYN包，而改用syncookie技術進行三次握手。參考這裏
9. net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range參數決定了作爲客戶端，發起連接時可用的端口範圍，對於nginx來說，後拋請求是就是客戶端行爲，所以高併發場景下也有一定的必要。
10. net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_reuse參數可以重用TIME_WAIT狀態的連接，僅需要1秒就可以重用。此參數針對TIME_WAIT，與是否爲客戶端無關。
11. net.core.rmem_max
12. net.core.wmem_max
13. net.ipv4.tcp_rmem
14. net.ipv4.tcp_wmem
以上4個參數決定了socket buffer大小，默認是幾百KB，可以調大