1.文檔閱讀

搭建高并發、高可用的系統 | Laravel China 社區

高并發， 你真的理解透徹了嗎？ - 知乎

PHP實戰經驗之系統如何支撐高并發-51CTO.COM

PHP高并發和大流量解決方案整理 - 騰訊云開發者社區-騰訊云

php高并發問題思路 - 掘金

關于PHP高并發搶購系統設計-蜂巢建站

一個高性能，高并發，高可用的系統是如何演變來的 | PHP 技術論壇?--- 下面的兩個鏈接是一起的

【進階】Mysql分庫分表方案，如何分，怎樣分？

PHP使用Nginx實現反向代理，學一學吧

2.整理輸出

環境

PHP技術棧

以及

其他語言技術棧

先放下截圖

后續補充

...

1. 網關，負載均衡，反向代理的區別和關系？

API 網關 vs 負載均衡 vs 反向代理 - 學習/實踐_網關反向代理_穿素白衫的中少年的博客-CSDN博客

2. 是不是高并發系統一定會用到“三者”？【網關，負載均衡，反向代理】

未必，通常只會用到一個或者兩個，當然也可以用三個，具體應該結合業務場景分析

3. 服務器能在沒有收到請求時，主動給客戶端發送請求嗎？

或者說，

客戶端A請求了服務端B，服務端B將請求轉發給了服務端C，那么服務端C可以在收到請求，處理之后，將響應直接返回給客戶端A嗎？

初步解答，我們知道通常的客戶端與服務端通信方式是：

客戶端先發起請求，服務端收到請求，然后返回響應，服務端想要主動發起請求「這里是就響應，本質上也是請求，一段網絡數據」，就需要用到websocket「這里是基于http進行通信的方式分析」

但是個人認為，技術是可以實現的，因為需要的信息都有，為什么不能主動發送請求呢？

與chatgpt的問答

在“反向代理”模式下，服務端C為什么不能跳過代理服務器B，直接返回響應給客戶端A？技術上無法實現嗎？

在“反向代理”模式下，服務端C不能跳過代理服務器B，直接返回響應給客戶端A。

這是因為在這種模式下，客戶端A與服務端C之間沒有直接的網絡連接，只有通過代理服務器B才能相互通信。

從技術上講，服務端C可以直接向客戶端A發送響應，但是客戶端A無法接收到這個響應。這是因為客戶端A發送請求時將其發送到代理服務器B，而不是直接發送到服務端C。客戶端A根本不知道服務端C的存在，也不知道服務端C的地址。因此，即使服務端C發送了響應，客戶端A也無法接收到它。

另外，即使服務端C能夠直接向客戶端A發送響應，這也不是一種安全的方式。在這種情況下，服務端C暴露在公共網絡上，并且可能會受到各種攻擊，例如DDoS攻擊、SQL注入攻擊等。因此，為了保障服務端C的安全性，必須通過代理服務器B來完成請求和響應的傳輸。

從技術上講，服務端C可以直接向客戶端A發送響應，但這通常需要滿足以下兩個條件：

1. 客戶端A能夠直接訪問服務端C，即客戶端A和服務端C之間不存在任何網絡層級的中間設備或代理。

2. 服務端C在響應中指定客戶端A的IP地址和端口號，以確保響應能夠準確到達客戶端A。

在實際場景中，通常很難同時滿足上述兩個條件，因此服務端C一般需要通過中間設備或代理來向客戶端A發送響應。即使服務端C能夠直接向客戶端A發送響應，也需要考慮可能存在的網絡拓撲變化、安全性等問題，因此通常不建議這么做。

服務端能否主動向客戶端發起連接請求？

在一般的網絡通信場景中，服務端是不能主動向客戶端發送連接請求的，因為在大多數情況下，客戶端處于一個比較安全的內網環境中，不會暴露在公網上。而服務端則通常處于公網或者云服務器等位置，有公網IP地址可以被客戶端訪問到。

因此，在大多數情況下，只有客戶端才能主動向服務端發起連接請求。

當然，也有一些特殊情況，例如在使用VPN、內網穿透等技術的情況下，服務端也可以通過一些手段實現向客戶端發起連接請求的功能。但這種情況屬于特殊情況，并不是一般的網絡通信方式。