高并發(fā)Web 電商系統(tǒng)的設(shè)計(jì)與優(yōu)化?

黃芝龍 徐莉莎 瞿少成

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

1 引言

隨著互聯(lián)網(wǎng)的快速發(fā)展和互聯(lián)網(wǎng)用戶量的急劇增加，高并發(fā)Web應(yīng)用系統(tǒng)面臨更大的并發(fā)訪問壓力，容易出現(xiàn)網(wǎng)站響應(yīng)時(shí)間過長，甚至?xí)霈F(xiàn)服務(wù)器壓力過大，導(dǎo)致系統(tǒng)崩潰等問題。12306 鐵路購票網(wǎng)站就是一個(gè)典型的高并發(fā)Web 應(yīng)用。2012年春運(yùn)期間，該網(wǎng)站日均近10 億次訪問，同時(shí)在線人數(shù)高達(dá)500 萬，如此高的負(fù)載與高并發(fā)量使網(wǎng)站訪問擁堵，頻繁出現(xiàn)錯(cuò)誤，大量用戶買不到票［1］。

電商應(yīng)用是一類有代表性的高并發(fā)Web 應(yīng)用。目前針對(duì)高并發(fā)Web 應(yīng)用系統(tǒng)性能低下的問題，解決的方案主要圍繞以下幾個(gè)方面:提高數(shù)據(jù)庫配置［2］、優(yōu)化數(shù)據(jù)庫性能［3］、優(yōu)化服務(wù)器參數(shù)配置［4］、優(yōu)化網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)［5］和Web 容器的性能［6］，但上述方法限制了系統(tǒng)的擴(kuò)展性，并加大了系統(tǒng)的開發(fā)和維護(hù)成本。本文從網(wǎng)站的系統(tǒng)架構(gòu)入手，提出了一個(gè)高并發(fā)Web電商系統(tǒng)的解決方案，針對(duì)Web前端、后臺(tái)程序、數(shù)據(jù)庫和服務(wù)器4 個(gè)部分的處理給出了優(yōu)化方案。在最近的100 次測試中承受住了近12 萬次的訪問，在解決高并發(fā)訪問的問題上取得了較好效果。

2 電商系統(tǒng)的特點(diǎn)、目標(biāo)和流程分析

2.1 電商系統(tǒng)的特點(diǎn)

電商系統(tǒng)平時(shí)的訪問量不是特別大，因?yàn)橛脩魰?huì)在不同的時(shí)間段來選擇商品。但是，在年中和雙十一等購物狂歡節(jié)，同一時(shí)間訪問的用戶量過多，后臺(tái)服務(wù)器瞬間接收的請(qǐng)求量過大，巨大的訪問量會(huì)導(dǎo)致服務(wù)器崩潰等嚴(yán)重后果，降低用戶體驗(yàn)的同時(shí)也會(huì)造成很大的損失。此時(shí)，電商系統(tǒng)的前端Web和后臺(tái)數(shù)據(jù)庫查詢都面臨高并發(fā)問題。

2.2 電商系統(tǒng)的設(shè)計(jì)目標(biāo)

電商系統(tǒng)的設(shè)計(jì)目標(biāo)主要有:1）滿足高并發(fā)訪問。這是電商系統(tǒng)的主要目標(biāo)和首要解決的問題。2）高可用性。將停止服務(wù)時(shí)間降到最低甚至是無間斷服務(wù)。3）可擴(kuò)展性。隨著訪問量的增加，系統(tǒng)具有良好的伸縮能力。4）高可靠性。經(jīng)過優(yōu)化的體系結(jié)構(gòu)和合理的備份策略，使得電商系統(tǒng)具有穩(wěn)定性，發(fā)生故障時(shí)能快速排查和恢復(fù)。

2.3 電商系統(tǒng)的流程

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

3 電商系統(tǒng)的架構(gòu)與負(fù)載均衡

為了解決高并發(fā)問題，最重要的是系統(tǒng)架構(gòu)設(shè)計(jì)。本節(jié)首先介紹電商系統(tǒng)的功能模塊及瓶頸，然后介紹負(fù)載均衡技術(shù)，最后給出一個(gè)應(yīng)對(duì)高并發(fā)的架構(gòu)解決方案。

3.1 電商系統(tǒng)的功能及瓶頸

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

商品模塊包括商品的添加、修改及商品信息的管理。用戶模塊包括用戶的注冊、登錄、權(quán)限的管理和用戶信息的維護(hù)。統(tǒng)計(jì)模塊包括統(tǒng)計(jì)商品信息、用戶信息和用戶點(diǎn)擊，購買的商品的統(tǒng)計(jì)信息。反饋模塊收集用戶對(duì)商品的評(píng)論，同時(shí)回答用戶的問題。訂單模塊是用戶添加購物車、下單、付款和物流等流程。

圖1 電商系統(tǒng)的功能模塊

在功能模塊中，用戶模塊一般不會(huì)成為高并發(fā)的瓶頸。系統(tǒng)規(guī)定只有注冊并登錄過的模塊才能參與購物，由于注冊和登錄的時(shí)間分散，一般不會(huì)造成高并發(fā)問題。反饋模塊和統(tǒng)計(jì)模塊也不是高并發(fā)問題產(chǎn)生的主要地方。商品模塊和支付模塊往往是高并發(fā)問題出現(xiàn)的主要位置，在購物狂歡節(jié)開始的短短幾分鐘內(nèi)，會(huì)產(chǎn)生極大的并發(fā)流量，對(duì)系統(tǒng)造成巨大壓力，本文應(yīng)用負(fù)載均衡和緩存等技術(shù)來減輕并發(fā)壓力。

3.2 電商系統(tǒng)的負(fù)載均衡方案

在電商系統(tǒng)中，尤其是在高并發(fā)、多節(jié)點(diǎn)的情況下，經(jīng)常會(huì)出現(xiàn)服務(wù)器負(fù)載過重的情況，而單純的升級(jí)一臺(tái)服務(wù)器的配置已經(jīng)不能滿足需求，必須設(shè)置多臺(tái)物理服務(wù)器，采用負(fù)載均衡技術(shù)構(gòu)建系統(tǒng)。負(fù)載均衡好處是:1）將負(fù)載分擔(dān)在多臺(tái)服務(wù)器上，解決了高并發(fā)難題；2）增強(qiáng)了安全性；3）改善了可擴(kuò)展性。

負(fù)載均衡可分為，1）前端Web服務(wù)器的負(fù)載均衡；2）邏輯層應(yīng)用服務(wù)器負(fù)載均衡；3）后端數(shù)據(jù)庫和文件系統(tǒng)的負(fù)載均衡。

負(fù)載均衡實(shí)現(xiàn)的方法主要有:1）軟件負(fù)載均衡；2）硬件負(fù)載均衡；3）反向代理負(fù)載均衡；4）DNS負(fù)載均衡；5）基于NAT的負(fù)載均衡［7］。

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

3.3 電商系統(tǒng)的架構(gòu)

電商系統(tǒng)的系統(tǒng)架構(gòu)圖如圖2所示。

圖2 電商系統(tǒng)架構(gòu)圖

根據(jù)三層邏輯結(jié)構(gòu)，將Web 服務(wù)器、應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器三層分離。在Web 服務(wù)器群前端應(yīng)用Nginx 反向代理服務(wù)器和F5 負(fù)載均衡器進(jìn)行負(fù)載均衡，并在Nginx反向代理服務(wù)器和F5負(fù)載均衡器中進(jìn)行緩存設(shè)置。系統(tǒng)使用服務(wù)器集群和分布式系統(tǒng)改善性能，將多臺(tái)Web服務(wù)器與多臺(tái)應(yīng)用服務(wù)器相連，最后再連接分布式緩存服務(wù)器、文件服務(wù)器和數(shù)據(jù)庫服務(wù)器，其中數(shù)據(jù)庫服務(wù)器分為主從服務(wù)器，主服務(wù)器主要完成寫操作，從服務(wù)器完成讀操作。

4 電商系統(tǒng)的優(yōu)化方案

在實(shí)際應(yīng)用中，影響Web電商系統(tǒng)性能的因素有很多，本節(jié)主要從Web前端、后臺(tái)程序、數(shù)據(jù)庫以及服務(wù)器四個(gè)方面給出應(yīng)對(duì)高并發(fā)的系統(tǒng)優(yōu)化方案。

4.1 電商系統(tǒng)的Web前端優(yōu)化方案

對(duì)于高并發(fā)電商網(wǎng)站，頁面質(zhì)量是影響網(wǎng)站運(yùn)行速度的重要原因之一［9］。首先要考慮的是頁面的大小，如果頁面設(shè)計(jì)的太大，在頁面加載時(shí)就會(huì)耗費(fèi)大量的網(wǎng)絡(luò)帶寬，因此，頁面設(shè)計(jì)應(yīng)盡可能地簡潔，以此減少不必要的網(wǎng)絡(luò)流量，進(jìn)而有效的減緩高并發(fā)帶來的帶寬壓力。

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

4.2 電商系統(tǒng)的后臺(tái)程序優(yōu)化方案

4.2.1 電商系統(tǒng)的緩存方案

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

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

當(dāng)緩存區(qū)存滿時(shí)，要?jiǎng)h除舊的數(shù)據(jù)，添加新的數(shù)據(jù)，因此緩存的替換算法也是需要考慮的問題。在電商系統(tǒng)中，首頁中的商品信息經(jīng)常是最常用的商品信息，被訪問量最多的數(shù)據(jù)要長時(shí)間留在緩存中，因此緩存的替換算法應(yīng)用最近最少使用算法，最近最少使用算法原理如圖3所示。

圖3 最近最少使用算法

假如緩存區(qū)能存儲(chǔ)三個(gè)數(shù)據(jù)，在數(shù)據(jù)沒有存儲(chǔ)滿時(shí)，新數(shù)據(jù)會(huì)添加在緩存中。而在緩存存滿時(shí)，若再去更新緩存，則會(huì)刪掉最近最少使用的數(shù)據(jù)，更新后來有的數(shù)據(jù)，圖4為更新緩存數(shù)據(jù)的流程圖。

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

應(yīng)用最近最少使用算法，能將長時(shí)間無人查詢的記錄刪除，從而易于插入新的記錄。最近最少使用算法是將每個(gè)存儲(chǔ)值添加一個(gè)計(jì)數(shù)器的標(biāo)簽，當(dāng)這個(gè)值被查詢或是更新時(shí)就同時(shí)更新對(duì)應(yīng)的計(jì)數(shù)器。因此，當(dāng)緩存區(qū)滿時(shí)，計(jì)數(shù)器中最低值將會(huì)被優(yōu)先替換掉。

4.2.2 多線程

高并發(fā)訪問是電商系統(tǒng)的基本需求，由于線程比進(jìn)程更輕量，更少占有系統(tǒng)資源，切換代價(jià)更小，所以Web 應(yīng)用服務(wù)器都采用多線程的方式響應(yīng)并發(fā)用戶請(qǐng)求，因此本系統(tǒng)采用多線程編程。

例如用戶的下單流程，對(duì)于用戶提交的訂單請(qǐng)求，如果用戶點(diǎn)擊提交訂單，則系統(tǒng)會(huì)自動(dòng)調(diào)用用戶信息和商品信息。調(diào)用之后驗(yàn)證該商品是否有貨，配送區(qū)域是否符合要求等信息，而查驗(yàn)的用戶信息是用戶是否為游客，用戶的id是否被禁用等信息。只有商品信息和用戶信息都驗(yàn)證通過時(shí)，系統(tǒng)才認(rèn)為該訂單提交成功。如果有一項(xiàng)不符合要求則認(rèn)為這次訂單提交失敗。這兩部分驗(yàn)證無論先后都對(duì)判斷結(jié)果沒有影響，并且這兩個(gè)判斷相互之間不影響，可是如果順序執(zhí)行會(huì)降低效率，因此應(yīng)用多線程來處理業(yè)務(wù)邏輯內(nèi)能并發(fā)處理的事情，從而達(dá)到提高效率的目的。

如果未添加多線程，則程序按順序執(zhí)行，該程序執(zhí)行流程如圖5所示。其中，examineProduct（）方法會(huì)檢驗(yàn)商品庫存，商品配送區(qū)域是否滿足需求，而examineUser（）方法則會(huì)驗(yàn)證用戶的地址，權(quán)限等是否符合要求。因?yàn)檫@兩部分的驗(yàn)證是互不影響的，所以將兩種方法并行處理，然后集中處理返回?cái)?shù)據(jù)就會(huì)提高處理效率。

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

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

4.3 電商系統(tǒng)的數(shù)據(jù)庫優(yōu)化方案

4.3.1 數(shù)據(jù)庫的讀寫分離

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

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

圖7 數(shù)據(jù)庫讀寫分離

4.3.2 創(chuàng)建索引

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

4.3.3 數(shù)據(jù)庫操作語言的優(yōu)化

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

4.4 電商系統(tǒng)的服務(wù)器優(yōu)化方案

4.4.1 圖片服務(wù)器分離

對(duì)于電商系統(tǒng)的Web 服務(wù)器來說，不管是Apache 還是其他容器，圖片是最消耗資源的，因此有必要將圖片與頁面進(jìn)行分離，部署獨(dú)立的圖片服務(wù)器，甚至是多臺(tái)服務(wù)器，從而減少高并發(fā)頁面訪問請(qǐng)求的服務(wù)器系統(tǒng)壓力，并且可以確保系統(tǒng)不會(huì)因?yàn)閳D片問題而崩潰，在圖片服務(wù)器和應(yīng)用服務(wù)器上，可以進(jìn)行不同的配置優(yōu)化。

4.4.2 服務(wù)器集群技術(shù)

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

5 測試與應(yīng)用

本方案分別對(duì)優(yōu)化前和優(yōu)化后的電商系統(tǒng)進(jìn)行壓力測試，選取并發(fā)量最高的首頁index.jsp 作為測試頁面。測試指標(biāo)包括響應(yīng)時(shí)間、各種服務(wù)器的CPU 利用率和最高并發(fā)量。在3 萬并發(fā)訪問的情況下，優(yōu)化前后各測試指標(biāo)的對(duì)比見表1。

表1 優(yōu)化前后各測試指標(biāo)對(duì)比

由表1 的對(duì)比可知，電商系統(tǒng)在優(yōu)化后各項(xiàng)指標(biāo)都有明顯提升，其中響應(yīng)時(shí)間減少約25%，各服務(wù)器的CPU 利用率降低45%左右。另外，在優(yōu)化前，由于各服務(wù)器CPU 利用率已接近或達(dá)到90%，由此可估計(jì)系統(tǒng)最高并發(fā)量為3 萬左右；優(yōu)化后經(jīng)測試，在系統(tǒng)并發(fā)量為6 萬時(shí)，各服務(wù)器CPU 利用率接近90%，估計(jì)最高并發(fā)量為6 萬左右。另外，在不同并發(fā)數(shù)時(shí)，負(fù)載均衡器F5 和Nginx 對(duì)三臺(tái)Web服務(wù)器分配的session數(shù)見表2。

表2 不同并發(fā)數(shù)時(shí)的session分配情況

由表2 中的數(shù)據(jù)可知經(jīng)過F5 和Nginx 的調(diào)度，負(fù)載是接近均衡分配的。

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

6 結(jié)語

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