建站
咨詢
售后
建站咨詢
新聞中心
本文轉載自微信公眾號「跨界架構師」，作者Zachary。轉載本文請聯(lián)系跨界架構師公眾號。
大家好，我是Z哥。
最近正好在編寫一套新的面試題，其中有一道是與高并發(fā)相關的。出題的目的是想了解一下候選人面對大流量場景下的優(yōu)化思路。在出這道題的過程中，我自己也梳理了一下自己對這個問題的思路。
然后之所以想在這里分享出來，是因為這是我這些年經過實戰(zhàn)所得出的躺著“血汗”的經驗，所以我覺得這可能對很多讀者都有所幫助。
不過丑話說在前面，我的思路并不是完美的，畢竟條條大路通羅馬，解決「高并發(fā)」的思路也有很多種。所以歡迎大家在評論區(qū)分享你的看法。
/01 高并發(fā)的定義/
首先，高并發(fā)的定義是什么?
高并發(fā)意味著大流量，需要運用技術手段抵抗流量的沖擊。這些手段的效果好比你可以操縱流量，讓流量可以乖乖地按照你的期望、更平穩(wěn)地被系統(tǒng)所處理，帶給用戶更好的體驗。對，就和大禹治水那樣。
我想，幾乎每個程序員心里都有過一個疑問，達到多少QPS或者TPS才算是高并發(fā)?
其實，這個問題無法單純地通過一個統(tǒng)一標準的數字來判斷。因為不同的業(yè)務所對應的復雜度不同，不能一概而論。
我自己用的評判標準是，當一個運行正常的系統(tǒng)在沒有刻意優(yōu)化性能的情況下，出現(xiàn)了性能問題，說明他開始進入到高并發(fā)的范圍了。
對，就是這么簡單粗暴，沒有具體的數字。
但是在高并發(fā)是常態(tài)的場景中，一般都會有一個監(jiān)控系統(tǒng)，會持續(xù)觀察至少以下這幾個指標是否正常。
- TPS。每秒事務處理量，這里的事務是指一個客戶機向服務器發(fā)送請求然后服務器做出反應的過程。(以客戶端為視角)
- QPS。每秒查詢率，可以通過并發(fā)量 / 平均響應時間計算得出。(以服務端為視角，一個TPS可能會對應多個QPS)
- 并發(fā)用戶數。系統(tǒng)可以同時承載的正常使用系統(tǒng)功能的用戶的數量。
- 響應時間。很多時候也叫RT，是指系統(tǒng)對請求作出響應的時間。
- 帶寬。如果是一個數據傳輸量比較大的業(yè)務，還需要考慮帶寬問題，比如視頻、音頻類應用程序。
如果你連這些指標的含義都不是很清楚，那就多讀幾遍，先搞清楚它們，否則你的高并發(fā)是閉著眼睛在做。
/02 應對高并發(fā)的思路/
很多缺乏經驗的小伙伴，遇到高并發(fā)問題，不管三七二十一，上來就懟緩存。
用緩存是沒錯的，但是緩存也不是靈丹妙藥，在哪里都適合。畢竟，緩存是「有狀態(tài)」的，在軟件開發(fā)中，處理「有狀態(tài)」的東西總是比「無狀態(tài)」的麻煩得多，因為存在數據一致性的問題需要考慮。
我建議你按照以下三個步驟來考慮這個問題。
01 梳理請求流轉鏈路
梳理好了請求流轉的鏈路，就好比你手里有了一張“作戰(zhàn)地圖”，你可以更加直觀、準確地進行排兵布陣。
畢竟軟件開發(fā)本身就是一個工程的問題，我們不能憑感覺，拍腦袋去做事。解決高并發(fā)問題自然也不例外。
02 確定目標
有一句話說得好，“沒有最好，只有更好”。如果不先確定目標，這件事將會變成對性能無止境地追求。而過度的高性能，不但不會產生額外的收益，反而是對投入成本的浪費，畢竟資源是有代價的，而且是有限的。
我建議你將具體的數值目標細化到每一個 API 上。比如我一般會先確定整個業(yè)務線的 TPS 要達到多少。例如，下單的 TPS 要達到100。
接下來，我會根據前面梳理好的鏈路圖，得到其中會涉及到哪些 Service ，哪些 API ，有哪些 API 還會被不同的 Service 多次調用的。
然后會根據鏈路中 API 被調用的先后順序(一般越上游的 API 定的數值要適當放大)以及會被重復調用的次數，得到每個 API 的 QPS 目標。比如，
- 獲取購物車列表，存在兩次調用，QPS = 200。
- 批量獲取商品庫存，存在三次調用，QPS = 300。
- 獲取會員信息，存在一次調用，QPS = 100。
- ……
照著這個思路，把所有業(yè)務線中會涉及到的 API 的 QPS 都確定好，然后將相同 API 的 QPS 數值相加，就能得到在整個系統(tǒng)層面每個 API 的理想 QPS 數值(相當于是在各條業(yè)務線都達到預估峰值的情況下)。比如，
- 獲取購物車列表，出現(xiàn)在三個業(yè)務線，QPS = 200 + 500 + 100 = 800。
- 批量獲取商品庫存，出現(xiàn)在兩個業(yè)務線，QPS = 300 + 200 = 500。
- 獲取會員信息，出現(xiàn)在兩個業(yè)務線，QPS = 100 + 200 = 300。
- ……
當然了，實際制定的目標除了 QPS 以外，還有其它指標，上面只是舉個例子。
另外，需要額外注意的是，要關注 TP90、TP99 的「響應時間」。因為就算平均響應時間達標了，也不代表整個系統(tǒng)很穩(wěn)定。因為可能存在80%的請求響應速度特別快，把平均值拉低了，但是同時還存在大量的耗時特別嚴重的請求。我慣用的經驗是，如果TP99超過了平均值的一倍，就需要引起重視了，因為這意味著某個地方存在著明顯的性能瓶頸。
03 制定具體的優(yōu)化方案
其實具體的優(yōu)化方案有很多種，要根據實際的情況來選擇。不過具體怎么選擇，還是需要你有全局視野。因為整個系統(tǒng)是一體的，通過相互配合形成合力，可以大大降低優(yōu)化的難度。比如，選擇某個優(yōu)化方案后，上游的 API 能扛掉90%的流量不往下游請求，那么下游 API 的 QPS 目標也可以適當降低了。
以下就是我綜合復雜度和成本所排列的具體方案，從簡單到復雜。
- 先在代碼層面做優(yōu)化，比如代碼性能，多線程，請求合并，池化(連接池、線程池、對象池等等)。
- 能升級硬件的就升級硬件。
- 能用緩存解決的堅決不做系統(tǒng)拆分。并且，緩存盡可能做到上游。比如， cdn >頁面> api > service 。
- 如果在數據處理上產生瓶頸，那么優(yōu)先考慮業(yè)務上是否接受異步，如果接受，那么用 MQ 來削峰填谷?；蛘呦蘖鹘导?。
- 如果 MQ 也不頂用，是整體吞吐量上的瓶頸的話，只要不是寫數據的瓶頸，盡量通過程序拆分而不是數據庫拆分來解決問題。(此時需要引入服務治理，另外，會存在一致性問題，數據合并問題要解決)
- 非得動到數據層面的話，優(yōu)先考慮數據庫讀寫分離，而不是直接拆分數據。
- 實在迫不得已需要拆分數據，優(yōu)先考慮根據業(yè)務垂直拆分，而不是水平拆分。(水平拆分的數據合并代價會比垂直拆分更大)
- 最后才是數據庫水平拆分，支持無限擴容，一勞永逸。
你看，雖然方案有很多，但是你也能觀察到一些規(guī)律：越在上游解決問題，成本越低。所以，以漏斗思維來做全局的考慮是最適合不過的。從客戶端請求到接入層，到邏輯層，到 DB 層，層層遞減，過濾掉請求，哪怕是出現(xiàn)異常也要 Fail Fast(要失敗也要盡早返回)。
/03 落地/
真正落地的時候，涉及到的具體技術細節(jié)就多了，負載均衡啊、緩存啊、消息隊列啊、分庫分表啊等等。我這里就不展開了，每一點展開都要寫好多。有興趣的小伙伴可以移步我之前寫的分布式系統(tǒng)系列文章——《8個月打磨，一份送給程序員的「分布式系統(tǒng)」合集》
其實，真正要把高并發(fā)當作一個系統(tǒng)化的事情來看待，視野不能僅僅局限在「性能」這一個維度上，還至少需要考慮「可用性」和「擴展性」這兩個方面。
可用性就是系統(tǒng)可以正常服務的時間。一個雖然訪問速度沒那么快，但是全年不停機、無故障;另一個雖然訪問速度很快，但是隔三差五出現(xiàn)上事故、宕機，用戶肯定選擇前者。
擴展性表示系統(tǒng)的快速擴展能力，當遇到突發(fā)的大流量沖擊時，能否在短時間內完成擴容，以承接這部分流量。比如，雙11活動、明星熱搜等場景。畢竟，我們不可能準確地預測未來的流量一定在什么范圍內，也更加不可能隨時為它準備著大量冗余的資源。
所以，這三個目標是需要通盤考慮的，因為它們互相關聯(lián)、甚至相互影響。
比如，當你考慮系統(tǒng)擴展能力的時候，你會將服務設計成無狀態(tài)的，這種設計其實不但提高了可擴展性，其實也間接提升了系統(tǒng)的性能和可用性，因為你可以隨時橫向擴展。
再比如，為了提高可用性，通常會對服務接口進行超時設置，以防大量線程阻塞在慢請求上造成系統(tǒng)雪崩。具體超時時間的設置成多少，參考的就是 API 的性能表現(xiàn)。
好了，總結一下。
這篇呢Z哥和你分享了我對高并發(fā)問題的處理思路。
按照以下三個步驟進行。
梳理請求流轉鏈路
確定目標
制定具體的優(yōu)化方案
其中的第2和3點在文中給了很多實操細節(jié)，這里就不一一羅列了。
希望對你有所幫助。
業(yè)務都是從0到1做起來的，在業(yè)務量逐漸變成原來的10倍、100倍的過程中，你是否用到了高并發(fā)的處理思路去演進你的系統(tǒng)，從架構設計、編碼實現(xiàn)、甚至產品方案等維度去預防和解決高并發(fā)的問題?
當前名稱：應對「高并發(fā)」的思路
文章鏈接：http://www.dlmjj.cn/article/coihioc.html
