假設報考app是用5W rmb 向供應商采購，報名當天涌入海量考生，并發數飆升至30W+，導致系統宕機，拒絕服務，致使考生無法報名，那么5W rmb 能否支持30W+并發呢？
不過對于我們來說，不妨把問題上升一個角度：「如何在有限的資源里最大提升服務器并發能力」，假設你是一名技術負責人，你在面對一個并發量較大的專案時會如何設計和架構呢？
首先我們可以針對這個專案捋一下大體的思路，從上述描述中不難看出，該專案的瓶頸在于「并發寫」而非「讀」，因此從資源分配上我們可以向「寫」傾斜，在此我將資料全部寫入在Redis中，除此之外，我們也需要盡量的將MySQL的讀操作遷移到Redis上來，MySQL所做的作業更傾向于一些常規非并發的讀寫操作，
服務器
當用戶請求過來，由負載均衡器負載到各個服務器上
★我的php學習交流社群「點擊」管理整理了一些資料，BAT等一線大廠進階知識體系備好（相關學習資料以及筆面試題）以及不限于：分布式架構、高可擴展、高性能、高并發、服務器性能調優、TP6，laravel，YII2，Redis，Swoole、Swoft、Kafka、Mysql優化、shell腳本、Docker、微服務、Nginx等多個知識點高級進階干貨需要的可以免費分享給大家
這是一張來自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 互聯網架構師成長指南+行業問題解決總綱（持續更新）
★面試10家公司，識訓9個offer，2020年PHP 面試問題
★如果喜歡我的文章，想與更多資深開發者一起交流學習的話，獲取更多大廠面試相關技術咨詢和指導，歡迎加入我們的群-點擊此處，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/1938.html
標籤：PHP