目錄
- 概述
- 服務(wù)器
- 數(shù)據(jù)庫(kù)
- 總結(jié)
概述
假設(shè)報(bào)考app是用5W rmb 向供應(yīng)商采購(gòu),報(bào)名當(dāng)天涌入海量考生,并發(fā)數(shù)飆升至30W+,導(dǎo)致系統(tǒng)宕機(jī),拒絕服務(wù),致使考生無(wú)法報(bào)名,那么5W rmb 能否支持30W+并發(fā)呢?
不過(guò)對(duì)于我們來(lái)說(shuō),不妨把問(wèn)題上升一個(gè)角度:「如何在有限的資源里最大提升服務(wù)器并發(fā)能力」。假設(shè)你是一名技術(shù)負(fù)責(zé)人,你在面對(duì)一個(gè)并發(fā)量較大的項(xiàng)目時(shí)會(huì)如何設(shè)計(jì)和架構(gòu)呢?
首先我們可以針對(duì)這個(gè)項(xiàng)目捋一下大體的思路,從上述描述中不難看出,該項(xiàng)目的瓶頸在于「并發(fā)寫」而非「讀」,因此從資源分配上我們可以向「寫」傾斜,在此我將數(shù)據(jù)全部寫入在Redis中。除此之外,我們也需要盡量的將MySQL的讀操作遷移到Redis上來(lái),MySQL所做的工作更傾向于一些常規(guī)非并發(fā)的讀寫操作。
服務(wù)器
當(dāng)用戶請(qǐng)求過(guò)來(lái),由負(fù)載均衡器負(fù)載到各個(gè)服務(wù)器上
這是一張來(lái)自symfony的壓測(cè)數(shù)據(jù),使用的是1 CPU, 4 GB and PHP 7的配置。
上圖的數(shù)據(jù)來(lái)自于swoole官網(wǎng),在加上我們?cè)趯?shí)際業(yè)務(wù)邏輯的執(zhí)行之后,可以發(fā)現(xiàn),當(dāng)我們?cè)谑褂贸qv內(nèi)存的啟動(dòng)方式時(shí),3臺(tái)更低配服務(wù)器就能解決上述需要16臺(tái)才能解決的問(wèn)題。
數(shù)據(jù)庫(kù)
其實(shí)許多人在接觸后端有一定的階段之后都會(huì)了解,現(xiàn)在的許多互聯(lián)網(wǎng)項(xiàng)目的瓶頸更多的集中在數(shù)據(jù)庫(kù)I/O這塊,各個(gè)語(yǔ)言之間并沒(méi)有特別大的差距。包括廣被大家所詬病的PHP-FPM的啟動(dòng)方式,也可以使用swoole等方式來(lái)替代。因此,在這個(gè)項(xiàng)目中,會(huì)將更多的把精力集中于數(shù)據(jù)庫(kù)這一塊,可以嘗試使用Redis來(lái)解決,當(dāng)然,在具體代碼中,也需要提前準(zhǔn)備好一定數(shù)量的數(shù)據(jù)連接池。 另外,也考慮MongoDB雖然在同等配置下的寫入速度要比MySQL快得多,但是相比于Redis,還是存在明顯不足。
注冊(cè)登錄
注冊(cè)和登錄其實(shí)應(yīng)該分成兩塊來(lái)講,二者分別對(duì)應(yīng)的是「寫」和「讀」。在高并發(fā)讀寫情況下,直接使用MySQL,如你期待的那樣,會(huì)爆。因此,我們?cè)跇?gòu)建整個(gè)項(xiàng)目的過(guò)程中,可以將用戶數(shù)據(jù)緩存到Redis中。 「寫」的問(wèn)題:在用戶數(shù)量不明確且并發(fā)量較大的情況下,我更傾向于用戶數(shù)據(jù)不直接入庫(kù)。我們可以設(shè)計(jì)一個(gè)開(kāi)關(guān)或閾值,來(lái)設(shè)置用戶的入庫(kù)方式,當(dāng)并發(fā)大的情況下可以通過(guò)MQ來(lái)異步讓用戶入庫(kù),而平時(shí)則可以正常入庫(kù)。
提交表單
因?yàn)樵擁?xiàng)目并非我們所常見(jiàn)的秒殺,且需要即時(shí)通知的,因此給我們項(xiàng)目的設(shè)計(jì)大大減少了難度。在提交表單的功能也跟注冊(cè)類似,我們完全可以讓數(shù)據(jù)異步入庫(kù),然后后臺(tái)審核。
總結(jié)
其他的像CDN、MySQL是否需要主從之類的就不再贅述了,視實(shí)際情況而定。從理論上,如果使用PHP-FPM的方式,大概需要19000元/月來(lái)解決項(xiàng)目的這個(gè)問(wèn)題,而當(dāng)使用swoole時(shí),大概需要4500元/月,在這里并沒(méi)有鼓吹swoole,想說(shuō)明的是當(dāng)我們?cè)诿鎸?duì)大并發(fā)項(xiàng)目時(shí),尤其是業(yè)務(wù)邏輯相對(duì)復(fù)雜,我們使用常駐內(nèi)存更能解決問(wèn)題,而這與語(yǔ)言無(wú)關(guān)。 最后,需要說(shuō)明的是,上述僅是理論階段,至于實(shí)際數(shù)據(jù)如何都需要進(jìn)一步檢驗(yàn)。文章素材來(lái)源于網(wǎng)絡(luò),如果有寫的不正確的地方,望指出。
以上就是詳解PHP服務(wù)器如何在有限的資源里最大提升并發(fā)能力的詳細(xì)內(nèi)容,更多關(guān)于PHP服務(wù)器如何在有限的資源里最大提升并發(fā)能力的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章!
您可能感興趣的文章:- php多進(jìn)程并發(fā)編程防止出現(xiàn)僵尸進(jìn)程的方法分析
- PHP高并發(fā)和大流量解決方案整理
- PHP 并發(fā)場(chǎng)景的幾種解決方案
- PHP下用Swoole實(shí)現(xiàn)Actor并發(fā)模型的方法
- php多進(jìn)程模擬并發(fā)事務(wù)產(chǎn)生的問(wèn)題小結(jié)
- PHP利用Mysql鎖解決高并發(fā)的方法
- PHP curl批處理及多請(qǐng)求并發(fā)實(shí)現(xiàn)方法分析
- php curl批處理實(shí)現(xiàn)可控并發(fā)異步操作示例
- PHP使用curl_multi實(shí)現(xiàn)并發(fā)請(qǐng)求的方法示例