併發系統架構優化細節

在本人短暫的IT開發生涯當中,面試過一些程序員（主要集中在2年-3年）。或多或小的都會問及在併發系統業務邏輯中的優化及實現，大部分的回答都是集羣，主從，NOSQL 使用。對於這些我的並不反對，可是我有話要說！這些都是一些大方向，還有狠多狠多細節是須要咱們IT技術人員瞭解的，這些細節是咱們在併發數據處理過程當中對咱們的系統將有很大的提高。（本人技術有限，若是不對的地方請你們提出，歡迎你們指正，內容來自在工做過程當中本身學習筆記）

優化重點TCP/IP協議的優化

1:對TCP/IP 協議的三次握手的優化，話很少說直接上圖

當客戶主機發起鏈接請求ACK，服務器主機接收到ACK而且返回ACK，併爲客戶主機分配資源。客戶端在收到ACK 報文後，也會發送確認ACK報文給服務器主機，這樣就創建起TCP/IP鏈接。

優化參數：tcp_max_syn_backlog: TCP 三次握手創建階段接受SYN，請求列隊的最大長度.默認1024，講其設置大一些可使出現NGINX繁忙來不及accept新鏈接的狀況下，LINUX 不至於STOP客戶的鏈接請求

2:TCP/IP 協議的四次揮手

第一次揮手：客戶端發送FIN+ACK包（序號爲seq=a，確認序號ack=b）給服務端，用來關閉客戶端到服務端的數據傳送，客戶端進入FIN_WAIT_1狀態。

第二次揮手：服務端收到FIN+ACK包後，發送ACK包給客戶端進行確認，服務端進入CLOSE_WAIT狀態。客戶端收到ACK包後進入FIN_WAIT_2狀態。到這裏，關閉一個單向通道。

第三次揮手：服務端發送FIN+ACK包給客戶端，服務端進入LAST_ACK狀態。

第四次揮手：客戶端收到FIN+ACK包後，發送ACK包給服務端進行確認，客戶端進入TIME_WAIT狀態，在等待30秒（可修改）後進入CLOSED狀態。服務端收到ACK包後進入CLOSED狀態，關閉另外一個單向通道。

優化參數：tcp_fin_timeout:當服務器主動關閉的時候，SOCKET 保持在FIN_WAIT_2狀態的最長時間.默認爲60秒,我通常設置爲10秒

解釋：在存在大量短連接的狀況下,LINUX 的TCP 通常會生成大量的time_wait的狀態的SOCKET

netstat -aut|grep -i time_wait|wc -l

tcp_tw_resuse:這個參數設置爲1，表示容許講time_wait狀態的SOCKET從新用於新的TCP 鏈接

tcp_max_tw_buckets:表示運行time_wait套接字數量的最大值，若是超過這個數字，會馬上清除並打印警告信息

tcp_keepalive_time:這個參數表示當keepalive啓用的時候,TCP 發送keepalive 消息的頻度,設置小一些能夠更快d清理無效的鏈接

file_max:表示進程，能夠同時打開的最大的句柄數

netdev_max_backlog:當服務器網卡處理的請求鏈接的速度大於LINUX 內核處理速度的時候，LINUX 就會把來不及處理的請求加入一個請求列隊（這接下來的博文中講會講述隊列的數據結構）

還有一些其餘的LINUX TCP/IP 優化參數，在工做中使用很少