基于Redis緩存數(shù)據(jù)庫(kù)和Nginx負(fù)載均衡技術(shù)的購(gòu)物網(wǎng)站性能優(yōu)化

王 歡，李 民，鄧秀輝，焦 宇，余開(kāi)朝

（1.昆明理工大學(xué)機(jī)電工程學(xué)院，云南昆明 650500；2.華信咨詢?cè)O(shè)計(jì)研究院，浙江杭州 310000）

0 引言

隨著信息時(shí)代的到來(lái)，人們的生活已經(jīng)越來(lái)越離不開(kāi)互聯(lián)網(wǎng)。據(jù)第47 次《中國(guó)互聯(lián)網(wǎng)絡(luò)發(fā)展?fàn)顩r報(bào)告》顯示，截至2020 年12 月，我國(guó)網(wǎng)購(gòu)用戶規(guī)模已達(dá)7.82 億，較2020年3 月增長(zhǎng)7 215 萬(wàn)，占整體網(wǎng)民的79.1%。2020 年，我國(guó)網(wǎng)上零售額高達(dá)11.76 萬(wàn)億元，較2019 年增長(zhǎng)10.9%［1］。人們購(gòu)物習(xí)慣的轉(zhuǎn)變極大地促進(jìn)了線上經(jīng)濟(jì)的發(fā)展，對(duì)網(wǎng)絡(luò)購(gòu)物平臺(tái)提出了更高要求。開(kāi)展對(duì)現(xiàn)有電商平臺(tái)系統(tǒng)的研究與優(yōu)化至關(guān)重要，不僅能夠使購(gòu)物系統(tǒng)性能得到提升，改善消費(fèi)者的購(gòu)物體驗(yàn)，還能滿足企業(yè)長(zhǎng)期發(fā)展的需求，促進(jìn)社會(huì)經(jīng)濟(jì)良好發(fā)展。

1 相關(guān)研究

傳統(tǒng)的網(wǎng)上商城系統(tǒng)大多采用垂直應(yīng)用框架，在面對(duì)某一具體時(shí)刻眾多并發(fā)訪問(wèn)請(qǐng)求時(shí)，存在因難以承受巨大訪問(wèn)量而發(fā)生系統(tǒng)崩潰、用戶等待時(shí)間過(guò)長(zhǎng)、用戶體驗(yàn)差等問(wèn)題。隨著企業(yè)規(guī)模的擴(kuò)張以及業(yè)務(wù)種類和業(yè)務(wù)量的增加，傳統(tǒng)電商系統(tǒng)架構(gòu)早已不能滿足現(xiàn)代消費(fèi)需求。微服務(wù)架構(gòu)可以幫助解決企業(yè)面臨的種種開(kāi)發(fā)難題，許多學(xué)者進(jìn)行了相關(guān)研究。例如，F(xiàn)owler 等［2］提出微服務(wù)的概念；Lewis 等［3］基于微服務(wù)的概念首次提出微服務(wù)架構(gòu)體系，并指出通過(guò)該架構(gòu)可以更好地降低服務(wù)模塊間的耦合度。目前主流的微服務(wù)框架主要包括阿里的Dubbo 框架［4］和Spring社區(qū)的Spring Cloud 框架［5］。

針對(duì)高并發(fā)環(huán)境下數(shù)據(jù)查詢時(shí)間變長(zhǎng)，在實(shí)際項(xiàng)目中數(shù)據(jù)查詢效率低、系統(tǒng)運(yùn)行效能不佳的問(wèn)題，許多學(xué)者提出了解決辦法。例如，聶小雄［6］通過(guò)優(yōu)化傳統(tǒng)遺傳算法對(duì)數(shù)據(jù)庫(kù)進(jìn)行分庫(kù)分表與資源優(yōu)化，并重構(gòu)了系統(tǒng)架構(gòu)，有效提高了系統(tǒng)數(shù)據(jù)查詢性能；Peng 等［7］基于Redis 緩存數(shù)據(jù)庫(kù)的高可用性建立Dynamic cuckoo filter 系統(tǒng)，大大提高了海量數(shù)據(jù)的檢索速度。

為保證系統(tǒng)具有更高的并發(fā)性和可用性，面對(duì)請(qǐng)求同一服務(wù)的多個(gè)實(shí)例，如何縮短等待時(shí)間是一個(gè)亟需解決的問(wèn)題。負(fù)載均衡技術(shù)為解決這一難題提供了新的思路。例如，Alakeel［8］采用動(dòng)態(tài)負(fù)載均衡方法，對(duì)服務(wù)器集群中服務(wù)器節(jié)點(diǎn)的工作負(fù)載進(jìn)行重新分配，避免其他服務(wù)器節(jié)點(diǎn)出現(xiàn)空閑狀態(tài)，縮短了服務(wù)節(jié)點(diǎn)的工作響應(yīng)時(shí)間；張宇星［9］從Nginx 源碼著手，深入研究了其信號(hào)機(jī)制、反向代理功能和負(fù)載均衡，將C++、標(biāo)準(zhǔn)程序庫(kù)和模板轉(zhuǎn)變?yōu)閷?duì)Nginx 的負(fù)載轉(zhuǎn)發(fā)并進(jìn)行優(yōu)化改進(jìn)，測(cè)試證明改進(jìn)后的負(fù)載分發(fā)性能優(yōu)于改進(jìn)前；吳寶花［10］提出一種基于Nginx 加權(quán)輪詢負(fù)載均衡算法的后端服務(wù)器動(dòng)態(tài)負(fù)載均衡算法，可有效實(shí)現(xiàn)服務(wù)器資源分配的合理化。

在購(gòu)物商城系統(tǒng)優(yōu)化方面，也有不少學(xué)者進(jìn)行了研究。例如，王珂［11］針對(duì)某公司委托的電子商城開(kāi)發(fā)項(xiàng)目，運(yùn)用Spring、SpringMVC、Mybatis 框架，加入Nginx 輪詢技術(shù)提高了原購(gòu)物系統(tǒng)的并發(fā)性，數(shù)據(jù)庫(kù)采用一主一從的設(shè)計(jì)；徐光耀［12］針對(duì)擁有大規(guī)模用戶的電商企業(yè)面臨的問(wèn)題，設(shè)計(jì)了基于Dubbo 架構(gòu)的網(wǎng)上商城，與王珂的不同之處是其采用的是Dubbo 整合Spring、SpringMVC、Mybatis 框架，數(shù)據(jù)庫(kù)沒(méi)有主從設(shè)計(jì)；郭志偉［13］與徐光耀采用了同樣的系統(tǒng)架構(gòu)，但研究重點(diǎn)放在了以動(dòng)態(tài)調(diào)節(jié)權(quán)重的Nginx作為反向代理為基礎(chǔ)的系統(tǒng)性能優(yōu)化方面。

本文設(shè)計(jì)的購(gòu)物網(wǎng)站系統(tǒng)主要針對(duì)小型電商企業(yè)，尤其是創(chuàng)業(yè)初期資金有限、技術(shù)要求不高、顧客量較小的電商企業(yè)，與上述學(xué)者設(shè)計(jì)的不同點(diǎn)在于將Spring 框架替換為SpringBoot 框架，優(yōu)點(diǎn)是SpringBoot 框架不需要考慮版本兼容和框架整合問(wèn)題。本文系統(tǒng)采用Dubbo 整合Spring-Boot、SpringMVC、Mybatis 框架，采用“二主二從”的數(shù)據(jù)庫(kù)高可用性設(shè)計(jì)，同時(shí)采用Redis 數(shù)據(jù)緩存技術(shù)和Nginx 輪詢負(fù)載均衡技術(shù)提高系統(tǒng)并發(fā)性。

2 關(guān)鍵技術(shù)

2.1 Dubbo框架

Dubbo 是采用Java 編寫的開(kāi)源分布式框架［12］，其主要功能是使用高性能遠(yuǎn)程調(diào)用技術(shù)進(jìn)行服務(wù)的發(fā)布與應(yīng)用。該框架通過(guò)統(tǒng)一標(biāo)準(zhǔn)將復(fù)雜的網(wǎng)狀結(jié)構(gòu)梳理成便于管理的星型結(jié)構(gòu)，當(dāng)某一個(gè)服務(wù)節(jié)點(diǎn)出現(xiàn)問(wèn)題時(shí)，整個(gè)系統(tǒng)仍然可以正常運(yùn)行，較好地解決了各個(gè)服務(wù)器之間的通信問(wèn)題。Dubbo 框架作為微服務(wù)架構(gòu)之一，其每個(gè)服務(wù)都可以運(yùn)行在獨(dú)立的進(jìn)程中，具有高度的隔離性、自治性，這是傳統(tǒng)架構(gòu)模式不能實(shí)現(xiàn)的，也是本文采用Dubbo 框架降低系統(tǒng)耦合度、提高并發(fā)性的重要原因。

圖1 為Dubbo 框架的工作原理，其執(zhí)行流程簡(jiǎn)潔清晰［14］。第一步先啟動(dòng)加載配置文件，同時(shí)將自身所能提供的服務(wù)代碼調(diào)入內(nèi)存；第二步啟動(dòng)服務(wù)消費(fèi)者，向注冊(cè)中心提交所需服務(wù)信息，注冊(cè)中心返回服務(wù)提供者IP 和端口號(hào)給服務(wù)消費(fèi)者。監(jiān)控中心會(huì)監(jiān)控服務(wù)提供者和服務(wù)消費(fèi)者在一段時(shí)間內(nèi)在內(nèi)存中的調(diào)用次數(shù)和時(shí)間［15］。

Fig.1 Working principle of Dubbo framework圖1 Dubbo框架工作原理

2.2 Redis緩存技術(shù)

互聯(lián)網(wǎng)中的數(shù)據(jù)存儲(chǔ)和訪問(wèn)規(guī)模逐漸增大，緩存技術(shù)作為一種既經(jīng)濟(jì)又高效的解決方式被廣泛運(yùn)用于互聯(lián)網(wǎng)數(shù)據(jù)中心等系統(tǒng)中［16］。Redis 是當(dāng)前應(yīng)用最為廣泛的外部緩存產(chǎn)品，具有可使用數(shù)據(jù)類型豐富、運(yùn)行性能高、可擴(kuò)展性好、配置簡(jiǎn)單等特點(diǎn)。Redis 是基于內(nèi)存存儲(chǔ)的，所有操作均直接在內(nèi)存中進(jìn)行，可加快數(shù)據(jù)讀寫速度，有效緩解關(guān)系型數(shù)據(jù)庫(kù)的訪問(wèn)壓力，大大縮短訪問(wèn)和請(qǐng)求的響應(yīng)時(shí)間［17］。Redis 是單線程的，在收到任務(wù)后僅按照順序性、排他性、一次性的原則執(zhí)行某一隊(duì)列的一系列命令。Redis可實(shí)現(xiàn)一主機(jī)一從機(jī)或一主機(jī)多從機(jī)的主從復(fù)制機(jī)制，在進(jìn)行主從搭建時(shí)，常采用“哨兵”機(jī)制實(shí)現(xiàn)緩存數(shù)據(jù)的高可用性。Redis 緩存技術(shù)的持久化策略也是其被廣泛應(yīng)用的主要原因之一。Redis 按照指定配置，可定期將內(nèi)存中的數(shù)據(jù)以ROB 或AOF 的模式持久化到磁盤中，當(dāng)重新啟動(dòng)時(shí)，Redis 會(huì)首先根據(jù)文件中的配置讀取持久化文件實(shí)現(xiàn)數(shù)據(jù)恢復(fù)，可很好地避免因服務(wù)器崩潰給商城帶來(lái)的經(jīng)濟(jì)損失。

目前Redis 緩存技術(shù)應(yīng)用十分廣泛，例如蔡宇等［16］研究了運(yùn)行數(shù)據(jù)緩存的高效存儲(chǔ)模型、高可用管理等關(guān)鍵技術(shù)，提出了基于Redis 的數(shù)據(jù)平臺(tái)分布式緩存框架，經(jīng)實(shí)驗(yàn)證明該框架在可靠性、可擴(kuò)展性、讀寫性等方面滿足各類業(yè)務(wù)對(duì)數(shù)據(jù)的管理與訪問(wèn)要求；劉明［18］采用面對(duì)服務(wù)架構(gòu)的思想設(shè)計(jì)并實(shí)現(xiàn)了Yogo 電子商務(wù)系統(tǒng)，在服務(wù)器與數(shù)據(jù)庫(kù)之間采用Redis 緩存技術(shù)，大大提高了系統(tǒng)對(duì)請(qǐng)求的響應(yīng)效率；詹利群等［19］基于內(nèi)存Key-Value 結(jié)構(gòu)搭建Redis 數(shù)據(jù)庫(kù)集群，提出適合自動(dòng)氣象站資料調(diào)用的數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)模型，并通過(guò)實(shí)驗(yàn)證實(shí)了Redis 緩存技術(shù)具有較高的資料檢索效率。

2.3 Nginx負(fù)載均衡

Nginx 是一個(gè)具有強(qiáng)大性能的Web 和反向代理服務(wù)器，具有對(duì)網(wǎng)絡(luò)依賴性小、安裝和配置比較簡(jiǎn)單、可以承擔(dān)很高的負(fù)載壓力且性能穩(wěn)定等多種優(yōu)勢(shì)。Nginx 服務(wù)器最大的特點(diǎn)是可以提供負(fù)載均衡技術(shù)，即當(dāng)服務(wù)器接收到具體的服務(wù)請(qǐng)求時(shí)，可以按照既定策略將請(qǐng)求轉(zhuǎn)發(fā)至不同服務(wù)器，防止出現(xiàn)一臺(tái)服務(wù)器過(guò)載而其他服務(wù)器閑置的情況。既定策略包括輪詢、權(quán)重、ip_hash、url_hash 等［20］，其中輪詢即按照配置文件的順序依次訪問(wèn)服務(wù)器；權(quán)重即“能者多勞”，安排性能較優(yōu)的服務(wù)器處理較多的服務(wù)請(qǐng)求；ip_hash 即將用戶和某個(gè)特定的服務(wù)器進(jìn)行綁定，客服端請(qǐng)求ip 進(jìn)行hash，再通過(guò)hash 值選擇后端服務(wù)器，用于某些特定場(chǎng)景；url_hash 即通過(guò)請(qǐng)求url 進(jìn)行hash，再通過(guò)hash 值選擇后端服務(wù)器，可以提高后端緩存服務(wù)器的使用效率。ip_hash 和url_hash 具有使用局限性，當(dāng)后端服務(wù)器發(fā)生宕機(jī)時(shí)，不會(huì)自動(dòng)跳轉(zhuǎn)至其他服務(wù)器，嚴(yán)重影響用戶體驗(yàn)感。

目前Nginx 負(fù)載均衡技術(shù)應(yīng)用也十分廣泛，例如伍春生［21］應(yīng)用加權(quán)Nginx 負(fù)載均衡技術(shù)處理高速公路視頻云聯(lián)網(wǎng)平臺(tái)應(yīng)用層的請(qǐng)求，解決了該平臺(tái)訪問(wèn)能力較差的問(wèn)題；張博等［22］將Nginx 反向代理與負(fù)載均衡技術(shù)以及多級(jí)緩存、水平拓展服務(wù)器等技術(shù)引入到中小型電商網(wǎng)站中，通過(guò)測(cè)試工具檢驗(yàn)出優(yōu)化后的網(wǎng)站系統(tǒng)并發(fā)訪問(wèn)能力顯著提升。

3 購(gòu)物網(wǎng)站系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)

3.1 購(gòu)物網(wǎng)站系統(tǒng)工程搭建

3.1.1 開(kāi)發(fā)環(huán)境

本文設(shè)計(jì)的購(gòu)物網(wǎng)站在MacOS 環(huán)境下開(kāi)發(fā)，商城集群服務(wù)器、MySQL 數(shù)據(jù)庫(kù)、Redis 緩存、Zookeeper 等部署在VMware 虛擬機(jī)的Linux系統(tǒng)中。開(kāi)發(fā)工具如表1所示。

Table 1 Introduction to development tools表1 開(kāi)發(fā)工具介紹

3.1.2 網(wǎng)站系統(tǒng)搭建

購(gòu)物網(wǎng)站系統(tǒng)基于Dubbo 框架，同時(shí)整合SSM（Spring-Boot-SpringMVC-Mybatis）進(jìn)行架構(gòu)設(shè)計(jì)，主要由服務(wù)消費(fèi)者、服務(wù)提供者、緩存層和數(shù)據(jù)層4 層組成。架構(gòu)如圖2所示。

Fig.2 System architecture of a shopping website after reconstruction圖2 購(gòu)物網(wǎng)站系統(tǒng)架構(gòu)

網(wǎng)站中，服務(wù)消費(fèi)者負(fù)責(zé)頁(yè)面展示并與用戶進(jìn)行信息交互；服務(wù)提供者負(fù)責(zé)接收并處理服務(wù)消費(fèi)者傳來(lái)的用戶請(qǐng)求參數(shù)。為解決該購(gòu)物網(wǎng)站在某一時(shí)刻因并發(fā)量大而導(dǎo)致數(shù)據(jù)讀取速度慢的問(wèn)題，采用Redis 緩存技術(shù)設(shè)置緩存層，在服務(wù)層和數(shù)據(jù)層之間對(duì)熱點(diǎn)數(shù)據(jù)進(jìn)行緩存處理，以提高數(shù)據(jù)存儲(chǔ)速率和數(shù)據(jù)庫(kù)的可用性；數(shù)據(jù)層的數(shù)據(jù)庫(kù)設(shè)計(jì)采用開(kāi)源MyCat 數(shù)據(jù)庫(kù)消息中間件，對(duì)外統(tǒng)一提供數(shù)據(jù)服務(wù)。為緩解數(shù)據(jù)庫(kù)讀寫壓力，提高數(shù)據(jù)庫(kù)可用性，MySQL 數(shù)據(jù)庫(kù)采用兩主兩從設(shè)計(jì)，同時(shí)采用MyCat 對(duì)MySQL 進(jìn)行讀寫分離和雙機(jī)熱備。

該購(gòu)物網(wǎng)站系統(tǒng)主要通過(guò)Redis 的哨兵機(jī)制實(shí)現(xiàn)緩存數(shù)據(jù)的高可用性，同時(shí)對(duì)Redis 服務(wù)器集群節(jié)點(diǎn)進(jìn)行主從復(fù)制，從節(jié)點(diǎn)對(duì)主節(jié)點(diǎn)進(jìn)行復(fù)制備份，以實(shí)現(xiàn)數(shù)據(jù)同步。圖3 為Redis 數(shù)據(jù)庫(kù)集群的架構(gòu)示意圖，其分別由3 個(gè)主節(jié)點(diǎn)和3 個(gè)從節(jié)點(diǎn)構(gòu)成。為避免Redis 服務(wù)器出現(xiàn)宕機(jī)情況，哨兵通過(guò)心跳檢測(cè)機(jī)制向主機(jī)實(shí)時(shí)發(fā)出心跳檢測(cè)，連續(xù)3 次未收到主機(jī)回執(zhí)，則判斷該主機(jī)宕機(jī)，哨兵則通過(guò)推選機(jī)制選擇另一臺(tái)從機(jī)為新的主機(jī)，并將其他服務(wù)器改為當(dāng)前主機(jī)的從機(jī)。

在服務(wù)治理與監(jiān)控方面，本系統(tǒng)采用Dubbo+Zookeeper 應(yīng)用協(xié)調(diào)服務(wù)設(shè)計(jì)。以購(gòu)物車功能為例，當(dāng)服務(wù)提供者啟動(dòng)時(shí)，會(huì)將｛服務(wù)名稱：IP 端口｝寫入到Zookeeper 注冊(cè)中心，注冊(cè)中心收到消息后動(dòng)態(tài)維護(hù)服務(wù)列表數(shù)據(jù)。當(dāng)消費(fèi)者啟動(dòng)時(shí)，首先鏈接到注冊(cè)中心獲取到所有服務(wù)列表數(shù)據(jù)，并將該數(shù)據(jù)保存到消費(fèi)者本地中心用于后續(xù)訪問(wèn)。Zookeeper 注冊(cè)中心利用心跳檢測(cè)機(jī)制對(duì)后臺(tái)服務(wù)進(jìn)行監(jiān)控，判斷是否出現(xiàn)宕機(jī)。若出現(xiàn)宕機(jī)情況，注冊(cè)中心會(huì)及時(shí)更新服務(wù)列表消息，并將更新后的數(shù)據(jù)發(fā)送給消費(fèi)者。

Fig.3 Architecture of Redis database cluster圖3 Redis數(shù)據(jù)庫(kù)集群架構(gòu)

本文采用分布式搭建方式對(duì)該購(gòu)物網(wǎng)站系統(tǒng)進(jìn)行垂直拆分和水平拆分。垂直拆分是將購(gòu)物網(wǎng)站具體的服務(wù)模塊根據(jù)服務(wù)功能的不同拆分到不同服務(wù)器中，以提高整個(gè)系統(tǒng)的并發(fā)能力，具體拆分情況如圖4 所示。水平拆分是根據(jù)業(yè)務(wù)代碼的層級(jí)進(jìn)行項(xiàng)目功能的拆分，以便于后期系統(tǒng)的維護(hù)和升級(jí)，具體拆分情況如圖5所示。

3.2 Nginx負(fù)載均衡實(shí)現(xiàn)

為滿足購(gòu)物網(wǎng)站業(yè)務(wù)量和數(shù)據(jù)量不斷增多、系統(tǒng)功能不斷擴(kuò)展的需求，本文采用Nginx 負(fù)載均衡技術(shù)進(jìn)行服務(wù)器節(jié)點(diǎn)的水平擴(kuò)展，將海量訪問(wèn)請(qǐng)求分配到不同服務(wù)器節(jié)點(diǎn)上，使每臺(tái)服務(wù)器節(jié)點(diǎn)都能發(fā)揮作用，減少單節(jié)點(diǎn)服務(wù)器的訪問(wèn)壓力，提高系統(tǒng)吞吐量。采用輪詢方法將訪問(wèn)請(qǐng)求分配到商品管理系統(tǒng)服務(wù)器的3 個(gè)節(jié)點(diǎn)中。Nginx 負(fù)載均衡配置信息如圖6所示。

Fig.4 Project split vertically圖4 系統(tǒng)垂直拆分

Fig.5 Project level split圖5 系統(tǒng)水平拆分

Fig.6 Nginx load balancing configuration information圖6 Nginx負(fù)載均衡配置信息

4 性能測(cè)試

將該購(gòu)物商城系統(tǒng)部署在VMware 虛擬機(jī)的Linux 系統(tǒng)中，IP 地址分別為192.168.182.161，192.168.182.162，192.168.182.163，192.168.182.164，對(duì)應(yīng)的端口號(hào)為8081、8082、8083、8084。實(shí)驗(yàn)測(cè)試環(huán)境為MacOS10.15.5 系統(tǒng)、JDK1.8、MySQL8.0、Redis5.0、Tomcat8.5。

4.1 數(shù)據(jù)緩存性能

為驗(yàn)證該購(gòu)物網(wǎng)站系統(tǒng)的緩存性能，本文利用Post-Man 工具發(fā)出Get 請(qǐng)求，請(qǐng)求鏈接為http：//localhost：8091/item/cat/list。通過(guò)比較加入Redis 緩存數(shù)據(jù)庫(kù)前后該購(gòu)物網(wǎng)站系統(tǒng)的信息回顯速度，發(fā)現(xiàn)加入Redis 緩存數(shù)據(jù)的系統(tǒng)查詢時(shí)間為13ms，比原有系統(tǒng)直接從MySQL 數(shù)據(jù)庫(kù)中查詢快了63ms。具體結(jié)果如圖7所示。

Fig.7 Query time comparison圖7 查詢時(shí)間比較

4.2 并發(fā)性能

為驗(yàn)證加入Nginx 負(fù)載均衡技術(shù)后購(gòu)物網(wǎng)站系統(tǒng)的并發(fā)處理能力，運(yùn)用JMeter 工具進(jìn)行測(cè)試。設(shè)置用戶請(qǐng)求量分別為200、300、400、500，Ramp-Up Period（in seconds）為0，Loop Count 為1，通過(guò)比較系統(tǒng)響應(yīng)時(shí)間、吞吐量、錯(cuò)誤率等指標(biāo)衡量系統(tǒng)性能。由于網(wǎng)絡(luò)連接問(wèn)題會(huì)導(dǎo)致在實(shí)際測(cè)試過(guò)程中的數(shù)據(jù)出現(xiàn)波動(dòng)，本文采用3 次測(cè)試取平均值的方式處理數(shù)據(jù)結(jié)果。表2 為Samples（用戶請(qǐng)求數(shù)）分別為200、300、400、500 時(shí)，未搭載Nginx 負(fù)載均衡單節(jié)點(diǎn)服務(wù)器與搭載Nginx 負(fù)載均衡3 節(jié)點(diǎn)服務(wù)器的系統(tǒng)測(cè)試結(jié)果比較，評(píng)價(jià)項(xiàng)目包括平均響應(yīng)時(shí)間、50%用戶響應(yīng)時(shí)間、90%用戶響應(yīng)時(shí)間、錯(cuò)誤率、吞吐量等。如表2 所示，no 表示無(wú)Nginx 負(fù)載均衡單節(jié)點(diǎn)服務(wù)器系統(tǒng)，yes 表示Nginx 負(fù)載均衡3 節(jié)點(diǎn)服務(wù)器系統(tǒng)。通過(guò)分析發(fā)現(xiàn)，隨著并發(fā)量的增大，搭載Nginx 負(fù)載均衡3 節(jié)點(diǎn)服務(wù)器的系統(tǒng)平均響應(yīng)時(shí)間明顯縮短，二者吞吐量隨并發(fā)量的增加均開(kāi)始減小，但有Nginx 負(fù)載均衡的系統(tǒng)吞吐量仍高于無(wú)Nginx 負(fù)載均衡系統(tǒng)。當(dāng)用戶請(qǐng)求量分別為300、400、500 時(shí)，系統(tǒng)平均響應(yīng)時(shí)間分別縮短了47%、26%、11%，吞吐量分別提高了74%、23%、32%。在錯(cuò)誤率方面，在并發(fā)量較小時(shí)，二者的錯(cuò)誤率均為0，當(dāng)并發(fā)量為500 時(shí)，搭載Nginx 負(fù)載均衡的系統(tǒng)平均錯(cuò)誤率小于無(wú)Nginx負(fù)載均衡系統(tǒng)。

5 結(jié)語(yǔ)

本文針對(duì)傳統(tǒng)購(gòu)物網(wǎng)站系統(tǒng)存在的不足，設(shè)計(jì)并實(shí)現(xiàn)了以微服務(wù)技術(shù)為架構(gòu)，加入Redis 緩存技術(shù)、Nginx 負(fù)載均衡技術(shù)的購(gòu)物網(wǎng)站。通過(guò)實(shí)驗(yàn)證明了Redis 緩存數(shù)據(jù)庫(kù)可以提升數(shù)據(jù)的讀取速度，Ngnix 負(fù)載均衡技術(shù)可以緩解服務(wù)器的訪問(wèn)壓力，提高系統(tǒng)并發(fā)能力，以便企業(yè)更好地應(yīng)對(duì)未來(lái)業(yè)務(wù)量增大帶來(lái)的問(wèn)題，提升經(jīng)濟(jì)效益。由于實(shí)驗(yàn)條件限制，數(shù)據(jù)庫(kù)主備設(shè)計(jì)僅擴(kuò)展到“二主二從”，距離滿足現(xiàn)實(shí)情況還有一定差距，但設(shè)計(jì)思想有一定的參考價(jià)值。由于本文研究重點(diǎn)為提升購(gòu)物網(wǎng)站系統(tǒng)的整體并發(fā)性，未考慮到大型促銷活動(dòng)，如“雙十一”等瞬間高并發(fā)請(qǐng)求給系統(tǒng)帶來(lái)的訪問(wèn)壓力，后續(xù)需在流量削峰方面作進(jìn)一步研究，擴(kuò)大該系統(tǒng)的應(yīng)用范圍。

Table 2 Multi node server test result with or without Nginx load balancing表2 有無(wú)Nginx負(fù)載均衡的多節(jié)點(diǎn)服務(wù)器測(cè)試結(jié)果