詳解PHP服務器如何在有限的資源裡最大提升並發能力
概述
假設報考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服務器如何在有限的資源裡最大提升並發能力的資料請關註WalkonNet其它相關文章！