法克油，高併發下的API採用快取、分庫、壓縮、protocolbuff，全球定位服務。高併發下的網站除去上面的protocolbuff，加上cnd處理靜態檔案。有本事的就拿一點自己開發的實際東西出來分析，而不是拿網上一兩篇文章或者一兩個類的原始碼

根據我真實的經歷給出以下建議：

第一，最簡單的就是硬體支援，比如說增加cpu，用更好的顯示卡等。

第二，在資料庫方面做最佳化，最佳化配置檔案，注意適當的多分表，規範資料表的形式和正規化，適當增加中間關聯表，建立索引。

第三，避免進行頻繁的操作，以及大記憶體檔案的上傳下載。

第四，最佳化資料庫查詢語句，儘量避免多層巢狀查詢，避免進行大量的函式計算。

第五，使用快取機制，避免多次請求重複的內容。

以上是真是開發實踐出來的，僅供參考！

網站響應時間是指系統對請求作出響應的時間。通俗來講，就是我們把網址輸入進瀏覽器然後敲回車鍵開始一直到瀏覽器把網站的內容呈現給使用者的這段時間。網站響應時間越短越好，因為網站頁面開啟速度越快，就意味著我們的使用者可以更快地訪問站點或者我們的伺服器。一般網站的響應時間保持在100~1000ms即可，1s=1000ms，開啟速度越快對使用者體驗度越好。

響應時間並不能直接反映網站效能的高低，但是在一定程度上反應了網站系統的處理能力，也是給使用者最直觀的感受。如果網站的響應時間過長，比如10秒以上，使用者的流失率會大大增加，所以把響應時間控制在一定範圍內是提高使用者體驗度的第一要素。

解決方案

當用戶請求一個網站資料的時候，實際上是傳送了一個HTTP請求，在宏觀上可以分為兩個部分：

HTTP請求到達目標網站伺服器之前；

HTTP請求到達目標網站伺服器之後。

如果忽略其中硬體部分和部分細節，請求一個網站資料的大體過程如下圖所示（其中CDN和快取部分可以省略）：

我們要想縮短一個網站的響應時間，本質上是提高資料的返回速度，說的直白一點就是要把請求資料過程中的各個步驟提高速度，這樣整體下來響應時間就會縮短。

把資料放在離使用者越近的地方響應時間越快。

客戶端

客戶端是發起一個網站請求的源頭，其實這個源頭可以施加一定的策略來大大縮短某些資料的獲取時間。其中最為常用的就是快取，一些常用的、很少變動的資源快取在客戶端，不但能縮短獲取資源的時間，而且在很大程度上能減輕服務端的壓力。比如一些圖片、CSS、JS檔案，甚至一些介面的資料或者整個網頁內容都可以在客戶端做快取。另外HTTP請求的合併也可以減少對服務端的請求次數，在一定程度上可以縮短請求的響應時間。

DNS

一般網站的訪問方式都採用域名的方式（很少見IP方式），既然是域名就涉及到DNS解析速度的問題，如果DNS服務解析的速度比較慢，整體過程的響應時間也會加長，不過這個過程其實很少出現慢的問題（不是說沒有）。

網路

客戶端獲取到網站IP之後透過網絡卡把HTTP請求傳送出去，目標地址為相應的網站伺服器。在這個過程當中如果客戶端和伺服器端有一方頻寬比較小的話，就會加大響應時間。我司曾經就因為伺服器頻寬過小導致客戶端響應時間很長的情況，當時排查了很長時間才發現。

當然網路是不可靠的，這個過程的響應時間其實取決於很多因素，比如路由器的路由策略是否最優，整個過程透過的閘道器資料量等。所以有很多網站其實是多地區多機房部署的，目的就是為了讓使用者透過很短的網路路徑就能到達網站（其實這個過程運營商的選擇也有影響）。

網站

當一個請求到達網站伺服器，伺服器便開始處理請求，一般會有專門處理業務請求的一個業務層，有的體現為RPC協議的微服務，有的體現為簡單的一個程式碼分層。最終請求的資料會透過查詢資料庫來返回。

其實這個過程和車站購票流程一樣，每個視窗的處理能力是有限的，對應到伺服器處理能力。由於這個原因，所以誕生了負載均衡的策略，核心思想就是：分。一臺伺服器不夠，那就兩臺、三臺、四臺..... 直到併發的所有請求的響應時間都在可控範圍之內。

資料庫的情況類似，一個數據庫扛不住壓力，就加到N個數據庫分散壓力。一個表扛不住壓力，就把這個表拆分開，拆分成多個表，甚至拆分到多個不同伺服器資料庫，這就是我們常用的拆表策略。有的時候在同一個資料庫中進行表拆分，效能的提升並非最大化，因為一臺伺服器的磁碟IO是有上限的，就算拆成100個表，還是在同一個物理磁碟上，當然這樣可緩解鎖單表的情況。

現在有很多的場景採用NoSQL代替關係型資料庫來縮短響應時間，在正常情況下，由於關係型資料庫的本身因素在特定場景下的讀寫速度比NoSQL要慢很多，所以系統設計初期，可以考慮採用關係型資料庫和NoSQL混用的方案。

快取

當併發的請求到達一定程度，瓶頸大部分情況下發生在DB層面，甚至DB無論怎麼最佳化總有上限。為了避免頻繁查詢資料庫產生瓶頸，誕生了快取。在訪問資料庫之前加入了快取層，當然這裡的快取採用的方案在資料的響應時間上要比資料庫小很多，比如常用的Redis、Memcache，但是這些第三方的快取元件還是要走網路，比起程序內的快取還是要慢的多。

現在一般流行的設計在網站層和服務層都有快取策略，只不過快取的資料和策略有所不同，但是最終目的都是為了加快請求的響應。當然加了快取之後，資料的一致性需要仔細設計才可以，如果發生資料不一致的情況，程式設計師可能要背鍋了。

緩解資料庫壓力並不是引入快取的唯一因素。

CDN加速

一些小廠可能用不到CDN，但是CDN帶來的加速還是很客觀的。CDN依靠部署在各地的邊緣伺服器，透過中心平臺的負載均衡、內容分發、排程等功能模組，使使用者就近獲取所需內容，降低網路擁塞，提高使用者訪問響應速度和命中率。

1.客戶端或瀏覽器快取，能快取的就快取在客戶端本地

2.利用cdn，靜態資源可以放入cdn，包括需要下載的檔案

3.降低dns解析的代價，對於介面，可以直接將伺服器ip快取到客戶端，在客戶端層面做負載和故障轉移

4.伺服器端構建多級快取，應用內的，redis或memcache集中快取

5.資料庫利用好索引，利用樂觀鎖，減少鎖時間

6.對時序要求不高的可以使用訊息對列，進行削峰填谷，或者解耦多個業務系統

7.做好系統層面的最佳化

8.增大硬體配置