Web開發中，什麼級別纔算是高併發

這並非一個回答的問題的文章，而是由此引起的一個思考。

你們內心仔細想一想，當大家聽到高併發網站時，內心對這個網站是個什麼概念？首先想到的是淘寶嗎？帶着問題，咱們一塊兒思考技術

寫這個話題是由於我對搜索引擎給個人答案很不滿意，而後決定把思考的一些東西分享出來，但願能夠你們彼此討論下。

咱們常常在面試的時候，被問到有沒有高併發的經驗？先不說哪些考高併發的裝逼公司。我思考的是什麼纔算是高併發？你一天幾個pv確定高不了。首先在網上查找一下，並未找到明確的標準定義。那麼什麼是併發呢？

併發，在操做系統中，是指一個時間段中有幾個程序都處於已啓動運行到運行完畢之間，且這幾個程序都是在同一個處理機上運行，但任一個時刻點上只有一個程序在處理機上運行。

摘自百度百科

咱們說的高併發是什麼？

上面的定義明顯不是咱們一般所言的併發，在互聯網時代，所講的併發、高併發，一般是指併發訪問。也就是在某個時間點，有多少個訪問同時到來。

我看到有人給高併發下了相似的定義：

高併發一般是指咱們提供的系統服務可以同時並行處理不少請求。

來看看這個定義，這裏首先把併發給混淆到並行了。關於併發並行的區別看這裏，我就很少說，繼續探討併發。

而後定義又說不少請求？什麼叫不少請求？作爲中國人，這個詞讓我想象力一發不可收拾......好了，拉回來，繼續本文。

那麼從上面的分析，能夠看出來高併發在網絡上業界也沒有明確的定義。但根據我搜索狀況，通常都是pv在千萬級別以上的公司纔會涉及到這個概念。因此我得出一個自定義概念：若是某個系統的日pv在千萬級別以上，他就多是一個高併發的系統。

爲何說是可能？那是由於有的公司徹底不走技術路線，全靠機器堆，這不在咱們的討論範圍。

高併發的問題，咱們具體該關心什麼？

講真話，高併發是個比較抽象的概念。很難有一個統一的可衡量的標準。哪麼有一些其它維度的標準指標來衡量系統的性能嗎？搬出之前計算機課程裏邊的一些指標來跟你們聊聊。

先聲明幾個概念，別打瞌睡。

• QPS（TPS）：每秒鐘 request/事務 數量，在互聯網領域，指每秒響應請求數（指http請求）；
• 吞吐量：單位時間內處理的請求數量（一般由QPS與併發數決定）；
• 響應時間：系統對一個請求作出響應的平均時間。例如系統處理一個HTTP請求須要200ms，這個200ms就是系統的響應時間（我認爲這裏應該僅包含處理時間，網絡傳輸時間忽略）。

這裏必定要注意呃，QPS ≠ 併發數

併發是指，某個時刻有多少個訪問同時到來。QPS是指秒鐘響應的請求數量。那麼這裏就肯容易推算出一個公式：

QPS = 併發數 / 平均響應時間

後面咱們的分析都是圍繞這個公示來進行展開，沒明白的再回味一下。

如今咱們來假設一個場景：既然QPS是每秒鐘處理的http請求數量。那麼1s = 1000ms。假設咱們當前一個http請求服務器處理完成須要100ms（即那麼 平均響應時間 = 100ms ）。那麼它1s鍾能夠處理10個請求。也就是說 qps = 10。推算出 併發數 = 10

經常咱們被問到高併發的問題，其實從某種程度上來講是怎麼提升現有程序的性能。如今咱們基於上面的假設，來進行分析。假設如今有個系統性能上就是咱們上面的假設，它天天有 300萬pv，運行在單機上（固然常常宕機），按照上面的系統性能數據，給出優化解決方案。

提升併發能力

經過上面的分析，要提高併發能力，咱們就須要提高咱們的qps（其實這裏並不徹底正確，爲了說明問題，咱們先放棄一部分正確性）

最快速解決方案，就是增長機器。咱們根據以上狀況來實際計算一下。

• 訪問量：200w pv
• QPS：10

根據平常經驗，80% 的訪問量集中在 20%的時間，算一下這 200w pv實際須要機器達到多少qps才能知足。

qps = (200w * 0.8) / (24 * 3600 * 0.3)

qps = 61.7

實際上若是在單機上，要求咱們每秒鐘處理請求必須達到 61.7 以上才行，而實際上咱們當前系統的qps是 10。那麼怎麼解決？

方案一：上機器

我的的能力是有限的，團隊的力量是無窮的。既然一臺機器搞不定，咱們就多上幾臺機器。這就涉及到db主從、讀寫分離、負載均衡等技術。

它的原理就是分流，把之前集中的壓力分散開來。改方案見效快，靈活，實踐起來也更快。

方案二：增長單機性能

單機到底性能可以增長到一個什麼程度，這取決於你的機器配置，也取決於你的服務到底有多複雜。

ps： 寫到這裏忽然有點可以理解爲什網上對高併發都是講不少請求，沒有具體數據了，由於這真的只能針對業務來說，100個併發對靜態網頁來講根本沒有的事兒，可是對於某些密集計算型的估計...

那麼常見的單機如何提高性能？好比：增長不常變化數據的緩存，開啓php的opcache，優化代碼（如：n+1問題、多重嵌套循環、深層遞歸等），db表優化等等。因爲這些每個點拿出來都夠寫一本書了。咋就不繼續下去。

總結

因爲筆者本身也是沒有實際經歷過kw級別pv場景，不少東西講的不必定對，本文也是理清本身的一點思路。但願可以與更多朋友進行討論。

也但願本文可以解決你的一點疑惑，讓咱們可以從高大上的概念落實到實際問題中去。

參考資料

• 併發和並行的區別
• 系統性能測試想個概念

---

GitHub：https://github.com/helei112g

我在github開源了支付寶支付、微信支付、招商一網通支付的php sdk。但願可以幫助你提高項目開發的效率。項目地址