假設報考app是用5W rmb 向供應商採購,報名當天湧入海量考生,並發數飆升至30W ,導致系統宕機,拒絕服務,致使考生無法報名,那麼5W rmb 能否支援30W 並發呢?
不過對我們來說,不妨把問題上升一個角度:「如何在有限的資源裡最大提升伺服器並發能力」。假設你是技術負責人,你在面對一個並發量較大的專案時會如何設計和架構呢?
首先我們可以針對這個項目捋一下大體的思路,從上述描述中不難看出,該項目的瓶頸在於“並發寫”而非“讀”,因此從資源分配上我們可以向“寫」傾斜,在此我將資料全部寫入在Redis中。除此之外,我們也需要盡量的將MySQL的讀取操作遷移到Redis上來,MySQL所做的工作更傾向於一些常規非並發的讀寫操作。
伺服器
當使用者要求過來,由負載平衡器負載到各個伺服器上
#這是一張來自symfony的壓測數據,使用的是1 CPU, 4 GB and PHP 7的配置。
上圖的資料來自於swoole官網,加上我們在實際業務邏輯的執行後,可以發現,當我們在使用常駐記憶體的啟動方式時,3台更低配伺服器就能解決上述需要16台才能解決的問題。
資料庫
其實許多人在接觸後端有一定的階段之後都會了解,現在的許多網路專案的瓶頸更多的集中在資料庫I/O這塊,各個語言之間並沒有特別大的差距。包括廣被大家所詬病的PHP-FPM的啟動方式,也可以使用swoole等方式來取代。因此,在這個專案中,會將更多的把精力集中在資料庫這一塊,可以嘗試使用Redis來解決,當然,在具體程式碼中,也需要提前準備好一定數量的資料連接池。另外,也考慮MongoDB雖然在同等配置下的寫入速度比MySQL快得多,但相較於Redis,還是有明顯不足。
註冊登入
註冊和登入其實應該分成兩塊來講,二者分別對應的是「寫」和「讀」。在高並發讀寫情況下,直接使用MySQL,如你預期的那樣,會爆。因此,我們在建構整個專案的過程中,可以將使用者資料快取到Redis中。 「寫」的問題:在使用者數量不明確且併發量較大的情況下,我更傾向於使用者資料不直接入庫。我們可以設計一個開關或閾值,來設定使用者的入庫方式,當並發大的情況下可以透過MQ來非同步讓使用者入庫,而平時則可以正常入庫。
提交表單
因為專案並非我們所常見的秒殺,且需要即時通知的,因此給我們專案的設計大大減少了難度。在提交表單的功能也跟註冊類似,我們完全可以讓資料異步入庫,然後後台審核。
總結
其他的像CDN、MySQL是否需要主從之類的就不再贅述了,視實際情況而定。從理論上,如果使用PHP-FPM的方式,大概需要19000元/月來解決專案的這個問題,而當使用swoole時,大概需要4500元/月,在這裡並沒有鼓吹swoole,想說明的是當我們在面對大並發專案時,尤其是業務邏輯相對複雜,我們使用常駐記憶體更能解決問題,而這與語言無關。最後,需要說明的是,上述僅是理論階段,至於實際數據如何都需要進一步檢驗。文章素材來自網絡,如果有寫的不正確的地方,望指出。
以上是怎麼使PHP伺服器在有限的資源中最大提升並發能力的詳細內容。更多資訊請關注PHP中文網其他相關文章!