99热婷婷-99热网-99热网址-99热亚洲-国产精品v欧美精品∨日韩-国产精品videosse

眾所周知，分布式緩存是提升系統(tǒng)性能的銀彈，在大型分布式系統(tǒng)中使用頻率很高，對提升系統(tǒng)性能起著不可或缺的作用。近些年，分布式和集中式系統(tǒng)在整個IT行業(yè)大行其道，CRM基于高內(nèi)聚、低耦合的原則，逐漸演化為多中心分布式部署架構(gòu)。由此產(chǎn)生的中心間交互，在日益復(fù)雜的業(yè)務(wù)催化下，對PAAS平臺組件提出了更高的要求。不出意外，分布式緩存在業(yè)務(wù)生產(chǎn)中也面臨著諸多挑戰(zhàn)。

02 理想與現(xiàn)實的沖突

業(yè)務(wù)系統(tǒng)引入分布式緩存的初衷是為了提升系統(tǒng)性能，為用戶帶來快速、簡潔、靈活的操作體驗。為了盡快享受到分布式緩存帶來的好處，加速系統(tǒng)建設(shè)中分布式緩存的引入，采用惰性加載（讀取時觸發(fā)）模式——當緩存中沒有數(shù)據(jù)時，先從DB讀取，再加載到分布式緩存中。這種模式在很多系統(tǒng)建設(shè)初期很常見。

隨著時間的推移和業(yè)務(wù)需求的變化，人們會發(fā)現(xiàn)單純使用分布式緩存已經(jīng)不能滿足復(fù)雜業(yè)務(wù)的需求，因此會加入應(yīng)用服務(wù)器作為二級緩存，減少應(yīng)用與遠程分布式緩存的交互次數(shù)，經(jīng)過調(diào)整后，系統(tǒng)的緩存使用架構(gòu)變成了兩級模型。

在這個架構(gòu)模式下，我們發(fā)現(xiàn)在很多業(yè)務(wù)場景，比如商品查詢、品銷關(guān)系查詢等，系統(tǒng)性能得到了很大的提升。然而這也帶來了一些緩存使用上的問題：

1）緩存數(shù)據(jù)不透明：無論是遠程分布式緩存還是本地二級緩存都是巨大的黑盒子，目前還沒有可靠的可視化工具可以清晰的查看緩存的內(nèi)容。尤其是緩存key/value在應(yīng)用層處理之后，運維人員沒有辦法通過簡單的標識來查看緩存key對應(yīng)的value。

2）多中心緩存刷新問題：在多中心架構(gòu)下，多個中心可能需要同一套配置數(shù)據(jù)，那么在刷新的時候，如何保證每個中心的緩存都能被刷新？如何保證錯過的刷新能被及時發(fā)現(xiàn)并靈活處理？

3）緩存數(shù)據(jù)一致性問題：如何保證遠程分布式緩存、本地二級緩存、DB的數(shù)據(jù)一致性？如何及時發(fā)現(xiàn)不一致情況并進行預(yù)警。

在分布式緩存給業(yè)務(wù)系統(tǒng)帶來的理想性能提升面前，使用過程中還存在一些技術(shù)與業(yè)務(wù)融合的痛點，運維過程中也面臨一些比較實際的問題，解決理想與現(xiàn)實的沖突也是一大挑戰(zhàn)，我們該怎么辦？

03 直面挑戰(zhàn)，給出答案

日常生活中，我們經(jīng)常會遇到房屋設(shè)施因時間、個人需求、人口規(guī)模等變化而變得陳舊過時的情況，需要時不時地進行整理或翻新。有趣的是，實際的 CRM 緩存優(yōu)化過程與翻新舊房的過程類似。

圍繞“一個愿景、兩個目標、四項提升、七項舉措”，各CRM中心緩存模塊的重構(gòu)優(yōu)化分為兩大部分：一是主體改造部分，二是微調(diào)打磨部分。

04 主體改造-緩存刷新重構(gòu)改造前期-現(xiàn)有功能拆解

改造前期，梳理原有功能邏輯的過程需要對現(xiàn)有業(yè)務(wù)支撐強度有一定的了解。拆解原有頁面所有組件，包括按鈕、表單等，記錄每個按鈕的功能。拆解是一個機械的過程，不需要任何額外的判斷。所有需要優(yōu)化的部分都會在后面的步驟中決定出來。這樣方便后期區(qū)分哪些業(yè)務(wù)功能需要保留，哪些邏輯需要重組。

設(shè)計階段：確定整體風(fēng)格，進行總體設(shè)計

經(jīng)過拆解梳理現(xiàn)有功能，我們已經(jīng)知道系統(tǒng)中現(xiàn)有的功能，發(fā)現(xiàn)原來舊版的頁面功能比較混亂，有些邏輯冗余，有些功能存在缺陷，經(jīng)過梳理，我們按照業(yè)務(wù)維度進行整理歸納，確定了整體優(yōu)化方案，制定了統(tǒng)一刷新的整體事項及方案：

重新設(shè)計的統(tǒng)一刷新架構(gòu)如圖所示

優(yōu)化重構(gòu)第一步：拆除工作-消除不必要的冗余邏輯

經(jīng)過功能分解和專項設(shè)計階段，發(fā)現(xiàn)緩存刷新口徑有十余個，分散在各個中心，如此多的口徑和頁面，難免讓運維人員感到無所適從，這就需要對各個中心分散的緩存管理功能進行取精去糟粕，剔除分散的頁面和冗余的業(yè)務(wù)邏輯，將各個中心保留的頁面功能整合到門戶統(tǒng)一的管理頁面中。

第二步：隱藏構(gòu)建項目-統(tǒng)一緩存刷新機制及統(tǒng)一zk命令發(fā)布監(jiān)控模式

在分布式架構(gòu)中，對于要求性能更高、可用性更好的數(shù)據(jù)，緩存往往會設(shè)計成多級結(jié)構(gòu)。如果有數(shù)據(jù)更新，需要考慮如何保證各個主機節(jié)點進程中緩存數(shù)據(jù)的一致性。為了保證緩存刷新的一致性，我們采用一種新的刷新模式，通過刷新頁面的方式發(fā)起緩存刷新請求。應(yīng)用收到緩存刷新請求后，生成緩存刷新命令修修補補，并將命令寫入ZK節(jié)點。各個中心后端應(yīng)用都有zookpper提供的API用于實時監(jiān)控。當監(jiān)控到ZK節(jié)點數(shù)據(jù)發(fā)生變化時，各個應(yīng)用獲取節(jié)點命令，解析命令，并調(diào)用命令緩存刷新API，刷新本地應(yīng)用節(jié)點進程內(nèi)的緩存數(shù)據(jù)。

步驟3：基礎(chǔ)構(gòu)建項目-根據(jù)用戶角色提供刷新接口

緩存操作涉及的角色有版本發(fā)布、故障運維人員、規(guī)范數(shù)據(jù)操作等，不同角色的操作習(xí)慣有所不同，為了使緩存管理功能更加強大，我們針對不同角色提供了個性化的刷新接口和邏輯。

1、對于運維或者數(shù)據(jù)操作人員，我們提供查看緩存數(shù)據(jù)的接口，可以通過key值進行刷新。

2、對于版本發(fā)布者，我們只需要提供表和字段對應(yīng)的KV關(guān)系刷新接口即可。

步驟4：通用裝修-緩存可視化、緩存檢查、緩存操作日志

要解決緩存可視化問題網(wǎng)校頭條，必須將緩存內(nèi)容以結(jié)構(gòu)化的方式展現(xiàn)出來。在業(yè)務(wù)系統(tǒng)中，我們緩存的數(shù)據(jù)可能是單一的KV映射值，也可能是復(fù)雜的業(yè)務(wù)對象數(shù)據(jù)。因此，為了給運維人員提供可視化的展現(xiàn)，我們需要在內(nèi)部對key和value進行封裝，然后提供給運維人員。以某產(chǎn)品的配置數(shù)據(jù)緩存結(jié)構(gòu)為例，其結(jié)構(gòu)是由不同的分表緩存對象構(gòu)成的。

完成結(jié)構(gòu)化的梳理后，增加頁面緩存數(shù)據(jù)的結(jié)構(gòu)化展示，使得結(jié)果更加清晰直觀。

在完成緩存刷新動作之后，無法檢查操作是否成功，以及緩存的數(shù)據(jù)狀態(tài)。為了解決這個問題，還需要一個可視化的檢查功能。操作完成后可以在頁面發(fā)起請求，后端根據(jù)key值循環(huán)調(diào)用各個應(yīng)用節(jié)點獲取key對應(yīng)的緩存值進行審計，對比本地緩存是否與數(shù)據(jù)庫一致，標記數(shù)據(jù)不一致的應(yīng)用節(jié)點，同時組裝本地緩存對象的數(shù)據(jù)值。

將檢測結(jié)果可視化，并對比差異數(shù)據(jù)，效果如下圖所示：

檢查

數(shù)據(jù)差異對比

05 微調(diào)完善-改善緩存引擎的使用

舊房裝修完成后，基本已經(jīng)達到入住標準，但業(yè)主在裝修前保留的家具等物品需要妥善整理擺放，才能入住。俗話說“三分雕琢，七分打磨”，在完成主要功能的優(yōu)化重構(gòu)后，常用的核心功能也需要細化打磨，提高緩存使用效率：

原子能力細化與封裝

對于部分緩存的API進行了原子性的封裝，并針對每個API給出了詳細的描述，以保證其優(yōu)秀性、規(guī)范性，也為后續(xù)研發(fā)人員提供了方便。

緩存補償與緩存攔截機制

為了防止系統(tǒng)產(chǎn)生臟數(shù)據(jù)，需要對異常數(shù)據(jù)進行防范和清洗。對于緩存數(shù)據(jù)缺失值修修補補，需要有補償機制；對于異常值，增加緩存校驗攔截機制。

獨創(chuàng)功能-灰度制作緩存無縫切換

CRM灰度環(huán)境的應(yīng)用，可以讓部分用戶進行版本升級內(nèi)測，很大程度上規(guī)避了因為版本問題導(dǎo)致生產(chǎn)失敗的風(fēng)險。在架構(gòu)設(shè)計時，對灰度和生產(chǎn)環(huán)境的緩存做了隔離。但是這樣的做法也帶來一些問題，當灰度驗證的業(yè)務(wù)數(shù)據(jù)沒有及時完成，灰度切換到生產(chǎn)環(huán)境后，生產(chǎn)中無法讀取原有的灰度業(yè)務(wù)數(shù)據(jù)。因此我們改造了應(yīng)用的讀取策略，將一套實例數(shù)據(jù)（用戶、訂單、費用等）緩存與生產(chǎn)和灰度共享，這樣灰度環(huán)境中的訂單在生產(chǎn)環(huán)境中也能查詢和續(xù)費。系統(tǒng)切換后，用戶無需重新下單驗收，實現(xiàn)了灰度和生產(chǎn)環(huán)境的無縫切換。

06 客戶評價

不同時期的業(yè)務(wù)對系統(tǒng)性能的要求不同，在性能要求不滿足時對系統(tǒng)設(shè)計的要求也不同。解釋起來有點困難，但總之，系統(tǒng)在不斷支持和演進的過程中，會遇到前期設(shè)計不足、不完善導(dǎo)致的問題。解決此類問題，可以謹慎，只治不好的地方；也可以大刀闊斧，一路砍掉。對于這種不治之癥就會一直縈繞在病床上的問題，修修補補可以暫時緩解，但果斷重構(gòu)才是負責(zé)任的表現(xiàn)。