網際網路分布式架構設計，提高系統併發能力的方式主要有兩種：垂直擴充套件（scale up）與水平擴充套件（scale out）。在網際網路業務發展非常迅猛的早期，如果預算不是問題，強烈建議使用「增強單機硬體效能」的 方式提公升系統併發能力，因為這個階段，公司的戰略往往是發展業務搶時間，而「增強單機硬體性 能」往往是最快的方法。 不管是提公升單機硬體效能，還是提公升單機架構效能，都有乙個致命的不足：單機效能總是有極限的。所以網際網路分布式架構設計高併發終極解決方案還是水平擴充套件。 水平擴充套件：只要增加伺服器數量，就能線性擴充系統效能。垂直擴充套件：提公升單機處理能力。垂直擴充套件的方式又有兩種。
增強單機硬體效能
提公升單機架構效能
水平擴充套件：增加伺服器，集群。
三種實現方式前兩種只能對客戶端（即單一ip限流）
}其中「limit_conn one 10"既可以放在server層對整個server有效，也可以放在location中只對單獨的location中只對單獨的location有效
該配置表明：客戶端的併發連線數只能是10個
}其中」limit_req zone=req_one burst=120"既可以放在server層對整個server有效，也可以放在location中只對單獨的location有效
rate=1r/s的意思是每個位址每秒只能請求一次，也就是說令牌桶burst=120一共有120塊令牌，並且每秒鐘只新增1塊令牌，120塊令牌發完後，多出來的請求就會返回503
3.ngx_http_upstream_module（推薦）
#提供了我們需要的後端限流功能的upstream ***
#版本安全#ip安全
#白名單配置：
location /
#黑名單配置：
location /
#檔案安全
location /logs
location ^/logs~*\.
(log|txt)$
#連線安全
https開啟
#調整nginx的主配置檔案，增加併發量worker_processes 2;
#調整到與cpu數量一致
events
#調整核心引數
[root@proxy ~]
# ulimit -a #檢視所有的屬性值
[root@proxy ~]
# ulimit -hn 100000 #臨時設定硬限制
[root@proxy ~]
# ulimit -sn 100000 #設定軟限制
[root@proxy ~]
# vim /etc/security/limits.conf..
.* soft nofile 100000
* hard nofile 100000
#使用者/組 軟/硬限制 需要限制的專案 限制的值
#驗證[root@proxy ~]
# ab -n 2000 -c 2000 #自己訪問自己,測試一下配置效果
nginx長連線短連線，可以增強伺服器的容災能力場景：http1.1之後，http協議支援持久連線，也就是長連線，優點在於在乙個tcp連線上可以傳送多個http請求和響應，
減少了建立和關閉連線的消耗和延遲。如果我們使用了nginx去作為反向**或者負載均衡，從客戶端過來的長連線請求就會被轉換
成短連線傳送給伺服器端，為了支援長連線，我們需要在nginx伺服器上做一些配置
要求：使用nginx時，想要做到長連線，我們必須做到以下兩點： 1：從client到nginx是長連線
2：從nginx到server是長連線
對於客戶端而言，nginx其實扮演著server的角色，反之，之於server，nginx就是乙個client
配置：我們要想做到client與nginx之間保持長連線，需要： 1：client傳送過來的請求攜帶"keep-alive"header。
2：nginx設定支援keep-alive
gzip壓縮作用：將響應報⽂傳送⾄客戶端之前可以啟⽤壓縮功能，這能夠有效地節 約頻寬，並提⾼響應⾄客戶端的速度,壓縮會消耗nginx的cpu效能。gzip壓縮可以配置http,server和location模組下
#配置nginx的監控選項（配置檔案路徑：nginx.conf）#新增如下**：
#設定nginx狀態訪問位址
location /nginxstatus
#外掛程式安裝：
#配置完成重啟nginx
#配置完成後在瀏覽器中輸入
/192.168.1.1/nginxstatus檢視
#引數說明：
#活躍的連線數量 active connections
#總共處理了n個連線 , 成功建立n次握手, 總共處理了n個請求 server accepts handled requests
#每個連線有三種狀態waiting、reading、writing
reading —讀取客戶端的header資訊數.這個操作只是讀取頭部資訊，讀取完後馬上進入writing狀態，因此時間很短
writing — 響應資料到客戶端的header資訊數.這個操作不僅讀取頭部，還要等待服務響應，因此時間比較長。
waiting — 開啟keep-alive後等候下一次請求指令的駐留連線.
正常情況下waiting數量是比較多的，並不能說明效能差。反而如果reading+writing數量比較多說明服務併發有問題。
#檢視nginx併發程序數：
ps-ef|grep nginx | wc -l
#檢視web伺服器tcp連線狀態：
netstat -n | awk '/^tcp/ end '
#解析：
closed #無連線是活動的或正在進行
listen #伺服器在等待進入呼叫
syn_recv #乙個連線請求已經到達，等待確認
syn_sent #應用已經開始，開啟乙個連線
established #正常資料傳輸狀態/當前併發連線數
fin_wait1 #應用說它已經完成
fin_wait2 #另一邊已同意釋放
itmed_wait #等待所有分組死掉
closing #兩邊同時嘗試關閉
time_wait #另一邊已初始化乙個釋放
last_ack #等待所有分組死掉
Linux 高併發下效能優化
ulimit用於shell啟動程序所占用的資源,暫時地，適用於通過 ulimit 命令登入 shell 會話期間 vi etc profile 儲存後執行 source etc profile 使其生效 ulimit 顯示 或設定 使用者可以使用的資源的限制 limit 這限制分為軟限制 當前限制 ...
高併發下投標過程進行優化
業務流程 對於乙個融資標的invest表，標的id,標的總融資金額 total money 已投資金額 invested money 滿標時間 finish invest time 標的狀態 status 假如有多個使用者user同時投標，投資金額為m,為保證資料一致性，以下步聚在同乙個事務當中 1...
高併發下RPC通訊優化路徑
選擇合適的通訊協議 基於 tcp 協議實現的 socket 通訊是有連線的，而傳輸資料是要通過三次握手來實現資料 傳輸的可靠性，且傳輸資料是沒有邊界的，採用的是位元組流模式。基於 udp 協議實現的 socket 通訊，客戶端不需要建立連線，只需要建立乙個套接字傳送 資料報給服務端，這樣就不能保證資...