李寧 張軼昀

摘要：該文敘述了一種基于微服務(wù)架構(gòu)的分布式系統(tǒng)雙緩存解決方案，經(jīng)過實(shí)踐，該方案對分布式系統(tǒng)中大數(shù)據(jù)量參數(shù)查詢交易產(chǎn)生了良好的性能提升作用。

關(guān)鍵詞：微服務(wù);應(yīng)用緩存;公共緩存

中圖分類號：TP393? ? ? ?文獻(xiàn)標(biāo)識碼：A

文章編號：1009-3044（2020）36-0073-02

Abstract： This article describes a distributed system double cache solution based on microservice architecture. Through practice， the scheme has a good performance improvement on the query transaction of a large amount of data in a distributed system.

Key words： microservice; application cache; public cache

前后端分離的設(shè)計(jì)方案，有效提高了系統(tǒng)的開發(fā)效率，同時使得微服務(wù)架構(gòu)中的服務(wù)共享成為可能，目前正在成為主流系統(tǒng)開發(fā)架構(gòu)之一。本文基于銀行財(cái)會綜合管理系統(tǒng)，討論一種基于微服務(wù)架構(gòu)的分布式系統(tǒng)緩存解決方案[1]。

財(cái)會綜合管理系統(tǒng)由公共應(yīng)用、核算會計(jì)、管理會計(jì)、預(yù)算、估值、合同等十幾個子系統(tǒng)構(gòu)成。各個子系統(tǒng)均采用前后端分離架構(gòu)，SpringBoot開發(fā)，系統(tǒng)部署及數(shù)據(jù)庫均相互獨(dú)立。為使用戶對分布式無感，所有子系統(tǒng)進(jìn)行了統(tǒng)一的微服務(wù)發(fā)現(xiàn)中心地址配置。如圖1所示：前端發(fā)起的交易，通過統(tǒng)一網(wǎng)關(guān)，交易碼被轉(zhuǎn)換為微服務(wù)識別碼，經(jīng)微服務(wù)發(fā)現(xiàn)中心轉(zhuǎn)發(fā)到對應(yīng)的后臺服務(wù)器，后臺響應(yīng)報文原路反向回傳前端。系統(tǒng)主要使用了擴(kuò)展的Spring Cloud注解，Eureka服務(wù)注冊發(fā)現(xiàn)組件（服務(wù)注冊發(fā)現(xiàn)、服務(wù)續(xù)約、獲取注冊列表信息、服務(wù)下線、服務(wù)剔除）、Ribbon負(fù)載均衡組件、Feign面向接口調(diào)用組件、Zuul微服務(wù)應(yīng)用網(wǎng)關(guān)組件、Hystrix斷路器組件、Sleuth全鏈路采集組件、Redis緩存集群以及接口描述組件Swagger。應(yīng)用系統(tǒng)鏡像使用K8S部署。

除公共應(yīng)用外，其他子系統(tǒng)均有自己明確的業(yè)務(wù)屬性及交易特點(diǎn)。公共應(yīng)用為所有登錄子系統(tǒng)的用戶提供統(tǒng)一鑒權(quán)、會話保持、權(quán)限控制以及公共參數(shù)的取用。公共參數(shù)主要包括機(jī)構(gòu)數(shù)據(jù)、員工數(shù)據(jù)、用戶數(shù)據(jù)、財(cái)會產(chǎn)品、會計(jì)科目、匯率等適用于全平臺的基礎(chǔ)數(shù)據(jù)。各個子系統(tǒng)與公共應(yīng)用間存在大量的參數(shù)查詢交易。例如財(cái)會產(chǎn)品維護(hù)時，產(chǎn)品所屬部門、所屬科目數(shù)據(jù)在子系統(tǒng)僅保存ID號，查詢反顯時需要從公共應(yīng)用查詢中文名稱。

微服務(wù)架構(gòu)，有效提高了交易的可復(fù)用性，但同時增加了網(wǎng)絡(luò)損耗。由于財(cái)會系統(tǒng)數(shù)據(jù)量大，運(yùn)算復(fù)雜的特點(diǎn)，大數(shù)據(jù)量的參數(shù)訪問及需要控制用戶權(quán)限的數(shù)據(jù)查詢交易對整體系統(tǒng)的性能提出挑戰(zhàn)。為了改善系統(tǒng)效率，本系統(tǒng)設(shè)計(jì)并應(yīng)用了一種雙緩存策略。

所有子系統(tǒng)分別配置應(yīng)用緩存和公共緩存兩組Redis服務(wù)器集群[2]的訪問路徑，每組服務(wù)器內(nèi)部互為三-三主備。應(yīng)用緩存用于存放子系統(tǒng)私有數(shù)據(jù)的緩存信息，由子系統(tǒng)自行搭建。公共緩存由公共應(yīng)用系統(tǒng)搭建，并進(jìn)行寫入與更新，各子系統(tǒng)僅擁有讀權(quán)限。如圖2所示：子系統(tǒng)發(fā)起查詢交易時，先訪問應(yīng)用緩存，如未命中，則訪問公共緩存，仍未命中，才通過面向接口調(diào)用組件Feign，發(fā)起交易，經(jīng)微服務(wù)注冊中心中轉(zhuǎn)至公共應(yīng)用后臺服務(wù)。公共應(yīng)用響應(yīng)后，如該查詢交易已配置緩存加載，則會將本次查詢內(nèi)容加載入公共緩存，緩存Key通常使用邏輯數(shù)據(jù)庫表主鍵或主鍵對。系統(tǒng)使用SpringBoot注解類并進(jìn)行了擴(kuò)展，使得緩存加載配置僅需為指定的查詢交易添加@Cacheable注解，指定使用的緩存名以及緩存id。

由于為查詢類交易在緩存未被命中時添加緩存，緩存未被訪問時間超過閾值才清除，可能導(dǎo)致動賬類交易對數(shù)據(jù)的修改，在緩存失效前無法被重新加載。對于一些熱表數(shù)據(jù)，可能存在全天駐留緩存的情況，可能產(chǎn)生以下現(xiàn)象：用戶在公共應(yīng)用系統(tǒng)對機(jī)構(gòu)數(shù)據(jù)進(jìn)行了修改，但由于緩存中存在原數(shù)據(jù)，子系統(tǒng)查詢交易依然返回修改前數(shù)據(jù)，由此出現(xiàn)緩存臟讀現(xiàn)象。以上情況可以通過兩種方案解決：1）每日批量;2）實(shí)時刷新。

為提高緩存命中率，公共應(yīng)用系統(tǒng)每日批量于每天早上5點(diǎn)進(jìn)行參數(shù)預(yù)讀入，先清空緩存，自動發(fā)起機(jī)構(gòu)、員工、財(cái)會參數(shù)等常用數(shù)據(jù)的查詢交易，進(jìn)行緩存預(yù)加載。此舉不僅可以在系統(tǒng)正式服務(wù)時擁有良好的緩存命中率，且可解決緩存臟讀問題。經(jīng)實(shí)測，系統(tǒng)每日8點(diǎn)正式對外提供聯(lián)機(jī)服務(wù)，日常狀態(tài)下，雙緩存命中率可達(dá)到95%以上。此方法適用于可容忍T+1時效的系統(tǒng)數(shù)據(jù)。對于實(shí)時性要求很高的數(shù)據(jù)，如匯率，采用實(shí)時刷新方式。在修改了該數(shù)據(jù)的動賬交易結(jié)束后強(qiáng)制刷新緩存內(nèi)容。出于對整體性能的考慮，本系統(tǒng)對交易進(jìn)行分類，綜合運(yùn)用了兩種方法。

為系統(tǒng)添加雙緩存后，系統(tǒng)的整體性能有了顯著提高。以4000條用戶權(quán)限范圍內(nèi)的機(jī)構(gòu)數(shù)據(jù)下載為例（機(jī)構(gòu)視圖表數(shù)據(jù)量約50萬，每條記錄約50個屬性，大部分屬性需要子表翻譯），添加緩存前，測試環(huán)境響應(yīng)時間約2分鐘，添加緩存后同環(huán)境響應(yīng)時間降至20s以內(nèi)。

參考文獻(xiàn)：

[1] 黃向平，彭明田，楊永凱.基于內(nèi)存映射文件的高性能庫存緩存系統(tǒng)[J].電子技術(shù)應(yīng)用，2020，46（7）：113-117，126.

[2] 寧方美，賀雪梅，牟晉娟.SpringBoot集成Redis緩存技術(shù)在企業(yè)一卡通系統(tǒng)中的應(yīng)用[J]. 電子技術(shù)與軟件工程，2019（24）：133-134.

【通聯(lián)編輯：唐一東】