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

王 歡，李 民，鄧秀輝，焦 宇，余開朝

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

0 引言

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

1 相關(guān)研究

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

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

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

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

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

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

2.1 Dubbo框架

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

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

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

2.2 Redis緩存技術(shù)

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

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

2.3 Nginx負載均衡

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.2 Nginx負載均衡實現(xiàn)

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

4 性能測試

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

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

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

Fig.7 Query time comparison圖7 查詢時間比較

4.2 并發(fā)性能

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

5 結(jié)語

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

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