基于PHP 搭建高并發分布式集群系統思路

做了很多有關php 專案，其中包括（P2P、電商、配送、CRM、OA等），我想對自己的作業成果經驗總結一下，同時也算是一次升華，

專案中經常提到大流量和高并發的名詞，聽起來很讓人害怕，無從下手，其實我們應該從實際的業務場景來規劃應該如果去解決這些問題，正常情況下我們系統應該只是某個或者某幾個服務壓力非常大，其他業務負載不會太高，下面我從整體的架構來記錄下思路，至于具體的實施方案，我在后續的文章會慢慢記錄下來，

高并發大流量的系統架構應該是從單體架構到服務拆分逐漸演變而來，并不是一次就實作并解決所有問題，我覺得要架構一個高并發大流量的網站至少要從以下11個方面去考慮，

一、web服務容器選型

對于php系統專案來說，
①、選擇nginx+php-fpm來作為我們的web容器，可以增加我們的并發連接數和處理效率，php-fpm和nginx默認選擇9000埠進行通信，但是在流量大時我出現埠阻塞情況，所以我們改用本地socket進行通信，

②、nginx使用反向代理服務器，將流量轉發到php-fpm服務器，

③、使用keepalived來對nginx代理服務器做高可用，

二、服務拆分、分布式集群部署

我們對整體系統進行需求分析后，可以將功能的模塊分開然后做成一個獨立的系統來進行服務，然后將這些獨立的服務進行集群部署，就形成了我們的分布式集群解決方案，

比如我們做電商系統現有：用戶模塊、商品模塊、訂單模塊、支付模塊、訊息模塊、物流資訊模塊、倉庫模塊等，我們可以將這些模塊獨立出來然后拆分為用戶服務、商品服務、訂單服務、支付服務、訊息服務、物流資訊服務、倉庫服務等，這從系統層面就實作了解耦，降低了代碼后期維護的難度，提高了服務器的回應，

但這樣做會衍生出三個問題：

①、系統的復雜度變高，

②、排查問題和例外變的例外復雜，

③、日志無序，分析問題變得困難，

怎么解決上面的問題呢？下面我們會慢慢闡述，

php常用六大設計模式：https://blog.csdn.net/jeremy_ke/article/details/89000003(轉載)

php陣列底層實作：https://www.cnblogs.com/mzhaox/p/11295445.html(轉載)

三、快取架構選型

我們現在主流的快取是使用redis來做，因為redis是單執行緒的記憶體操作，不消耗磁盤I/0，所以它單機正常情況下能達到10W/s的讀寫操作，它能解決高并發情況下的并發鎖和讀寫效率慢的問題，雖然這么優秀，但單機redis會存在單點故障，所以我們在選型的時候會選擇 以下兩種方案來保證redis的高可用，

①、一主多從 + 哨兵模式，

②、redis 集群模式，集群至少是3主3從才能搭建，而且可以動態擴容和分槽，

四、mysql資料庫架構選型

上面說到了我們將多個功能模塊拆分為多個服務后，那資料庫怎么處理呢？ 我們也使用分散方法，將不同的服務對應的資料庫放在不同的物理機下面，增加資料庫讀寫(I/O)能力，同時為了保證資料庫的高可用，我們應該采用一主多從或者多主多從的做法來提高我們資料庫的能力，更高層面的是采用異地多活(目前還未做過異地多活)，

MySQL雙主雙從同步配置：https://www.cnblogs.com/h--d/p/13336776.html(轉載)

五、資料庫優化

資料庫的優化是非常復雜且難做到的事情，我平時主要從以下幾個方面來做，

①、查詢SQL優化，盡量命中索引，重要SQL 陳述句一定要使用explain來做查詢預分析，

②、資料表建立合適的索引，提升查詢效率，innodb每個表都要自己創建主鍵，如果我們不創建主鍵，mysql自己也會創建一個隱藏的主鍵，

③、設定好innodb_buffer_poll_size的值，

④、設定好innodb_log_buffer_size的值，

⑤、選擇合適的innodb 事務隔離級別，

⑥、弄清楚innodb binlog日志與資料對磁盤的使用，找到合適的存盤方法，

⑦、熟悉innodb的存盤原理，提升磁盤I/O的率用率，

MySQL性能調優(存盤優化) ：https://blog.csdn.net/dichengyan0013/article/details/102347220(轉載)

六、前端優化（前后端分離）

前端我想到的只有三點，

①、減少dom樹的渲染，使用vue.js開發，

②、減少http請求數，將css和js檔案使用npm壓縮，減少帶寬，

③、使用cdn快取技術，

七、訊息佇列

對于大批量的資料處理，比如秒殺訂單或者發送短信、郵件這些，我們都需要用到訊息佇列，不管是redis 還是 kafka，都是實作訊息的一種方式，我們需要根據具體業務場景選擇使用哪種訊息佇列來實作業務上的解耦，

kafka中文檔案：https://www.orchome.com/66(轉載)

kafka什么時候會丟訊息：https://blog.csdn.net/qrne06/article/details/94225070(轉載)

kafka最全面試題： https://blog.csdn.net/qq_34668848/article/details/105611546(轉載)

zookeeper是干什么的：https://www.cnblogs.com/ultranms/p/9585191.html(轉載)

八、服務器監控

服務拆分后我們對服務器的運行情況和性能監控的掌握尤其應該注意，如果某個服務集群中的某臺服務器出問題，我們怎么來進行定位問題，或者某臺服務器負載過高，我們怎么知道，這些都需要監控來告訴我們，我們一般采用grafana + prometheus 對服務器進行監控和報警，

九、全鏈路日志

拆分成多個服務后，我們需要順序的記錄某次請求的所有日志，對我們分析線上問題來說將會提供極大便利，如果沒有統一存盤日志，我們就需要到每臺服務器去查詢日志，而且不知道哪個環節出問題，大大增加我們排查問題的難度，我們專案中一般使用ELK(elasticsearch、Logstash、Kibana） 來收集和處理日志，

十、基于swoft或者swoole的多行程框架

上面我們講述的是分布式集群的解決方案，隨著大資料時代的來臨，資料量的處理越來越大，我們大PHP 也有力不從心的時候，因為是單執行緒處理，限制了我們的處理能力，多執行緒對PHP來說支持的也不是很好，所以大佬們紛紛貢獻了 swoole 和 swoft 框架，其實swoft也是基于swoole去開發的，現在說一下這兩個框架吧，

swoole是一個用c++撰寫的高性能、異步、協程框架，它算是一個底層框架了，基于它人們又開發出了easyswoole、Hyperf等，

swoft也是一個基于swoole作為開發的框架，它完美的模仿了java spring的 ioc和aop 以及注解，增加了服務的注冊與發現、服務的熔斷、降級與限流，是非常好的php 多行程、多執行緒、協程 框架，

十一、并發壓力測驗

壓力測驗內容很多，這里就不細說了，大家可以在百度去搜索，

寫的很簡陋，至少我自己知道思路，朝著思路向前走，