如何設計一個高並發高可靠的伺服器

1. 自己如何搭建伺服器。

1、打開控制面板，選擇並進入「程序」，雙擊「打開或關閉Windows服務」，在彈出的窗口中選擇「Internet信息服務」下面所有地選項，點擊確定後，開始更新服務。

(1)如何設計一個高並發高可靠的伺服器擴展閱讀：

入門級伺服器所連的終端比較有限（通常為20台左右），況且在穩定性、可擴展性以及容錯冗餘性能較差，僅適用於沒有大型資料庫數據交換、日常工作網路流量不大，無需長期不間斷開機的小型企業。

不過要說明的一點就是目前有的比較大型的伺服器開發、生產廠商在後面我們要講的企業級伺服器中也劃分出幾個檔次，其中最低檔的一個企業級伺服器檔次就是稱之為"入門級企業級伺服器"，這里所講的入門級並不是與我們上面所講的"入門級"具有相同的含義，不過這種劃分的還是比較少。

還有一點就是，這種伺服器一般採用Intel的專用伺服器CPU晶元，是基於Intel架構（俗稱"IA結構"）的，當然這並不是一種硬性的標准規定，而是由於伺服器的應用層次需要和價位的限制。

2. 高並發網站架構的設計方案是怎樣的

技術這玩意兒，你不深入使用它，你就不知道它有多牛，更不知道會有多難！

並發:指定時間段內的請求數！

高並發:指定時間段內的超多請求數！

比如tomcat，單機最大支持並發數為8000左右，redis理論值可達到幾萬！

那麼怎麼設計一套可支持高並發的系統呢？使用技術如下:

1，分布式系統，微服務:使用springcloud家族包括eureka，zuul，feign，hysrix等或者bbo搭建一套微服務框架！

2，前後端分離:使用node.js搭建前端服務系統！

3，靜態化處理:將頁面，後台枚舉，資料庫定義表等使用靜態處理方式做處理！

4，文件伺服器剝離:採用單獨的文件伺服器，防止頁面載入的阻塞！

5，緩存:使用redis，memcache等將運行時數據緩存，代替頻繁的操作資料庫！

6，資料庫:讀寫分離或者分庫分表，採用druid等有性能監控系統的資料庫連接框架！

7，消息中間件:使用xxxmq，kafka等消息中間件，解耦服務，而且非同步處理效率更高！

8，反向代理:使用nginx等負載均衡服務！

9，代碼層:避免大量創建對象，避免阻塞IO，避免多層for循環，避免線程死鎖，避免大量同步！

10，各種優化:包括jvm優化，表結構優化，sql優化，關鍵欄位加索引（注意避免索引失效），連接池優化等等！

11，搜索引擎:sql有大量的like語句，有必要切換成solr等搜索引擎！

12，cdn:使用CDN技術將請求分發到最合適的主機上，避免網路傳輸的延遲！

13，使用batch:增刪改能一次做的別分為兩次，但要注意batch合理設計，防止數據丟失！

14，限流，削峰！

大型網站遇到的挑戰，主要是大量的用戶，高並發的訪問，就算一個簡單的增刪查改的功能，如果面對的是百萬、千萬甚至億級的用戶，都是一件難度很大的事情。

數據從資料庫到瀏覽器的過程：資料庫->應用數據集->內存對象->動態頁面->HTTP伺服器->用戶瀏覽器。 那麼我們可以把高並發的設計分成幾個層次：

前端是指，用戶的請求還沒有到服務前的環節。

系統架構大了，部署的伺服器多了，很多事情不可能通過人工完成了，比如一個介面調用發生了錯誤，不可能人工登錄到伺服器上去查日誌吧，所以這些東西也是必不可少的。

都是說個大概，後面有機會的話，會把每一項都並伍展開詳細說明。

希望我的回答能夠幫助到你！

我們通過這些架構要素來衡量我們整體系統架構設計的優劣，來判斷是絕遲或否達到了我們的要求。

性能是大型網站架構設計的一個重要方面，任何軟體架構設計方案都必須考慮可能帶來的性能問題，也正因為性能問題幾乎無處不在，在請求鏈路的任何一個環節，都是我們去做極致性能優化方案中的切入點。

衡量一個系統架構設計是否滿足高可用的目標，就是假設系統中任何一台或者多台伺服器宕機時，以及出現各種不可預期的問題時，系統整體是否依然可用。

網站的伸縮性是指不需要改變伺服器的硬體設計，僅僅靠改變應用伺服器的部署數量，就可以擴大或縮小伺服器的處理能力。

網站快速發展，功能不斷擴展，如何設計網站的旦孫架構使其能夠快速響應需求變化，是網站可擴展架構的主要目標。

互聯網跟傳統軟體不同，它是開放的，任何人在任何地方都可以訪問網站。網站的安全架構就是保護網站不受惡意訪問和攻擊，保護網站的重要數據不被竊取。

安全性架構，具體來說說就是保證數據的保密性、完整性、真實性、佔有性。

要完全掌握大型網站的架構設計方案，或許你可以點擊我頭像，進入我的專欄"深入大型網站核心架構實戰"。

這期專欄是筆者總結了當下這些互聯網行業中相對成熟且經過大型網站檢驗的技術和方案，內容涵蓋構建大型互聯網系統服務所需的關鍵技術。

3. 為保證伺服器高可靠性，高可用性，應採取哪些技術

1，從伺服器硬體系統的匯流排和處理器的處理能力入手。伺服器的系統匯流排已經從過去的16位、32位發展到現在的64位；局部I/O匯流排技術(例如AGP、PCI-Express)在不斷改進；SMP(對稱多處理器)技術和DP(雙處理器)技術的應用，硬體冗餘和負載均衡技術的發展，大容量內存校驗、糾錯和專用內存技術的進步。 2，伺服器硬體設計改進。硬體設計高度模塊化，便於故障診斷與維修。硬體冗餘，例如雙電源、雙CPU(雙CPU還能提高性能)。大功率的冷卻系統。指示燈故障示警。 3，高速、多個數、大容量磁碟的應用。支持 SCSI 高速硬碟及 Raid 技術，支持陣列卡以及光通訊設備。外接磁碟擴展陣列櫃滿足了大容量存儲和提高了存儲的I/O性能，高智能的陣列可以保證數據的安全和完整。本地Raid1雙硬碟基本杜絕了由於磁碟損壞而破壞OS的可能性。 4，支持集群、熱備和均衡技術。集群和均衡技術的使用，使伺服器系統具備了整體的容錯功能和承載能力，我們不必擔心由於伺服器的意外故障和突發訪問而引起的服務關閉甚至系統崩潰。 5，系統備份和容災。高性能的備份軟體可以對系統進行備份，便於軟體系統(OS、資料庫系統、郵件系統、財務軟體等)的及時恢復。異地容災、應用級容災降低了軟體系統遭受數據丟失的災難，和提高了災難恢復的效率。 本文來自「十萬個為什麼」電腦學習網 http://www.why100000.com

希望採納

4. 美團面試題：如何設計負載均衡架構支撐千萬級用戶的高並發訪問

1.1 負載均衡介紹

1.1.1 負載均衡的妙用

1.1.2 為什麼要用lvs

那為什麼要用lvs呢？

ü 簡單一句話，當並發超過了Nginx上限，就可以使用LVS了。

ü 日1000-2000W PV或並發請求1萬以下都可以考慮用Nginx。

ü 大型門戶網站，電商網站需要用到LVS。

1.2 LVS介紹

LVS是linux Virtual Server的簡寫，意即Linux虛擬伺服器，是一個虛擬的伺服器集群系統，可以在UNIX/LINUX平台下實現負載均衡集群功能。該項目在1998年5月由章文嵩博士組織成立，是 中國國內最早出現的自由軟體項目之一 。

1.2.1 相關參考資料

LVS官網： http://www.linuxvirtualserver.org/index.html

相關中文資料

1.2.2 LVS內核模塊ip_vs介紹

ü LVS無需安裝

ü 安裝的是管理工具，第一種叫ipvsadm，第二種叫keepalive

ü ipvsadm是通過命令行管理，而keepalive讀取配置文件管理

ü 後面我們會用Shell腳本實現keepalive的功能

1.3 LVS集群搭建

1.3.1 集群環境說明

主機說明

web環境說明

web伺服器的搭建參照：

Tomcat：

http://www.cnblogs.com/clsn/p/7904611.html

Nginx：

http://www.cnblogs.com/clsn/p/7750615.html

1.3.2 安裝ipvsadm管理工具

安裝管理工具

查看當前LVS狀態，順便激活LVS內核模塊。

查看系統的LVS模塊。

1.3.3 LVS集群搭建

命令集 ：

檢查結果 ：

ipvsadm參數說明： (更多參照 man ipvsadm)

1.3.4 在web瀏覽器配置操作

命令集 ：

至此LVS集群配置完畢 ！

1.3.5 進行訪問測試

瀏覽器訪問：

命令行測試：

抓包查看結果：

arp解析查看：

1.4 負載均衡（LVS）相關名詞

術語說明：

1.4.1 LVS集群的工作模式--DR直接路由模式

DR模式是通過改寫請求報文的目標MAC地址，將請求發給真實伺服器的，而真實伺服器將響應後的處理結果直接返回給客戶端用戶。

DR技術可極大地提高集群系統的伸縮性吵拆昌。但要求調度器LB與真實伺服器RS都有一塊物理升扒網卡連在同一物理網段上，即必須在同一區域網環境。

DR直接路由模式說明：

a)通過在調度御攜器LB上修改數據包的目的MAC地址實現轉發。注意，源IP地址仍然是CIP，目的IP地址仍然是VIP。

b)請求的報文經過調度器，而RS響應處理後的報文無需經過調度器LB，因此，並發訪問量大時使用效率很高，比Nginx代理模式強於此處。

c)因DR模式是通過MAC地址的改寫機制實現轉發的，因此，所有RS節點和調度器LB只能在同一個區域網中。需要注意RS節點的VIP的綁定(lo:vip/32)和ARP抑制問題。

d)強調一下：RS節點的默認網關不需要是調度器LB的DIP，而應該直接是IDC機房分配的上級路由器的IP(這是RS帶有外網IP地址的情況)，理論上講，只要RS可以出網即可，不需要必須配置外網IP，但走自己的網關，那網關就成為瓶頸了。

e)由於DR模式的調度器僅進行了目的MAC地址的改寫，因此，調度器LB無法改變請求報文的目的埠。LVS DR模式的辦公室在二層數據鏈路層（MAC），NAT模式則工作在三層網路層（IP）和四層傳輸層（埠）。

f)當前，調度器LB支持幾乎所有UNIX、Linux系統，但不支持windows系統。真實伺服器RS節點可以是windows系統。

g)總之，DR模式效率很高，但是配置也較麻煩。因此，訪問量不是特別大的公司可以用haproxy/Nginx取代之。這符合運維的原則：簡單、易用、高效。日1000-2000W PV或並發請求1萬以下都可以考慮用haproxy/Nginx(LVS的NAT模式)

h)直接對外的訪問業務，例如web服務做RS節點，RS最好用公網IP地址。如果不直接對外的業務，例如：MySQL，存儲系統RS節點，最好只用內部IP地址。

DR的實現原理和數據包的改變

(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP

(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈

(c) IPVS比對數據包請求的服務是否為集群服務，若是，將請求報文中的源MAC地址修改為DIP的MAC地址，將目標MAC地址修改RIP的MAC地址，然後將數據包發至POSTROUTING鏈。 此時的源IP和目的IP均未修改，僅修改了源MAC地址為DIP的MAC地址，目標MAC地址為RIP的MAC地址

(d) 由於DS和RS在同一個網路中，所以是通過二層來傳輸。POSTROUTING鏈檢查目標MAC地址為RIP的MAC地址，那麼此時數據包將會發至Real Server。

(e) RS發現請求報文的MAC地址是自己的MAC地址，就接收此報文。處理完成之後，將響應報文通過lo介面傳送給eth0網卡然後向外發出。 此時的源IP地址為VIP，目標IP為CIP

(f) 響應報文最終送達至客戶端

1.5 在web端的操作有什麼含義？

1.5.1 RealServer為什麼要在lo介面上配置VIP？

既然要讓RS能夠處理目標地址為vip的IP包，首先必須要讓RS能接收到這個包。

在lo上配置vip能夠完成接收包並將結果返回client。

1.5.2 在eth0網卡上配置VIP可以嗎？

不可以，將VIP設置在eth0網卡上,會影響RS的arp請求,造成整體LVS集群arp緩存表紊亂，以至於整個負載均衡集群都不能正常工作。

1.5.3 為什麼要抑制ARP響應？

① arp協議說明

為了提高IP轉換MAC的效率，系統會將解析結果保存下來，這個結果叫做ARP緩存。

ARP緩存表是把雙刃劍

ARP廣播進行新的地址解析

測試命令

windows查看arp -a

③arp_announce和arp_ignore詳解

lvs在DR模式下需要關閉arp功能

arp_announce

對網路介面上，本地IP地址的發出的，ARP回應，作出相應級別的限制:

確定不同程度的限制,宣布對來自本地源IP地址發出Arp請求的介面

arp_ignore 定義

對目標地定義對目標地址為本地IP的ARP詢問不同的應答模式0

抑制RS端arp前的廣播情況

抑制RS端arp後廣播情況

1.6 LVS集群的工作模式

DR（Direct Routing）直接路由模式

NAT（Network Address Translation）

TUN（Tunneling）隧道模式

FULLNAT（Full Network Address Translation）

1.6.1 LVS集群的工作模式--NAT

通過網路地址轉換，調度器LB重寫請求報文的目標地址，根據預設的調度演算法，將請求分派給後端的真實伺服器，真實伺服器的響應報文處理之後，返回時必須要通過調度器，經過調度器時報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。

收費站模式---來去都要經過LB負載均衡器。

NAT方式的實現原理和數據包的改變

(a). 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP

(b). PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈

(c). IPVS比對數據包請求的服務是否為集群服務，若是，修改數據包的目標IP地址為後端伺服器IP，然後將數據包發至POSTROUTING鏈。 此時報文的源IP為CIP，目標IP為RIP

(d). POSTROUTING鏈通過選路，將數據包發送給Real Server

(e). Real Server比對發現目標為自己的IP，開始構建響應報文發回給Director Server。 此時報文的源IP為RIP，目標IP為CIP

(f). Director Server在響應客戶端前，此時會將源IP地址修改為自己的VIP地址，然後響應給客戶端。 此時報文的源IP為VIP，目標IP為CIP

LVS-NAT模型的特性

l RS應該使用私有地址，RS的網關必須指向DIP

l DIP和RIP必須在同一個網段內

l 請求和響應報文都需要經過Director Server，高負載場景中，Director Server易成為性能瓶頸

l 支持埠映射

l RS可以使用任意操作系統

l 缺陷：對Director Server壓力會比較大，請求和響應都需經過director server

1.6.2 LVS集群的工作模式--隧道模式TUN

採用NAT技術時，由於請求和響應的報文都必須經過調度器地址重寫，當客戶請求越來越多時，調度器的處理能力將成為瓶頸。

為了解決這個問題，調度器把請求的報文通過IP隧道(相當於ipip或ipsec )轉發至真實伺服器，而真實伺服器將響應處理後直接返回給客戶端用戶，這樣調度器就只處理請求的入站報文。

由於一般網路服務應答數據比請求報文大很多，採用 VS/TUN技術後，集群系統的最大吞吐量可以提高10倍。

VS/TUN工作流程,它的連接調度和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。

調度器根據各個伺服器的負載情況，連接數多少，動態地選擇一台伺服器，將原請求的報文封裝在另一個IP報文中，再將封裝後的IP報文轉發給選出的真實伺服器。

真實伺服器收到報文後，先將收到的報文解封獲得原來目標地址為VIP地址的報文, 伺服器發現VIP地址被配置在本地的IP隧道設備上(此處要人為配置)，所以就處理這個請求，然後根據路由表將響應報文直接返回給客戶。

TUN原理和數據包的改變

(a) 當用戶請求到達Director Server，此時請求的數據報文會先到內核空間的PREROUTING鏈。 此時報文的源IP為CIP，目標IP為VIP 。

(b) PREROUTING檢查發現數據包的目標IP是本機，將數據包送至INPUT鏈

(c) IPVS比對數據包請求的服務是否為集群服務，若是，在請求報文的首部再次封裝一層IP報文，封裝源IP為為DIP，目標IP為RIP。然後發至POSTROUTING鏈。 此時源IP為DIP，目標IP為RIP

(d) POSTROUTING鏈根據最新封裝的IP報文，將數據包發至RS（因為在外層封裝多了一層IP首部，所以可以理解為此時通過隧道傳輸）。 此時源IP為DIP，目標IP為RIP

(e) RS接收到報文後發現是自己的IP地址，就將報文接收下來，拆除掉最外層的IP後，會發現裡面還有一層IP首部，而且目標是自己的lo介面VIP，那麼此時RS開始處理此請求，處理完成之後，通過lo介面送給eth0網卡，然後向外傳遞。 此時的源IP地址為VIP，目標IP為CIP

(f) 響應報文最終送達至客戶端

LVS-Tun模型特性

1.6.3 LVS集群的工作模式--FULLNAT

LVS的DR和NAT模式要求RS和LVS在同一個vlan中，導致部署成本過高；TUNNEL模式雖然可以跨vlan，但RealServer上需要部署ipip隧道模塊等，網路拓撲上需要連通外網，較復雜，不易運維。

為了解決上述問題，開發出FULLNAT

該模式和NAT模式的區別是：數據包進入時，除了做DNAT，還做SNAT（用戶ip->內網ip）

從而實現LVS-RealServer間可以跨vlan通訊，RealServer只需要連接到內網。類比地鐵站多個閘機。

1.7 IPVS調度器實現了如下八種負載調度演算法：

a) 輪詢（Round Robin）RR

調度器通過"輪叫"調度演算法將外部請求按順序輪流分配到集群中的真實伺服器上，它均等地對待每一台伺服器，而不管伺服器上實際的連接數和系統負載。

b) 加權輪叫（Weighted Round Robin）WRR

調度器通過"加權輪叫"調度演算法根據真實伺服器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的伺服器處理更多的訪問流量。

調度器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。

c) 最少鏈接（Least Connections） LC

調度器通過"最少連接"調度演算法動態地將網路請求調度到已建立的鏈接數最少的伺服器上。

如果集群系統的真實伺服器具有相近的系統性能，採用"最小連接"調度演算法可以較好地均衡負載。

d) 加權最少鏈接（Weighted Least Connections） Wlc

在集群系統中的伺服器性能差異較大的情況下，調度器採用"加權最少鏈接"調度演算法優化負載均衡性能，具有較高權值的伺服器將承受較大比例的活動連接負載。調度器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。

e) 基於局部性的最少鏈接（Locality-Based Least Connections） Lblc

"基於局部性的最少鏈接" 調度演算法是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。

該演算法根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器 是可用的且沒有超載，將請求發送到該伺服器。

若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則用"最少鏈接"的原則選出一個可用的服務 器，將請求發送到該伺服器。

f) 帶復制的基於局部性最少鏈接（Locality-Based Least Connections with Replication）

"帶復制的基於局部性最少鏈接"調度演算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。

它與LBLC演算法的不同之處是它要維護從一個 目標IP地址到一組伺服器的映射，而LBLC演算法維護從一個目標IP地址到一台伺服器的映射。

該演算法根據請求的目標IP地址找出該目標IP地址對應的服務 器組，按"最小連接"原則從伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器。

若伺服器超載，則按"最小連接"原則從這個集群中選出一 台伺服器，將該伺服器加入到伺服器組中，將請求發送到該伺服器。

同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低復制的 程度。

g) 目標地址散列（Destination Hashing） Dh

"目標地址散列"調度演算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。

h) 源地址散列（Source Hashing）SH

"源地址散列"調度演算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器。

若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。

1.8 LVS+Keepalived方案實現

1.8.1 keepalived功能

1. 添加VIP

2. 添加LVS配置

3. 高可用（VIP漂移）

4. web伺服器 健康 檢查

1.8.2 在負載器安裝Keepalived軟體

# 檢查軟體是否安裝

1.8.3 修改配置文件

lb03上keepalied配置文件

lb04的Keepalied配置文件

keepalived persistence_timeout參數意義 LVS Persistence 參數的作用

http://blog.csdn.net/nimasike/article/details/53911363

1.8.4 啟動keepalived服務

1.8.5 在web伺服器上進行配置

注意：web伺服器上的配置為臨時生效，可以將其寫入rc.local文件，注意文件的執行許可權。

使用curl命令進行測試

至此keepalived+lvs配置完畢

1.9 常見LVS負載均衡高可用解決方案

Ø 開發類似keepalived的腳本，早期的辦法，現在不推薦使用。

Ø heartbeat+lvs+ldirectord腳本配置方案，復雜不易控制，不推薦使用

Ø RedHat工具piranha，一個web界面配置LVS。

Ø LVS-DR+keepalived方案，推薦最優方案，簡單、易用、高效。

1.9.1 lvs排錯思路

5. java高並發，如何解決，什麼方式解決，高並發

首先，為防止高並發帶來的系統壓力，或者高並發帶來的系統處理異常，數據紊亂，可以以下幾方面考慮：1、加鎖，這里的加鎖不是指加java的多線程的鎖，是指加應用所和資料庫鎖，應用鎖這邊通常是使用redis的setnx來做，其次加資料庫鎖，因為代碼中加了應用所，所以資料庫不建議加悲觀鎖（排他鎖），一般加樂觀鎖（通過設置一個seq_no來解決），這兩個鎖一般能解決了，最後做合理的流控，丟棄一部分請求也是必不可少的

6. 如何解決高並發問題

使用高性能的伺服器、高性能的資料庫、高效率的編程語言、還有高性能的Web容器，(對架構分層+負載均衡+集群)這幾個解決思路在一定程度上意味著更大的投入。

1、高並發：在同一個時間點，有大量的客戶來訪問我們的網站，如果訪問量過大，就可能造成網站癱瘓。

2、高流量：當網站大後，有大量的圖片，視頻，這樣就會對流量要求高，需要更多更大的帶寬。

3、大存儲：可能對數據保存和查詢出現問題。

解決方案：

1、提高硬體能力、增加系統伺服器。（當伺服器增加到某個程度的時候系統所能提供的並發訪問量幾乎不變，所以不能根本解決問題）

2、本地緩存：本地可以使用JDK自帶的Map、Guava Cache.分布式緩存：Redis、Memcache.本地緩存不適用於提高系統並發量，一般是用處用在程序中。

Spiring把已經初始過的變數放在一個Map中，下次再要使用這個變數的時候，先判斷Map中有沒有，這也就是系統中常見的單例模式的實現。

7. (二)微信紅包高並發系統設計方案（1）

2017年1月28日，正月初一，微信公布了用戶在除夕當天收發微信紅包的數量——142億個，而其收發峰值也已達到76萬每秒。百億級別的紅包，如何保障並發性能與資金安全？這給微信帶來了超級挑戰。面對挑戰，微信紅包在分析了業界「秒殺」系統解決方案的基礎上，採用了 SET化、旦拍悄請求排隊串列化、雙維度分庫表 等設計，形成了獨特的高並發、資金安全系統解決方案。實踐證明，該方案表現穩定，且實現了除夕夜系統零故障運行。概要：

一、業務 特點 ：海量的並發要求；嚴格的安全級別

二、技術 難點 ：並發請求搶鎖；事務級操作量級大；事務性要求嚴格

三、解決高並發問題 通常 使用的 方案 ：

1.使用內存操作替代實時的DB事務操作（優點：內存操作替代磁碟操作，提高了並發性能。）

2使用樂觀鎖替代悲觀鎖。應用於微信紅包系統，則會存在下面三個問題：滾並返回失敗；並發大失敗，小成功。DB壓力大。

四、微信 紅包 系統的高並發解決 方案 ：

1.系統垂直SET化，分而治之。

2.邏輯Server層將請求排隊，解決DB並發問題。

3.雙維度庫表設計，保障系統性能穩定

類似「秒殺」活動，群里發一個紅包=「秒殺」商品上架；搶紅包的動作=「秒殺」的查詢庫存；拆紅包=「秒殺」

同一時間有10萬個群里的用戶同時在發紅包，那就相當於同一時間有10萬個「秒殺」活動發布出去。10萬個微信群里的用戶同時搶紅包，將產生海量的並發請求。

微信紅包是微信支付的一個商戶，提供資金流轉服務。

用戶發紅包=購買一筆「錢」（在微信紅包這個商戶上），並且收貨地址是微信群。當用戶支付成功後，紅包「發貨」到微信群里，群里的用戶拆開紅包後，微信紅包提供了將「錢」轉入折紅包用戶微信零錢的服務。

資金交易業務比普通商品「秒殺」活動有更高的安全級別要求。普通的商品「秒殺」商品由商戶提供，庫存是商戶預設的，「秒殺」時可以允許存在「超賣」、「少賣」的情況。但是對於微信紅包，100元不可以被拆出101元；領取99元時，剩下的1元在24小時過期後要精確地退還給發紅包用戶，不能多也不能少。

在介紹微信紅包系統的技術難點之前，先介紹下簡單的、典型的商品「秒殺」系統的架構設計，如下圖所示。

該系統由接入層、邏輯服務層、存儲層與緩存構成。Proxy處理請求接入，Server承載主要的業務邏輯，Cache用於緩存庫存數量、DB則用於數據持久化。

一個「秒殺」活動，對應DB中的一條庫存記錄。當用戶進行商品「秒殺」時，系統的主要邏輯在於DB中庫存的操作上。一般來說，對DB的操作流程有以下三步：

a. 鎖庫存

b. 插入「秒殺」記錄

c. 更新庫存

a.鎖庫存是為了 避免 並發請求時出現「 超賣 」情況。同時要求這 三步操作 需要在 一個事務 中完成(難點:並發請求搶鎖)。

第一個事務完成提交之前這個鎖一直被第一個請求佔用，後面的所有請求需要 排隊等待 。同時參與「秒殺」的用戶越多，並發進DB的請求越多，請求 排隊越嚴重 。

紅包系統的設計上， 除了並發請求搶鎖之外，還有以下兩個突出難點 ：

首先，事務級操作量級大 。上文介紹微信紅包業務特點時提到，普遍情況下同時會有數以萬計的微信群在發紅包。這個業務特點映射到微信紅賀納包系統設計上，就是有數以萬計的「並發請求搶鎖」同時在進行。這使 得DB的壓力 比普通單個商品「庫存」被鎖要大很多倍。

其次，事務性要求嚴格 。微信紅包系統本質上是一個資金交易系統，相比普通商品「秒模渣殺」系統有更高的事務級別要求。

普通商品「秒殺」活動系統，解決高並發問題的方案，大體有以下幾種：

如圖2所示，將「實時扣庫存」的行為上移到 內存Cache中操作 ，內存Cache操作成功直接給Server返回成功，然後 非同步落DB持久化 。

優點：提高了並發性能。

缺點： 在內存操作 成功 但 DB持久化失敗 ，或者內存 Cache故障 的情況下，DB持久化會 丟數據 ，不適合微信紅包這種資金交易系統。

商品「秒殺」系統中，樂觀鎖的具體應用方法，是在DB的「庫存」記錄中維護一個版本號。在更新「庫存」的操作進行前，先去DB獲取當前版本號。在更新庫存的事務提交時，檢查該版本號是否已被其他事務修改。如果版本沒被修改，則提交事務，且版本號加1；如果版本號已經被其他事務修改，則回滾事務，並給上層報錯。

這個方案解決了「並發請求搶鎖」的問題，可以提高DB的並發處理能力。

應用於微信紅包系統，則會存在下面三個問題 ：

1.在並發搶到相同版本號的拆紅包請求中， 只有一個能拆紅包成功 ， 其他的請求 將事務回滾並返回失敗，給用戶 報錯 ，用戶體驗完全不可接受。

2.將會導致 第一時間 同時拆紅包的用戶有一部分直接 返回失敗 ，反而那些「 手慢 」的用戶，有可能因為 並發減小 後拆紅包 成功 ，這會帶來用戶體驗上的負面影響。

3.會帶來 大數量 的 無效 更新 請求 、事務 回滾 ，給 DB 造成不必要的額外 壓力 。

微信紅包用戶發一個紅包時，微信紅包系統生成一個ID作為這個紅包的唯一標識。接下來這個紅包的所有發紅包、搶紅包、拆紅包、查詢紅包詳情等操作，都根據這個ID關聯。

紅包系統根據這個紅包ID，按一定的規則（如按ID尾號取模等），垂直上下切分。切分後，一個垂直鏈條上的邏輯Server伺服器、DB統稱為一個SET。

各個SET之間相互獨立，互相解耦。並且同一個紅包ID的所有請求，包括發紅包、搶紅包、拆紅包、查詳情詳情等，垂直stick到同一個SET內處理，高度內聚。通過這樣的方式，系統將所有紅包請求這個巨大的洪流分散為多股小流，互不影響，分而治之，如下圖所示。

這個方案解決了同時存在海量事務級操作的問題，將海量化為小量。

紅包系統是資金交易系統，DB操作的事務性無法避免，所以會存在「並發搶鎖」問題。但是如果到達DB的事務操作（也即拆紅包行為）不是並發的，而是串列的，就不會存在「並發搶鎖」的問題了。

按這個思路，為了使拆紅包的事務操作串列地進入DB，只需要將請求在 Server層以FIFO （ 先進先出 ）的方式排隊，就可以達到這個效果。從而問題就集中到Server的FIFO隊列設計上。

微信紅包系統設計了分布式的、輕巧的、靈活的FIFO隊列方案。其具體實現如下：

首先，將同一個紅包ID的所有請求stick到同一台Server。

上面SET化方案已經介紹，同個紅包ID的所有請求，按紅包ID stick到同個SET中。不過在同個SET中，會存在多台Server伺服器同時連接同一台DB（基於容災、性能考慮，需要多台Server互備、均衡壓力）。

為了使同一個紅包ID的所有請求，stick到同一台Server伺服器上，在SET化的設計之外，微信紅包系統添加了一層基於紅包ID hash值的分流，如下圖所示。

其次，設計單機請求排隊方案。

將stick到同一台Server上的所有請求在被接收進程接收後，按紅包ID進行排隊。然後 串列地進入worker進程 （執行業務邏輯）進行處理，從而達到 排隊 的效果，如下圖所示。

最後，增加memcached控制並發。

為了 防止 Server中的請求隊列過載導致隊列被降級，從而所有請求 擁進DB ，系統增加了與Server伺服器同機部署的 memcached ，用於控制拆同一個紅包的 請求並發數 。

具體來說，利用memcached的 CAS原子累增操作 ，控制同時進入 DB執行拆紅包事務的請求數 ，超過預先設定數值則 直接拒絕服務 。用於 DB負載升高時的降級 體驗。

通過以上三個措施，系統有效地 控制了DB的「並發搶鎖」 情況。

紅包系統的分庫表規則，初期是根據 紅包ID的hash值 分為多庫多表。隨著紅包數據量逐漸增大，單表數據量也逐漸增加。而DB的性能與單表數據量有一定相關性。當單表數據量達到一定程度時，DB性能會有大幅度下降，影響系統性能穩定性。採用 冷熱分離 ，將歷史冷數據與當前熱數據分開存儲，可以解決這個問題。

系統在以 紅包ID維度 分庫表的基礎上，增加了以 循環天分表的維度 ，形成了 雙維度分庫表 的特色。

具體來說，就是分庫表規則像db_xx.t_y_dd設計，其中，xx/y是紅包ID的 hash值後三位 ，dd的取值范圍在01~31，代表一個月天數最多 31 天。

通過這種雙維度分庫表方式，解決了DB單表數據量膨脹導致性能下降的問題，保障了系統性能的穩定性。同時，在熱冷分離的問題上，又使得數據搬遷變得簡單而優雅。

綜上所述，微信紅包系統在解決高並發問題上的設計，主要採用了SET化分治、請求排隊、雙維度分庫表等方案，使得單組DB的並發性能 提升了8倍 左右，取得了很好的效果。

http://www.infoq.com/cn/articles/2017hongbao-weixin

8. 如何搭建億級並發的系統架構

想設計億萬級高並發架構，你要先知道高並發是什麼？

面對流量高峰，不同的企業是如何通過技術手段解決高並發難題的呢?

0、引言

軟體系統有三個追求：高性能、高並發、高可用，俗稱三高。三者既有區別也有聯系，門門道道很多，全面討論需要三天三夜，本篇討論高並發。

高並發（High Concurrency）。並發是操作系統領域的一個概念，指的是一段時間內多任務流交替執行的現象，後來這個概念被泛化，高並發用來指大流量、高請求的業務情景，比如春運搶票，電商雙十一，秒殺大促等場景。

很多程序員每天忙著搬磚，平時接觸不到高並發，哪天受不了跑去面試，還常常會被面試官犀利的高並發問題直接KO，其實吧，高並發系統也不高深，我保證任何一個智商在線的看過這篇文章後，都能戰勝恐懼，重拾生活的信心。

本文先介紹高並發系統的度量指標，然後講述高並發系統的設計思路，再梳理高並發的關鍵技術，最後結合作者的經驗做一些延伸探討。

1、高並發的度量指標

既然是高並發系統，那並發一定要高，不然就名不副實。並發的指標一般有QPS、TPS、IOPS，這幾個指標都是可歸為系統吞吐率，QPS越高系統能hold住的請求數越多，但光關注這幾個指標不夠，我們還需要關注RT，即響應時間，也就是從發出request到收到response的時延，這個指標跟吞吐往往是此消彼長的，我們追求的是一定時延下的高吞吐。

比如有100萬次請求，99萬次請求都在10毫秒內響應，其他次數10秒才響應，平均時延不高，但時延高的用戶受不了，所以，就有了TP90/TP99指標，這個指標不是求平均，而是把時延從小到大排序，取排名90%/99%的時延，這個指標越大，對慢請求越敏感。

除此之外，有時候，我們也會關注可用性指標，這可歸到穩定性。

一般而言，用戶感知友好的高並發系統，時延應該控制在250毫秒以內。

什麼樣的系統才能稱為高並發？這個不好回答，因為它取決於系統或者業務的類型。不過我可以告訴你一些眾所周知的指標，這樣能幫助你下次在跟人扯淡的時候稍微靠點兒譜，不至於貽笑大方。

通常，資料庫單機每秒也就能抗住幾千這個量級，而做邏輯處理的服務單台每秒抗幾萬、甚至幾十萬都有可能，而消息隊列等中間件單機每秒處理個幾萬沒問題，所以我們經常聽到每秒處理數百萬、數千萬的消息中間件集群，而像阿某的API網關，每日百億請求也有可能。

2、高並發的設計思路

高並發的設計思路有兩個方向：

• 垂直方向擴展，也叫豎向擴展

• 水平方向擴展，也叫橫向擴展

垂直方向：提升單機能力

提升單機處理能力又可分為硬體和軟體兩個方面：

• 硬體方向，很好理解，花錢升級機器，更多核更高主頻更大存儲空間更多帶寬

• 軟體方向，包括用各快的數據結構，改進架構，應用多線程、協程，以及上性能優化各種手段，但這玩意兒天花板低，就像提升個人產出一樣，996、007、最多24 X 7。

水平方向：分布式集群

為了解決分布式系統的復雜性問題，一般會用到架構分層和服務拆分，通過分層做隔離，通過微服務解耦。

這個理論上沒有上限，只要做好層次和服務劃分，加機器擴容就能滿足需求，但實際上並非如此，一方面分布式會增加系統復雜性，另一方面集群規模上去之後，也會引入一堆AIOps、服務發現、服務治理的新問題。

因為垂直向的限制，所以，我們通常更關注水平擴展，高並發系統的實施也主要圍繞水平方向展開。

3、高並發的關鍵技術

玩具式的網路服務程序，用戶可以直連伺服器，甚至不需要資料庫，直接寫磁碟文件。但春運購票系統顯然不能這么做，它肯定扛不住這個壓力，那一般的高並發系統是怎麼做呢？比如某寶這樣的正經系統是怎麼處理高並發的呢？

其實大的思路都差不多，層次劃分 + 功能劃分。可以把層次劃分理解為水平方向的劃分，而功能劃分理解為垂直方向的劃分。

首先，用戶不能直連伺服器，要做分布式就要解決「分」的問題，有多個服務實例就需要做負載均衡，有不同服務類型就需要服務發現。

集群化：負載均衡

負載均衡就是把負載（request）均衡分配到不同的服務實例，利用集群的能力去對抗高並發，負載均衡是服務集群化的實施要素，它分3種：

• DNS負載均衡，客戶端通過URL發起網路服務請求的時候，會去DNS伺服器做域名解釋，DNS會按一定的策略（比如就近策略）把URL轉換成IP地址，同一個URL會被解釋成不同的IP地址，這便是DNS負載均衡，它是一種粗粒度的負載均衡，它只用URL前半部分，因為DNS負載均衡一般採用就近原則，所以通常能降低時延，但DNS有cache，所以也會更新不及時的問題。

• 硬體負載均衡，通過布置特殊的負載均衡設備到機房做負載均衡，比如F5，這種設備貴，性能高，可以支撐每秒百萬並發，還能做一些安全防護，比如防火牆。

• 軟體負載均衡，根據工作在ISO 7層網路模型的層次，可分為四層負載均衡（比如章文嵩博士的LVS）和七層負載均衡（NGINX），軟體負載均衡配置靈活，擴展性強，阿某雲的SLB作為服務對外售賣，Nginx可以對URL的後半部做解釋承擔API網關的職責。

所以，完整的負載均衡鏈路是 client <-> DNS負載均衡 -> F5 -> LVS/SLB -> NGINX

不管選擇哪種LB策略，或者組合LB策略，邏輯上，我們都可以視為負載均衡層，通過添加負載均衡層，我們將負載均勻分散到了後面的服務集群，具備基礎的高並發能力，但這只是萬里長征第一步。

資料庫層面：分庫分表+讀寫分離

前面通過負載均衡解決了無狀態服務的水平擴展問題，但我們的系統不全是無狀態的，後面通常還有有狀態的資料庫，所以解決了前面的問題，存儲有可能成為系統的瓶頸，我們需要對有狀態存儲做分片路由。

資料庫的單機QPS一般不高，也就幾千，顯然滿足不了高並發的要求。

所以，我們需要做分庫分表 + 讀寫分離。

就是把一個庫分成多個庫，部署在多個資料庫服務上，主庫承載寫請求，從庫承載讀請求。從庫可以掛載多個，因為很多場景寫的請求遠少於讀的請求，這樣就把對單個庫的壓力降下來了。

如果寫的請求上升就繼續分庫分表，如果讀的請求上升就掛更多的從庫，但資料庫天生不是很適合高並發，而且資料庫對機器配置的要求一般很高，導致單位服務成本高，所以，這樣加機器抗壓力成本太高，還得另外想招。

讀多寫少：緩存

緩存的理論依據是局部性原理。

一般系統的寫入請求遠少於讀請求，針對寫少讀多的場景，很適合引入緩存集群。

在寫資料庫的時候同時寫一份數據到緩存集群里，然後用緩存集群來承載大部分的讀請求，因為緩存集群很容易做到高性能，所以，這樣的話，通過緩存集群，就可以用更少的機器資源承載更高的並發。

緩存的命中率一般能做到很高，而且速度很快，處理能力也強（單機很容易做到幾萬並發），是理想的解決方案。

CDN本質上就是緩存，被用戶大量訪問的靜態資源緩存在CDN中是目前的通用做法。

緩存也有很多需要謹慎處理的問題：

• 一致性問題：(a)更新db成功+更新cache失敗 -> 不一致 (b)更新db失敗+更新cache成功 -> 不一致 ©更新db成功+淘汰緩存失敗 -> 不一致

• 緩存穿透：查詢一定不存在的數據，會穿透緩存直接壓到資料庫，從而導致緩存失去作用，如果有人利用這個漏洞，大量查詢一定不存在的數據，會對資料庫造成壓力，甚至打掛資料庫。解決方案：布隆過濾器 或者 簡單的方案，查詢不存在的key，也把空結果寫入緩存（設置較短的過期淘汰時間），從而降低命失

• 緩存雪崩：如果大量緩存在一個時刻同時失效，則請求會轉到DB，則對DB形成壓迫，導致雪崩。簡單的解決方案是為緩存失效時間添加隨機值，降低同一時間點失效淘汰緩存數，避免集體失效事件發生

但緩存是針對讀，如果寫的壓力很大，怎麼辦？

高寫入：消息中間件

同理，通過跟主庫加機器，耗費的機器資源是很大的，這個就是資料庫系統的特點所決定的。

相同的資源下，資料庫系統太重太復雜，所以並發承載能力就在幾千/s的量級，所以此時你需要引入別的一些技術。

比如說消息中間件技術，也就是MQ集群，它是非常好的做寫請求非同步化處理，實現削峰填谷的效果。

消息隊列能做解耦，在只需要最終一致性的場景下，很適合用來配合做流控。

假如說，每秒是1萬次寫請求，其中比如5千次請求是必須請求過來立馬寫入資料庫中的，但是另外5千次寫請求是可以允許非同步化等待個幾十秒，甚至幾分鍾後才落入資料庫內的。

那麼此時完全可以引入消息中間件集群，把允許非同步化的每秒5千次請求寫入MQ，然後基於MQ做一個削峰填谷。比如就以平穩的1000/s的速度消費出來然後落入資料庫中即可，此時就會大幅度降低資料庫的寫入壓力。

業界有很多著名的消息中間件，比如ZeroMQ，rabbitMQ，kafka等。

消息隊列本身也跟緩存系統一樣，可以用很少的資源支撐很高的並發請求，用它來支撐部分允許非同步化的高並發寫入是很合適的，比使用資料庫直接支撐那部分高並發請求要減少很多的機器使用量。

避免擠兌：流控

再強大的系統，也怕流量短事件內集中爆發，就像銀行怕擠兌一樣，所以，高並發另一個必不可少的模塊就是流控。

流控的關鍵是流控演算法，有4種常見的流控演算法。

• 計數器演算法（固定窗口）：計數器演算法是使用計數器在周期內累加訪問次數，當達到設定的限流值時，觸發限流策略，下一個周期開始時，進行清零，重新計數，實現簡單。計數器演算法方式限流對於周期比較長的限流，存在很大的弊端，有嚴重的臨界問題。

• 滑動窗口演算法：將時間周期分為N個小周期，分別記錄每個小周期內訪問次數，並且根據時間滑動刪除過期的小周期，當滑動窗口的格子劃分的越多，那麼滑動窗口的滾動就越平滑，限流的統計就會越精確。此演算法可以很好的解決固定窗口演算法的臨界問題。

• 漏桶演算法：訪問請求到達時直接放入漏桶，如當前容量已達到上限（限流值），則進行丟棄（觸發限流策略）。漏桶以固定的速率進行釋放訪問請求（即請求通過），直到漏桶為空。分布式環境下實施難度高。

• 令牌桶演算法：程序以r（r=時間周期/限流值）的速度向令牌桶中增加令牌，直到令牌桶滿，請求到達時向令牌桶請求令牌，如獲取到令牌則通過請求，否則觸發限流策略。分布式環境下實施難度高。

4、高並發的實踐經驗

接入-邏輯-存儲是經典的互聯網後端分層，但隨著業務規模的提高，邏輯層的復雜度也上升了，所以，針對邏輯層的架構設計也出現很多新的技術和思路，常見的做法包括系統拆分，微服務。

除此之外，也有很多業界的優秀實踐，包括某信伺服器通過協程（無侵入，已開源libco）改造，極大的提高了系統的並發度和穩定性，另外，緩存預熱，預計算，批量讀寫（減少IO），池技術等也廣泛應用在實踐中，有效的提升了系統並發能力。

為了提升並發能力，邏輯後端對請求的處理，一般會用到生產者-消費者多線程模型，即I/O線程負責網路IO，協議編解碼，網路位元組流被解碼後產生的協議對象，會被包裝成task投入到task queue，然後worker線程會從該隊列取出task執行，有些系統會用多進程而非多線程，通過共享存儲，維護2個方向的shm queue，一個input q，一個output q，為了提高並發度，有時候會引入協程，協程是用戶線程態的多執行流，它的切換成本更低，通常有更好的調度效率。

另外，構建漏斗型業務或者系統，從客戶端請求到接入層，到邏輯層，到DB層，層層遞減，過濾掉請求，Fail Fast（盡早發現盡早過濾），嘴大屁眼小，哈哈。

漏斗型系統不僅僅是一個技術模型，它也可以是一個產品思維，配合產品的用戶分流，邏輯分離，可以構建全方位的立體模型。

5、小結

莫讓浮雲遮望眼，除去繁華識真顏。我們不能掌握了大方案，吹完了牛皮，而忽視了編程最本質的東西，掌握最基本最核心的編程能力，比如數據架構和演算法，設計，慣用法，培養技術的審美，也是很重要的，既要致高遠，又要盡精微。

9. 一般互聯網公司 如何進行高並發的架構

一、什麼是高並發
高並發（High Concurrency）是互聯網分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。
高並發相關常用的一些指標有響應時間（Response Time），吞吐量（Throughput），每秒查詢率QPS（Query Per Second），並發用戶數等。
響應時間：系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms，這個200ms就是系統的響應時間。
吞吐量：單位時間內處理的請求數量。
QPS：每秒響應請求數。在互聯網領域，這個指標和吞吐量區分的沒有這么明顯。
並發用戶數：同時承載正常使用系統功能的用戶數量。例如一個即時通訊系統，同時在線量一定程度上代表了系統的並發用戶數。
二、如何提升系統的並發能力
互聯網分布式架構設計，提高系統並發能力的方式，方法論上主要有兩種：垂直擴展（Scale Up）與水平擴展（Scale Out）。
垂直擴展：提升單機處理能力。垂直擴展的方式又有兩種：
（1）增強單機硬體性能，例如：增加CPU核數如32核，升級更好的網卡如萬兆，升級更好的硬碟如SSD，擴充硬碟容量如2T，擴充系統內存如128G；
（2）提升單機架構性能，例如：使用Cache來減少IO次數，使用非同步來增加單服務吞吐量，使用無鎖數據結構來減少響應時間；
在互聯網業務發展非常迅猛的早期，如果預算不是問題，強烈建議使用「增強單機硬體性能」的方式提升系統並發能力，因為這個階段，公司的戰略往往是發展業務搶時間，而「增強單機硬體性能」往往是最快的方法。
不管是提升單機硬體性能，還是提升單機架構性能，都有一個致命的不足：單機性能總是有極限的。所以互聯網分布式架構設計高並發終極解決方案還是水平擴展。
水平擴展：只要增加伺服器數量，就能線性擴充系統性能。水平擴展對系統架構設計是有要求的，如何在架構各層進行可水平擴展的設計，以及互聯網公司架構各層常見的水平擴展實踐，是本文重點討論的內容。
三、常見的互聯網分層架構
常見互聯網分布式架構如上，分為：
（1）客戶端層：典型調用方是瀏覽器browser或者手機應用APP
（2）反向代理層：系統入口，反向代理
（3）站點應用層：實現核心應用邏輯，返回html或者json
（4）服務層：如果實現了服務化，就有這一層
（5）數據-緩存層：緩存加速訪問存儲
（6）數據-資料庫層：資料庫固化數據存儲
整個系統各層次的水平擴展，又分別是如何實施的呢？
四、分層水平擴展架構實踐
反向代理層的水平擴展
反向代理層的水平擴展，是通過「DNS輪詢」實現的：dns-server對於一個域名配置了多個解析ip，每次DNS解析請求來訪問dns-server，會輪詢返回這些ip。
當nginx成為瓶頸的時候，只要增加伺服器數量，新增nginx服務的部署，增加一個外網ip，就能擴展反向代理層的性能，做到理論上的無限高並發。
站點層的水平擴展
站點層的水平擴展，是通過「nginx」實現的。通過修改nginx.conf，可以設置多個web後端。
當web後端成為瓶頸的時候，只要增加伺服器數量，新增web服務的部署，在nginx配置中配置上新的web後端，就能擴展站點層的性能，做到理論上的無限高並發。
服務層的水平擴展
服務層的水平擴展，是通過「服務連接池」實現的。
站點層通過RPC-client調用下游的服務層RPC-server時，RPC-client中的連接池會建立與下游服務多個連接，當服務成為瓶頸的時候，只要增加伺服器數量，新增服務部署，在RPC-client處建立新的下游服務連接，就能擴展服務層性能，做到理論上的無限高並發。如果需要優雅的進行服務層自動擴容，這里可能需要配置中心裡服務自動發現功能的支持。
數據層的水平擴展
在數據量很大的情況下，數據層（緩存，資料庫）涉及數據的水平擴展，將原本存儲在一台伺服器上的數據（緩存，資料庫）水平拆分到不同伺服器上去，以達到擴充系統性能的目的。
互聯網數據層常見的水平拆分方式有這么幾種，以資料庫為例：
按照范圍水平拆分
每一個數據服務，存儲一定范圍的數據，上圖為例：
這個方案的好處是：
（1）規則簡單，service只需判斷一下uid范圍就能路由到對應的存儲服務；
（2）數據均衡性較好；
（3）比較容易擴展，可以隨時加一個uid[2kw,3kw]的數據服務；
不足是：
（1）請求的負載不一定均衡，一般來說，新注冊的用戶會比老用戶更活躍，大range的服務請求壓力會更大；
按照哈希水平拆分
每一個資料庫，存儲某個key值hash後的部分數據，上圖為例：
這個方案的好處是：
（1）規則簡單，service只需對uid進行hash能路由到對應的存儲服務；
（2）數據均衡性較好；
（3）請求均勻性較好；
不足是：
（1）不容易擴展，擴展一個數據服務，hash方法改變時候，可能需要進行數據遷移；
這里需要注意的是，通過水平拆分來擴充系統性能，與主從同步讀寫分離來擴充資料庫性能的方式有本質的不同。
通過水平拆分擴展資料庫性能：
（1）每個伺服器上存儲的數據量是總量的1/n，所以單機的性能也會有提升；
（2）n個伺服器上的數據沒有交集，那個伺服器上數據的並集是數據的全集；
（3）數據水平拆分到了n個伺服器上，理論上讀性能擴充了n倍，寫性能也擴充了n倍（其實遠不止n倍，因為單機的數據量變為了原來的1/n）；
通過主從同步讀寫分離擴展資料庫性能：
（1）每個伺服器上存儲的數據量是和總量相同；
（2）n個伺服器上的數據都一樣，都是全集；
（3）理論上讀性能擴充了n倍，寫仍然是單點，寫性能不變；
緩存層的水平拆分和資料庫層的水平拆分類似，也是以范圍拆分和哈希拆分的方式居多，就不再展開。
五、總結
高並發（High Concurrency）是互聯網分布式系統架構設計中必須考慮的因素之一，它通常是指，通過設計保證系統能夠同時並行處理很多請求。
提高系統並發能力的方式，方法論上主要有兩種：垂直擴展（Scale Up）與水平擴展（Scale Out）。前者垂直擴展可以通過提升單機硬體性能，或者提升單機架構性能，來提高並發性，但單機性能總是有極限的，互聯網分布式架構設計高並發終極解決方案還是後者：水平擴展。
互聯網分層架構中，各層次水平擴展的實踐又有所不同：
（1）反向代理層可以通過「DNS輪詢」的方式來進行水平擴展；
（2）站點層可以通過nginx來進行水平擴展；
（3）服務層可以通過服務連接池來進行水平擴展；
（4）資料庫可以按照數據范圍，或者數據哈希的方式來進行水平擴展；
各層實施水平擴展後，能夠通過增加伺服器數量的方式來提升系統的性能，做到理論上的性能無限。