伺服器如何實現承受如此大量的用戶請求?
0.
以網站和遊戲伺服器為例.1.是否每一位用戶都將自己的請求發送到同一IP地址?2.在此,伺服器對待這些請求,是否只有2種處理方式:
一種獨立完成另一種先用一台伺服器接收下來,然後通過某種方式將請求分發給其他伺服器.3.可否就"伺服器分發請求"這種方式簡述一下實現?4.是否不論是以上哪兩種,這其中必然會有一個集中處理的過程??5.若存在一個集中處理的過程,像百度這樣的網站,又是如何做到讓集中接收請求的那台機器不被大量的用戶請求淹沒?===============================================現已知整個問題是負載均衡,但問題4中提到的,就算是暫存-分發的過程,是否也是用邏輯上一台伺服器所實現的?
這台機器到達極限就阻塞了對嗎?
1. HTTP 負載均衡： Nginx 工作在TCP第7層2. TCP 負載均衡： LVS 工作在TCP第4層 還有HaProxy3. 還有一種接近的東西，用 DNS 做負載均衡4. 商業上還有一個大名鼎鼎硬體F5
Cdn可以做請求緩存；dns可以做第一級請求分派，將用戶請求分派到最靠近用戶的服務地址；lvs可以做同機房一層的請求分發；squid/nginx等可以做更細力度的代理；後面服務IO的部分還有memcache/redis等緩存方法。根據業務需求靈活組合，各種方法對資源的需求，調控靈活度，更新實效性等各方面都各有優劣，就看業務需求如何妥協平衡
首先我想說樓主的提問列表很程序員，從0開始的。
1.這個當然是不一定的，樓主已經知道問題是負載均衡了，現在大型伺服器一般都會做成分散式的。
2.其實你說的意思應該是直接處理這個請求還是我找另外一個機器處理你的請求。3.伺服器分發請求有很多種策略，舉個簡單的例子。某個伺服器在登錄的時候根據用戶的ID取模，然後選擇對應的一台機器進行轉發，這是一種比較簡單的分發請求策略了。再比如很多遊戲伺服器會分網通、電信等大區，然後大區下有分1,2,3...多個房間，這些其實都是分發請求的例子。4.根據你的業務類型，可能會存在一個必須有集中處理的過程。比如登錄校驗這個過程，所有的請求最終都要去查詢db，那麼如果db只有一台的話就會存在你說的集中處理情況。現在的開發很聰明的，無論是高並發還是容災都不會只搞一台db的，他們可以分庫分表，可會主從備份，甚至是讀寫分離。5.在設計伺服器的時候，肯定會相對會有4中的情況，我們當然不希望因為4中的情況而影響整個伺服器的性能。我們可以把分發策略放在客戶端，比如登錄的時候在客戶端進行選擇，直接登錄到負載較低的伺服器上。你會說客戶端查詢各個伺服器的負載情況這個功能介面會壓力很大，其實不做IO操作的話，僅僅是獲取內存中的數據性能會很高的。如果樓主需要進行伺服器壓力測試的話可以試試騰訊公司的一款工具WeTest伺服器性能，用來測試伺服器各個介面的性能情況很有效。陳大神解答了高層面的問題，我來逐條低層回答一下。
0.
以網站和遊戲伺服器為例.1.
是否每一位用戶都將自己的請求發送到同一IP地址?
實際應用中他們只將請求發送到同一域名，不一定是同一IP地址。
2.
在此,伺服器對待這些請求,是否只有2種處理方式:一種獨立完成另一種先用一台伺服器接收下來,然後通過某種方式將請求分發給其他伺服器.
如果都指向同一IP地址的話，是。但如何實現「另一種」有很多種方法。
3.
可否就"伺服器分發請求"這種方式簡述一下實現?
此類技術統稱Load Balancing，根據你的服務需要可以在TCP/IP棧的上四層的任何一層實現。每一層又有不同的實現方法。具體的大概讀一讀相關文檔更容易。
4.
是否不論是以上哪兩種,這其中必然會有一個集中處理的過程??
你既然已經要求到達同一IP了，自然這個IP上就要集中處理。當然對於大多數業務後台也會集中處理，不過不在此題目之限。
5.
若存在一個集中處理的過程,像百度這樣的網站,又是如何做到讓集中接收請求的那台機器不被大量的用戶請求淹沒?
首先你的硬體要足夠強大…當然這是廢話。除此之外，軟體設計上的性能優化思路是這樣的——
1、Load Balancer應當避免對數據進行修改2、LB應當緩存決策3、LB應當無鎖所以最終性能好的實現要麼在應用層要麼在鏈路層，因為只有這兩層邏輯上可以實現這三個特性要求。===============================================
現已知整個問題是負載均衡,但問題4中提到的,就算是暫存-分發的過程,是否也是用邏輯上一台伺服器所實現的?這台機器到達極限就阻塞了對嗎?
對。但你還有一招就是可以多級LB。
伺服器如何實現多台機器共用一個IP地址而承受用戶請求?
可以，但是我不知道有沒有開源的方案。
Google Compute Engine 就支持多個虛擬機共享同一個公網IP。 Load BalancingAmazon 也有類似的技術，但是實現可能很不一樣。What Is Elastic Load Balancing?區別在於你的虛擬機看到的 Client IP 是 loadbalancer IP 還是客戶的真實IP。大致可以說，Google 的 load balancer 工作在第4層，而 Amazon 的在第 7 層。這影響到你的 SSL certs 是放在本機，還是放在 load balancer。========== 2016/7/31 更新 ==========Google 的技術公開了，叫 Maglev，目前還沒有開源實現，估計不久就會有了。http://research.google.com/pubs/pub44824.html＊不太贊同本回答之前所有回答！！！＊
不太贊同的原因很簡單，不夠全面，過於偏向Web為主的網站，或者壓根就沒什麼乾貨。。。
簡單回答一遍題主的問題吧。
0.
以網站和遊戲伺服器為例.
04～06年做過遊戲，05～07年還負責過視頻分享網站和即時通訊，10～13年在開心網（用戶超1.6億，DAU最高可到3、4千萬）做分散式架構，14～現在 在遊戲公司做基礎設施架構。應該滿足題主需求吧。
1.
是否每一位用戶都將自己的請求發送到同一IP地址?
不一定。關於這條，前面幾個回答還是靠譜的。用戶訪問的是域名，同一個域名可以解析道不同的IP上。而這些IP呢，可未必就是業務伺服器，還可能是負載均衡服務。特別是全球部署的業務更是這樣。
2.
在此,伺服器對待這些請求,是否只有2種處理方式:一種獨立完成另一種先用一台伺服器接收下來,然後通過某種方式將請求分發給其他伺服器.
目前就這兩種，小公司小網站小業務一般也就第一種了，還有現在不少小創業公司的遊戲，如果分服，也以第一種居多。但如果用戶多了，或者公司成長了，那基本上都是第二種。
3.
可否就"伺服器分發請求"這種方式簡述一下實現?
關於這個回答就是我「不太贊同」之前所有回答，甚至想反對之前所有回答的原因。
之前的回答全是負載均衡LB！！！但問題沒這麼簡單！！！坑害深著呢！！！！對於海量數據和海量並發請求，集群處理，有LB導致的需求，也有存儲容量導致的需求。在以微服務的架構下，一個業務流程可能會經歷多個業務伺服器。而這多個業務伺服器，甚至包含Gate服務，是不是需要轉發，有LB導致的需求，也有後端服務LB或者存儲容量導致的需求。而且，還有一大類是容災和故障轉移等安全和穩定性導致的需求。
比如作為一個Gateway，要訪問後端用戶交易系統，分發請求道不同的用戶交易系統Gateway，這個可以說是因為後端用戶交易系統Gateway的LB導致的需求；又比如作為一個Gateway，要訪問後端資料庫，分發請求到不同的資料庫，這是容量導致的需求；又比如作為一個Gateway，要訪問後端About或者其他極少變動也極少訪問的業務配置信息緩存，這是架構設計容災災備導致的需求，和LB、容量等等無關。又比如作為一個業務服務，當需要聚合資源時，分發請求到不同的後端服務上去，這是架構設計也業務導致的需求，可能完全和LB沒有半毛錢關係。
而分發請求的方式呢，一般我常用的有這麼幾種（根據不同的需求，用的方式不同）：
一致性Hash，隨機、輪轉、分區/段、強一致性分發、廣播、任一成功廣播、半數成功廣播。再說一遍，業務不同，需求不同，方式也就不同。4.
是否不論是以上哪兩種,這其中必然會有一個集中處理的過程??
可能沒有，取決於業務。
但分散式系統中，一般常見的是，對於但個業務流來說，是的；對於業務流整體來說，不是。好比我用戶a的X業務，A伺服器集中處理；用戶b的X業務，B伺服器集中處理。但就X業務這一類來說，沒有集中處理。而且根據資源分布，用戶a的X業務，也有可能在不同的伺服器上被分段集中處理。這樣的話，實際上沒有一個伺服器集中處理。
5.
若存在一個集中處理的過程,像百度這樣的網站,又是如何做到讓集中接收請求的那台機器不被大量的用戶請求淹沒?
參見上一條的回答，分散式的分段「集中」處理。
說白了，就是分散式分階段數據聚合。現已知整個問題是負載均衡,但問題4中提到的,就算是暫存-分發的過程,是否也是用邏輯上一台伺服器所實現的?
參見之前幾條的回答，這不一定是負載均衡的問題。
當系統很小的時候，這不一定是負載均衡的問題。當你的系統開始成長，負載均衡成了主要的凸顯需求；但當你的系統大到一定程度，架構設計和流程優化層面的因素就更加凸顯，負載均衡反而成了次一等的考慮因素了。再加上之前說的分散式分階段數據聚合，這是不是「邏輯上一台伺服器所實現」，就看你這「邏輯伺服器」是怎麼定義的了。
這台機器到達極限就阻塞了對嗎?
一般情況下，是的。但如果設計好的伺服器，或者框架，有自動過濾、屏蔽、回復、轉移等特性，所以不一定會阻塞。或者，會極大的推遲阻塞的到來。
但目前阻塞最大的誘因是，你的帶寬被佔滿了。無聊刷題玩。。。。。。。。。。
0.
以網站和遊戲伺服器為例.1.是否每一位用戶都將自己的請求發送到同一IP地址?=======================================================未必，在分散式架構中，入口/路由服務可以分擔很多事情，就算負載均衡也可以這麼操作。2.
在此,伺服器對待這些請求,是否只有2種處理方式:一種獨立完成另一種先用一台伺服器接收下來,然後通過某種方式將請求分發給其他伺服器.========================================================你這個很概括了，你還能想出第三種模式么。3.
可否就"伺服器分發請求"這種方式簡述一下實現?=========================================================請求-》區分類型-》查找合適處理的節點-》發送請求-》節點處理完成-》丟入結果分發-》通過消息路由-》找到用戶-》返回結果4.
是否不論是以上哪兩種,這其中必然會有一個集中處理的過程??==========================================================未必，均衡和任務分配可以做到去中心化的請求方式，我們自己在實現也是盡量避免過度的依賴中心化。5.若存在一個集中處理的過程,像百度這樣的網站,又是如何做到讓集中接收請求的那台機器不被大量的用戶請求淹沒?===========================================================均衡和拆分，一堆既定分離又看似合作的機制，理論上無限堆機器即可。從所有你想得到的層面去分流
伺服器分發請求有很多種策略，舉個簡單的例子。某個伺服器在登錄的時候根據用戶的ID取模，然後選擇對應的一台機器進行轉發，這是一種比較簡單的分發請求策略了。再比如很多遊戲伺服器會分網通、電信等大區，然後大區下有分1,2,3...多個房間，這些其實都是分發請求的例子。
0.以網站和遊戲伺服器為例.
1.是否每一位用戶都將自己的請求發送到同一IP地址?
一般來說都是請求同一個域名，解析到不同的IP，但這些解析出來的IP可以是機器實際IP，也可以是集群的IP
2.在此,伺服器對待這些請求,是否只有2種處理方式:
a.一種獨立完成 b.另一種先用一台伺服器接收下來,然後通過某種方式將請求分發給其他伺服器.
2.a 獨立完成的就是機器實際IP
2.b 並無「接收下來」一說，通常是收到請求就轉發，可以是IP層轉發（交換機），可以是TCP層轉發（LVS），可以是HTTP層轉發（NGINX）。3.可否就"伺服器分發請求"這種方式簡述一下實現?
上面提到的LVS就非常典型，Google一下吧
4.是否不論是以上哪兩種,這其中必然會有一個集中處理的過程??
大型服務都是分散式的，在DNS解析這層做第一次分布，把不同地理位置不同運營商的用戶引導去不同的IP，這些「不同的IP」實際就是集群的VIP，我想題主關心的應該是這個。
5.若存在一個集中處理的過程,像百度這樣的網站,又是如何做到讓集中接收請求的那台機器不被大量的用戶請求淹沒?
一般情況下上線的Load Balancing 伺服器都是經過容量評估的，不會把超過負載的請求引過來（攻擊是另一回事）。
另外Load Balancing伺服器也可以是集群socket http 兩種目前的開源技術+雲 搞定抗ddos 抗拖庫 抗xss cdn 自動彈性伸縮 自動負載均衡 業務邏輯一個人夠了 老司機（適用99.9999%的場景 google 蘋果那樣流量的是另一個故事）練手的就不好說了 累得臭死的一堆人也會漏洞百出
其實這個跟伺服器端程序寫的水平也是有很大關係的，寫好了，一台伺服器也可以支持很大量的用戶請求，寫的不好，你100台伺服器也不一定行。好與不好，區別大了。把單台伺服器最大的壓榨跑滿用足，這個已經夠應付多數情況了，然後再考慮其他吧，其實只要不是BAT，哪有那麼多用戶請求啊。
他不是一個人在戰鬥
負載均衡 ！總之麻煩！
可以用lvs加上keepalive讓乾颱伺服器用分發請求，也可以直接買load balancer
負載均衡 nginx ip_hash
全球伺服器 國內外域名 空間郵箱 歡迎來了解
1.是否每一位用戶都將自己的請求發送到同一IP地址?
可以採用CDN分發到不同伺服器。詳情搜索CDN。2.在此,伺服器對待這些請求,是否只有2種處理方式:
一種獨立完成另一種先用一台伺服器接收下來,然後通過某種方式將請求分發給其他伺服器.你這不廢話嗎？
3.可否就"伺服器分發請求"這種方式簡述一下實現?
詳情搜索反向代理4.是否不論是以上哪兩種,這其中必然會有一個集中處理的過程??
不是5.若存在一個集中處理的過程,像百度這樣的網站,又是如何做到讓集中接收請求的那台機器不被大量的用戶請求淹沒?同上0.
以網站和遊戲伺服器為例.--------------------------------------以網站為例，無論靜態還是動態都有一個叫DNS的好東西，還有js工程師可以做很多很多事情。以遊戲伺服器為例，一個遊戲一般就1-3台虛擬機就行，人多了就開新服。所以剩下的問題統統不用答了，我不是為了裝而裝，也請各位不要因為自己有個鎚子就看什麼都像釘子。
建議相關編輯把「雲計算」的標籤拿掉，這跟雲計算沒啥關係。推薦閱讀：
※WP8會卡頓么？
※學習大數據要從哪些知識點開始著手？
※AI、VR、AR、大數據、雲計算、區塊鏈，哪些更有前景，哪些只是泡沫？
※一句話說出你對雲計算的理解？
※根據時間生成手機令牌密碼的原理是什麼？