概述

假設報考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，想說明的是當我們在面對大併發專案時，尤其是業務邏輯相對複雜，我們使用常駐記憶體更能解決問題，而這與語言無關。 最後，需要說明的是，上述僅是理論階段，至於實際資料如何都需要進一步檢驗。文章素材來源於網路，如果有寫的不正確yDLwpxawj

以上就是詳解PHP伺服器如何在有限的資源裡最大提升併發能力的詳細內容，更多關於PHP伺服器如何在有限的資源裡最大提升併發能力的資料請關注我們其它相關文章！