高并發Web 電商系統的設計與優化?

黃芝龍 徐莉莎 瞿少成

（華中師范大學物理科學與技術學院電子信息工程系 武漢 430079）

1 引言

隨著互聯網的快速發展和互聯網用戶量的急劇增加，高并發Web應用系統面臨更大的并發訪問壓力，容易出現網站響應時間過長，甚至會出現服務器壓力過大，導致系統崩潰等問題。12306 鐵路購票網站就是一個典型的高并發Web 應用。2012年春運期間，該網站日均近10 億次訪問，同時在線人數高達500 萬，如此高的負載與高并發量使網站訪問擁堵，頻繁出現錯誤，大量用戶買不到票［1］。

電商應用是一類有代表性的高并發Web 應用。目前針對高并發Web 應用系統性能低下的問題，解決的方案主要圍繞以下幾個方面:提高數據庫配置［2］、優化數據庫性能［3］、優化服務器參數配置［4］、優化網絡拓撲結構［5］和Web 容器的性能［6］，但上述方法限制了系統的擴展性，并加大了系統的開發和維護成本。本文從網站的系統架構入手，提出了一個高并發Web電商系統的解決方案，針對Web前端、后臺程序、數據庫和服務器4 個部分的處理給出了優化方案。在最近的100 次測試中承受住了近12 萬次的訪問，在解決高并發訪問的問題上取得了較好效果。

2 電商系統的特點、目標和流程分析

2.1 電商系統的特點

電商系統平時的訪問量不是特別大，因為用戶會在不同的時間段來選擇商品。但是，在年中和雙十一等購物狂歡節，同一時間訪問的用戶量過多，后臺服務器瞬間接收的請求量過大，巨大的訪問量會導致服務器崩潰等嚴重后果，降低用戶體驗的同時也會造成很大的損失。此時，電商系統的前端Web和后臺數據庫查詢都面臨高并發問題。

2.2 電商系統的設計目標

電商系統的設計目標主要有:1）滿足高并發訪問。這是電商系統的主要目標和首要解決的問題。2）高可用性。將停止服務時間降到最低甚至是無間斷服務。3）可擴展性。隨著訪問量的增加，系統具有良好的伸縮能力。4）高可靠性。經過優化的體系結構和合理的備份策略，使得電商系統具有穩定性，發生故障時能快速排查和恢復。

2.3 電商系統的流程

電商系統的流程為用戶注冊、用戶登錄、用戶查詢商品、添加購物車、提交訂單、付款、送貨等。具體流程是用戶在訪問商品信息時看到商品的價格、用途等屬性，將需要的商品加入購物車。購物車自動計算商品的總價，之后用戶想提交訂單時，若用戶是游客，則會提示用戶注冊；若用戶是電商系統的會員，則在用戶信息齊全的條件下可以進行支付。支付成功后接到支付成功的信息而更改狀態，商戶通知物流發貨，用戶收到貨物后確認收貨，交易完成。

3 電商系統的架構與負載均衡

為了解決高并發問題，最重要的是系統架構設計。本節首先介紹電商系統的功能模塊及瓶頸，然后介紹負載均衡技術，最后給出一個應對高并發的架構解決方案。

3.1 電商系統的功能及瓶頸

如圖1 所示，電商系統的主要功能包括商品模塊、用戶模塊、訂單模塊、反饋模塊和統計模塊。

商品模塊包括商品的添加、修改及商品信息的管理。用戶模塊包括用戶的注冊、登錄、權限的管理和用戶信息的維護。統計模塊包括統計商品信息、用戶信息和用戶點擊，購買的商品的統計信息。反饋模塊收集用戶對商品的評論，同時回答用戶的問題。訂單模塊是用戶添加購物車、下單、付款和物流等流程。

圖1 電商系統的功能模塊

在功能模塊中，用戶模塊一般不會成為高并發的瓶頸。系統規定只有注冊并登錄過的模塊才能參與購物，由于注冊和登錄的時間分散，一般不會造成高并發問題。反饋模塊和統計模塊也不是高并發問題產生的主要地方。商品模塊和支付模塊往往是高并發問題出現的主要位置，在購物狂歡節開始的短短幾分鐘內，會產生極大的并發流量，對系統造成巨大壓力，本文應用負載均衡和緩存等技術來減輕并發壓力。

3.2 電商系統的負載均衡方案

在電商系統中，尤其是在高并發、多節點的情況下，經常會出現服務器負載過重的情況，而單純的升級一臺服務器的配置已經不能滿足需求，必須設置多臺物理服務器，采用負載均衡技術構建系統。負載均衡好處是:1）將負載分擔在多臺服務器上，解決了高并發難題；2）增強了安全性；3）改善了可擴展性。

負載均衡可分為，1）前端Web服務器的負載均衡；2）邏輯層應用服務器負載均衡；3）后端數據庫和文件系統的負載均衡。

負載均衡實現的方法主要有:1）軟件負載均衡；2）硬件負載均衡；3）反向代理負載均衡；4）DNS負載均衡；5）基于NAT的負載均衡［7］。

本方案采用硬件和反向代理方式，用F5 負載均衡器和Nginx 反向代理服務器實現負載均衡。F5 由于其穩定性和技術成熟，應用于諸多大型網站［8］。F5 負載均衡器的優點有:1）管理簡單，方便操作和維護；2）容易部署和擴展；3）提高系統安全性；4）F5 具有緩存功能；5）開啟并使用了 F5 的SSL加速功能。Nginx 是一個高性能的HTTP 和反向代理服務器，是目前使用很廣泛的HTTP 軟負載均衡器，因高效的性能、穩定性和低系統資源的消耗而聞名于業界。許多大型門戶及商業網站都采用Nginx進行HTTP網站的數據分流。

3.3 電商系統的架構

電商系統的系統架構圖如圖2所示。

圖2 電商系統架構圖

根據三層邏輯結構，將Web 服務器、應用服務器和數據庫服務器三層分離。在Web 服務器群前端應用Nginx 反向代理服務器和F5 負載均衡器進行負載均衡，并在Nginx反向代理服務器和F5負載均衡器中進行緩存設置。系統使用服務器集群和分布式系統改善性能，將多臺Web服務器與多臺應用服務器相連，最后再連接分布式緩存服務器、文件服務器和數據庫服務器，其中數據庫服務器分為主從服務器，主服務器主要完成寫操作，從服務器完成讀操作。

4 電商系統的優化方案

在實際應用中，影響Web電商系統性能的因素有很多，本節主要從Web前端、后臺程序、數據庫以及服務器四個方面給出應對高并發的系統優化方案。

4.1 電商系統的Web前端優化方案

對于高并發電商網站，頁面質量是影響網站運行速度的重要原因之一［9］。首先要考慮的是頁面的大小，如果頁面設計的太大，在頁面加載時就會耗費大量的網絡帶寬，因此，頁面設計應盡可能地簡潔，以此減少不必要的網絡流量，進而有效的減緩高并發帶來的帶寬壓力。

另外，現在廣泛采用動態網頁，在加載這些頁面中的動態元素時，也會大大增加服務器的負擔，利用頁面壓縮技術和頁面靜態化技術可以有效解決該問題。電商系統中的首頁index.jsp 和支付頁面pay.jsp 是用戶最常訪問的兩個頁面。本方案在Web 服務器上部署了頁面靜態化服務。當用戶需要訪問首頁和支付頁面時，就不需要訪問應用服務器，訪問到的就是Web 服務器中已經靜態化的index.html 和pay.html。這樣可以大幅提高加載和訪問速度。頁面壓縮技術是指系統開啟Apache 的Gzip壓縮，將頁面壓縮后再傳送。此技術有效減少了頁面尺寸，節省了大量帶寬，緩解了高并發壓力。

4.2 電商系統的后臺程序優化方案

4.2.1 電商系統的緩存方案

緩存技術是解決高并發難題的一個重要手段。電商系統中的緩存技術是指將用戶要訪問的數據存在服務器內存中，當用戶要訪問這些數據時就不再訪問數據庫；而數據庫詢問是系統最耗時的工作，該技術大幅提升了訪問速度，減小了各臺服務器的負擔，緩解了高并發所帶來的擁堵。根據緩存的位置與內容不同，Web 緩存主要分為:1）前端頁面緩存；2）瀏覽器和客戶端緩存；3）后端數據庫的數據緩存［10］。

根據電商系統的系統架構圖，本方案利用CDN服務器、Nginx 服務器和F5 服務器提供緩存功能，將首頁index.html、支付頁面pay.html等經過處理的常用靜態化頁面放進緩存。在高并發的環境下，這樣可以有效地降低前臺Web 服務器集群的訪問壓力，同時也可以大大提高訪問效率。此外，為了減小數據庫訪問壓力，本方案在數據庫與應用服務器之間配置了redis 服務器。將用戶常用的查詢結果存在redis 緩存中，當用戶再次訪問時，先檢查緩存中是否有該查詢結果，如果有則直接從緩存中讀取，如果沒有才訪問數據庫，這樣可以減少數據庫服務器的訪問壓力。

當緩存區存滿時，要刪除舊的數據，添加新的數據，因此緩存的替換算法也是需要考慮的問題。在電商系統中，首頁中的商品信息經常是最常用的商品信息，被訪問量最多的數據要長時間留在緩存中，因此緩存的替換算法應用最近最少使用算法，最近最少使用算法原理如圖3所示。

圖3 最近最少使用算法

假如緩存區能存儲三個數據，在數據沒有存儲滿時，新數據會添加在緩存中。而在緩存存滿時，若再去更新緩存，則會刪掉最近最少使用的數據，更新后來有的數據，圖4為更新緩存數據的流程圖。

圖4 最近最少使用算法流程圖

應用最近最少使用算法，能將長時間無人查詢的記錄刪除，從而易于插入新的記錄。最近最少使用算法是將每個存儲值添加一個計數器的標簽，當這個值被查詢或是更新時就同時更新對應的計數器。因此，當緩存區滿時，計數器中最低值將會被優先替換掉。

4.2.2 多線程

高并發訪問是電商系統的基本需求，由于線程比進程更輕量，更少占有系統資源，切換代價更小，所以Web 應用服務器都采用多線程的方式響應并發用戶請求，因此本系統采用多線程編程。

例如用戶的下單流程，對于用戶提交的訂單請求，如果用戶點擊提交訂單，則系統會自動調用用戶信息和商品信息。調用之后驗證該商品是否有貨，配送區域是否符合要求等信息，而查驗的用戶信息是用戶是否為游客，用戶的id是否被禁用等信息。只有商品信息和用戶信息都驗證通過時，系統才認為該訂單提交成功。如果有一項不符合要求則認為這次訂單提交失敗。這兩部分驗證無論先后都對判斷結果沒有影響，并且這兩個判斷相互之間不影響，可是如果順序執行會降低效率，因此應用多線程來處理業務邏輯內能并發處理的事情，從而達到提高效率的目的。

如果未添加多線程，則程序按順序執行，該程序執行流程如圖5所示。其中，examineProduct（）方法會檢驗商品庫存，商品配送區域是否滿足需求，而examineUser（）方法則會驗證用戶的地址，權限等是否符合要求。因為這兩部分的驗證是互不影響的，所以將兩種方法并行處理，然后集中處理返回數據就會提高處理效率。

圖5 不添加多線程處理的流程圖

用戶提交訂單后，如果采用多線程的處理方式，就可以同時調用兩種方法，不過其內部處理的順序是不定的。多線程處理用戶提交訂單的流程圖如圖6 所示。其中用戶數據的獲取和商品數據的獲取是相對獨立的，對兩者用多線程處理后的結果進行判斷，可以減少處理時間。對于其他如付款和計算商品價格等流程也利用到多線程處理技術，提高系統的處理效率。多線程處理是調用jdk自帶的Thread對象來完成，并且一個Thread有一個完整的生命周期，在處理完成后，線程會自動調用destory進行銷毀，不會占用系統資源。

4.3 電商系統的數據庫優化方案

4.3.1 數據庫的讀寫分離

電商系統的用戶大部分是查看商品信息、瀏覽推薦的內容和查看資料等讀的內容。用戶注冊，下單量比查詢量少得多。由于數據庫壓力較大，所以系統部署了多個數據庫來分擔請求。但為了保持數據的高效性和一致性，僅設置了單個服務器進行寫入，其他的服務器則接受讀取的操作。其中負責寫入的服務器稱為主服務器，其在一定時間內將服務器中的數據同步到從服務器中。如圖7 所示，本系統的服務器利用的是master-slave 模式，將數據庫服務部署在多臺服務器上，一臺master服務器專門負責數據的寫入，而其他服務器則負責返回業務邏輯層讀取的數據。同時，現有master服務器還會定時對另一臺master服務器進行備份，如果主服務器宕機，就立即啟用備份服務器作為主服務器。

圖6 添加多線程處理的流程圖

圖7 數據庫讀寫分離

4.3.2 創建索引

當數據庫執行操作語句時，一般是根據條件進行全表掃描，每當遇到匹配項時，便將其添加到搜索結果內；在已經針對某唯一標識建立索引時，查詢時會優先到索引中定位符合條件的記錄數，從而得到所要結果。這樣可以減少查詢的記錄數從而大幅提升查詢速度。建立索引是為了提高數據庫查詢速度［11］，但是索引的建立和存儲也會占用一定空間，修改表內數據時索引也要進行相應的維護，進而影響到維護數據的速度，通常在有以下特征的字段上建立索引:需要頻繁和快速查詢的字段；建立了主鍵或外鍵的字段；定義了排序規則的字段；在檢索中需要組合到一起的字段。

4.3.3 數據庫操作語言的優化

對于關系型數據庫，通常需要寫數據庫操作語句來訪問所需數據，數據庫查詢效率是影響電商系統并發響應能力的一個重要因素，因此對數據庫操作語句的優化成為了不可少的一部分。對于ORACLE 數據庫中的SQL 優化原則，例如:將具有最大限制的條件放在where 語句的最后面，從而減少子句的訪問次數［12］；需要使用聯合查詢時，對from 后面的各個表應當選擇記錄條數最少的表來作為基礎表。本方案在研發過程中，利用這些原則對代碼中的SQL語句進行了優化，提高了數據庫的訪問速度。

4.4 電商系統的服務器優化方案

4.4.1 圖片服務器分離

對于電商系統的Web 服務器來說，不管是Apache 還是其他容器，圖片是最消耗資源的，因此有必要將圖片與頁面進行分離，部署獨立的圖片服務器，甚至是多臺服務器，從而減少高并發頁面訪問請求的服務器系統壓力，并且可以確保系統不會因為圖片問題而崩潰，在圖片服務器和應用服務器上，可以進行不同的配置優化。

4.4.2 服務器集群技術

對于單臺服務器的Web系統來說，在高并發的情況下，服務器的處理能力和I/O 能力肯定會成為服務的瓶頸，如果用戶的訪問超出了服務器能承受的范圍，就可能出現嚴重的后果甚至宕機。可以通過各種方法將單臺服務器的性能最優化，然而單臺服務器的性能有限，這時就必須考慮服務器集群技術了。服務器集群技術是將很多臺服務器集中起來進行同一服務，各臺服務器之間可以通過內部局域網進行相互通訊，在用戶看來就像是只有一臺服務器。集群可以應用多臺計算機來進行并行計算，從而獲得非常高的計算速度，也可以用多臺計算機做備份，如果其中某臺服務器出現故障，那么它所運行的服務就會被其他服務器替代，從而實現整個電商系統的高性能和高可靠性。

5 測試與應用

本方案分別對優化前和優化后的電商系統進行壓力測試，選取并發量最高的首頁index.jsp 作為測試頁面。測試指標包括響應時間、各種服務器的CPU 利用率和最高并發量。在3 萬并發訪問的情況下，優化前后各測試指標的對比見表1。

表1 優化前后各測試指標對比

由表1 的對比可知，電商系統在優化后各項指標都有明顯提升，其中響應時間減少約25%，各服務器的CPU 利用率降低45%左右。另外，在優化前，由于各服務器CPU 利用率已接近或達到90%，由此可估計系統最高并發量為3 萬左右；優化后經測試，在系統并發量為6 萬時，各服務器CPU 利用率接近90%，估計最高并發量為6 萬左右。另外，在不同并發數時，負載均衡器F5 和Nginx 對三臺Web服務器分配的session數見表2。

表2 不同并發數時的session分配情況

由表2 中的數據可知經過F5 和Nginx 的調度，負載是接近均衡分配的。

本電商系統經多方面測試后上線應用。在最近的一次大型購物活動中，該系統承受住12 萬人次的在線訪問，最高并發量為5 萬人，此時Web 應用服務器的CPU利用率約為70%，應用服務器CPU利用率約為55%，數據庫服務器CPU 利用率約為60%。系統的各部分功能運行正常，各個服務器的CPU 利用率不超過80%，響應時間在2s 左右，這也驗證了本方案可以有效解決高并發問題。

6 結語

本文設計了一個高并發Web電商系統，分析并提供了在高并發情況下的優化方案。首先分析了高并發Web電商系統的響應時間過長，服務器負載壓力過大和系統易崩潰的原因并提出了一個有效的優化方案。從負載均衡、Web前端、后臺程序、數據庫以及服務器幾個方面進行了優化。與其他高并發Web 應用系統相比，該系統具有可擴展性、高可用性和高可靠性等特點，并有效解決了Web電商系統的高并發難題。對類似高并發應用系統的優化具有重要意義。另外，隨著用戶量的持續增長，對電商系統的要求會越來越高，如何進一步優化電商系統還有待研究。