假設(shè)報(bào)考app是用5W rmb 向供應(yīng)商采購，報(bào)名當(dāng)天涌入海量考生，并發(fā)數(shù)飆升至30W+，導(dǎo)致系統(tǒng)宕機(jī)，拒絕服務(wù)，致使考生無法報(bào)名，那么5W rmb 能否支持30W+并發(fā)呢？

不過對于我們來說，不妨把問題上升一個(gè)角度：「如何在有限的資源里最大提升服務(wù)器并發(fā)能力」。假設(shè)你是一名技術(shù)負(fù)責(zé)人，你在面對一個(gè)并發(fā)量較大的項(xiàng)目時(shí)會如何設(shè)計(jì)和架構(gòu)呢？

首先我們可以針對這個(gè)項(xiàng)目捋一下大體的思路，從上述描述中不難看出，該項(xiàng)目的瓶頸在于「并發(fā)寫」而非「讀」，因此從資源分配上我們可以向「寫」傾斜，在此我將數(shù)據(jù)全部寫入在Redis中。除此之外，我們也需要盡量的將MySQL的讀操作遷移到Redis上來，MySQL所做的工作更傾向于一些常規(guī)非并發(fā)的讀寫操作。

當(dāng)用戶請求過來，由負(fù)載均衡器負(fù)載到各個(gè)服務(wù)器上

這是一張來自symfony的壓測數(shù)據(jù)，使用的是1 CPU, 4 GB and PHP 7的配置。

上圖的數(shù)據(jù)來自于swoole官網(wǎng)，在加上我們在實(shí)際業(yè)務(wù)邏輯的執(zhí)行之后，可以發(fā)現(xiàn)，當(dāng)我們在使用常駐內(nèi)存的啟動方式時(shí)，3臺更低配服務(wù)器就能解決上述需要16臺才能解決的問題。

其實(shí)許多人在接觸后端有一定的階段之后都會了解，現(xiàn)在的許多互聯(lián)網(wǎng)項(xiàng)目的瓶頸更多的集中在數(shù)據(jù)庫I/O這塊，各個(gè)語言之間并沒有特別大的差距。包括廣被大家所詬病的PHP-FPM的啟動方式，也可以使用swoole等方式來替代。因此，在這個(gè)項(xiàng)目中，會將更多的把精力集中于數(shù)據(jù)庫這一塊，可以嘗試使用Redis來解決，當(dāng)然，在具體代碼中，也需要提前準(zhǔn)備好一定數(shù)量的數(shù)據(jù)連接池。 另外，也考慮MongoDB雖然在同等配置下的寫入速度要比MySQL快得多，但是相比于Redis，還是存在明顯不足。

注冊和登錄其實(shí)應(yīng)該分成兩塊來講，二者分別對應(yīng)的是「寫」和「讀」。在高并發(fā)讀寫情況下，直接使用MySQL，如你期待的那樣，會爆。因此，我們在構(gòu)建整個(gè)項(xiàng)目的過程中，可以將用戶數(shù)據(jù)緩存到Redis中。 「寫」的問題：在用戶數(shù)量不明確且并發(fā)量較大的情況下，我更傾向于用戶數(shù)據(jù)不直接入庫。我們可以設(shè)計(jì)一個(gè)開關(guān)或閾值，來設(shè)置用戶的入庫方式，當(dāng)并發(fā)大的情況下可以通過MQ來異步讓用戶入庫，而平時(shí)則可以正常入庫。

因?yàn)樵擁?xiàng)目并非我們所常見的秒殺，且需要即時(shí)通知的，因此給我們項(xiàng)目的設(shè)計(jì)大大減少了難度。在提交表單的功能也跟注冊類似，我們完全可以讓數(shù)據(jù)異步入庫，然后后臺審核。

其他的像CDN、MySQL是否需要主從之類的就不再贅述了，視實(shí)際情況而定。從理論上，如果使用PHP-FPM的方式，大概需要19000元/月來解決項(xiàng)目的這個(gè)問題，而當(dāng)使用swoole時(shí)，大概需要4500元/月，在這里并沒有鼓吹swoole，想說明的是當(dāng)我們在面對大并發(fā)項(xiàng)目時(shí)，尤其是業(yè)務(wù)邏輯相對復(fù)雜，我們使用常駐內(nèi)存更能解決問題，而這與語言無關(guān)。 最后，需要說明的是，上述僅是理論階段，至于實(shí)際數(shù)據(jù)如何都需要進(jìn)一步檢驗(yàn)。文章素材來源于網(wǎng)絡(luò)，如果有寫的不正確的地方，望指出。

以上就是詳解PHP服務(wù)器如何在有限的資源里最大提升并發(fā)能力的詳細(xì)內(nèi)容，更多關(guān)于PHP服務(wù)器如何在有限的資源里最大提升并發(fā)能力的資料請關(guān)注好吧啦網(wǎng)其它相關(guān)文章！