PHP服務器如何在有限的資源裏最大提高併發能力？

時間 2020-08-17

標籤 php 服務器如何有限資源最大提高併發能力欄目 PHP 简体版

原文原文鏈接

假設報考app是用5W rmb 向供應商採購，報名當天涌入海量考生，併發數飆升至30W+，致使系統宕機，拒絕服務，導致考生沒法報名，那麼5W rmb 可否支持30W+併發呢？php

不過對於咱們來講，不妨把問題上升一個角度：「如何在有限的資源裏最大提高服務器併發能力」。假設你是一名技術負責人，你在面對一個併發量較大的項目時會如何設計和架構呢？laravel

首先咱們能夠針對這個項目捋一下大致的思路，從上述描述中不難看出，該項目的瓶頸在於「併發寫」而非「讀」，所以從資源分配上咱們能夠向「寫」傾斜，在此我將數據所有寫入在Redis中。除此以外，咱們也須要儘可能的將MySQL的讀操做遷移到Redis上來，MySQL所作的工做更傾向於一些常規非併發的讀寫操做。面試

服務器

當用戶請求過來，由負載均衡器負載到各個服務器上sql

★個人php學習交流社羣「點擊」管理整理了一些資料，BAT等一線大廠進階知識體系備好（相關學習資料以及筆面試題）以及不限於：分佈式架構、高可擴展、高性能、高併發、服務器性能調優、TP6，laravel，YII2，Redis，Swoole、Swoft、Kafka、Mysql優化、shell腳本、Docker、微服務、Nginx等多個知識點高級進階乾貨須要的能夠免費分享給你們shell

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

上圖的數據來自於swoole官網，在加上咱們在實際業務邏輯的執行以後，能夠發現，當咱們在使用常駐內存的啓動方式時，3臺更低配服務器就能解決上述須要16臺才能解決的問題。後端

數據庫

其實許多人在接觸後端有必定的階段以後都會了解，如今的許多互聯網項目的瓶頸更多的集中在數據庫I/O這塊，各個語言之間並無特別大的差距。包括廣被你們所詬病的PHP-FPM的啓動方式，也可使用swoole等方式來替代。所以，在這個項目中，會將更多的把精力集中於數據庫這一塊，能夠嘗試使用Redis來解決，固然，在具體代碼中，也須要提早準備好必定數量的數據鏈接池。另外，也考慮MongoDB雖然在同等配置下的寫入速度要比MySQL快得多，可是相比於Redis，仍是存在明顯不足。緩存

註冊登陸

註冊和登陸其實應該分紅兩塊來說，兩者分別對應的是「寫」和「讀」。在高併發讀寫狀況下，直接使用MySQL，如你期待的那樣，會爆。所以，咱們在構建整個項目的過程當中，能夠將用戶數據緩存到Redis中。「寫」的問題：在用戶數量不明確且併發量較大的狀況下，我更傾向於用戶數據不直接入庫。咱們能夠設計一個開關或閾值，來設置用戶的入庫方式，當併發大的狀況下能夠經過MQ來異步讓用戶入庫，而平時則能夠正常入庫。服務器

提交表單

由於該項目並不是咱們所常見的秒殺，且須要即時通知的，所以給咱們項目的設計大大減小了難度。在提交表單的功能也跟註冊相似，咱們徹底可讓數據異步入庫，而後後臺審覈。swoole

總結

其餘的像CDN、MySQL是否須要主從之類的就再也不贅述了，視實際狀況而定。從理論上，若是使用PHP-FPM的方式，大概須要19000元/月來解決項目的這個問題，而當使用swoole時，大概須要4500元/月，在這裏並無鼓吹swoole，想說明的是當咱們在面對大併發項目時，尤爲是業務邏輯相對複雜，咱們使用常駐內存更能解決問題，而這與語言無關。最後，須要說明的是，上述僅是理論階段，至於實際數據如何都須要進一步檢驗。文章素材來源於網絡，若是有寫的不正確的地方，望指出。

★PHP 互聯網架構師成長指南+行業問題解決總綱（持續更新）

★面試10家公司，收穫9個offer，2020年PHP 面試問題

★若是喜歡個人文章，想與更多資深開發者一塊兒交流學習的話，獲取更多大廠面試相關技術諮詢和指導，歡迎加入咱們的羣-點擊此處。