News
您的位置：
眾所周知，分布式緩存作為系統性能提升的銀彈利器，它在大型分布式系統中的使用頻率非常高，對系統的性能提升起到了不可或缺的作用。近些年來，分布式、中心化紅遍整個IT界，以高內聚、低耦合為原則，CRM逐步演進成為多中心分布式部署的架構，由此產生的各中心間交互在業務日益復雜的催化下，系統對PAAS平臺組件提出了更高的要求。不出意外的是，分布式緩存在業務生產中也正面臨著諸多挑戰。02理想與現實的沖突業務系統引入分布式緩存的初衷是提升系統性能，給使用人員帶來快、簡、靈的操作體驗。為了能夠盡快得到分布式緩存帶來的好處，加速在系統建設中引入分布式緩存，采用懶漢式（讀時觸發）的加載模式--當緩存中沒有數據時，先從DB讀取，再加載到分布式緩存中，這種模式普遍存在于很多系統建設的初期。伴隨著時間的推移和業務訴求的不斷變化，人們會在使用中發現，要滿足復雜業務的要求，光使用分布式緩存還是不夠，因此加入了應用服務器作為二級緩存，以期減少應用與遠程分布式緩存的交互次數。調整后系統的緩存使用架構就變為兩級模式。在這個架構模式下，發現系統在很多業務場景下性能有了很大的提升，例如產銷品查詢、產銷品關系查詢?？呻S之也帶來了一些緩存使用上的問題：1）緩存數據不透明：無論是遠程的分布式緩存，還是本地的二級緩存，都是一個巨大的黑盒。目前并沒有可靠的可視化工具能夠清晰查看緩存的內容。尤其是在應用層對緩存的key/value值進行加工后，運維人員更沒有辦法通過簡單的一個標識去查看緩存key對應的value值。2）多中心緩存刷新問題：多中心架構下，同一套配置數據，幾個中心可能都需要，因此在做刷新的時候，如何保證各中心的緩存都能刷新到？如何確保漏刷情況被及時發現，并且能夠靈活處理。3）緩存數據一致性問題：遠程分布式緩存、本地二級緩存的數據與DB的數據一致性如何保證？如何及時發現不一致的情況并且能夠提示預警。在分布式緩存給業務系統帶來的性能提升的理想前面，依然存在使用過程中技術與業務結合的痛點和運維過程中面臨的一些比較實際的問題。解決理想與現實的沖突也是一個較大的挑戰，怎么辦？03直面挑戰，給出答案生活中我們常常遇到因時間推移、個人需求、人口數量等變化導致房屋設施老化、格局不合時宜的情況，需要不定期整理或是翻新。有趣的是，實際的CRM緩存優化過程跟舊房翻新的工序原本異曲同工。圍繞“一個愿景、兩個目標、四個提升、七大舉措”，CRM各中心的緩存模塊重構和優化分為兩部分：一部分是主體改造部分，另一部分則是精修打磨部分。04主體改造——緩存刷新重構改造前期--對現有功能的拆解改造前期對原有功能邏輯的梳理過程，需要對現有的業務支撐力度有一定的了解。把原頁面的所有元件，包括按鈕、表單等都進行拆解，記錄每個按鈕的功能。拆解是一個機械的過程，不需要多加任何判斷。所有需要優化的部分，放在后面的步驟中決定。便于后期區分哪些業務功能進行保留，哪些邏輯進行重整。設計階段--確定整體風格、進行整體設計對現有的功能進行拆解與梳理之后，我們已經知道了系統中的存量功能，發現原有的舊版頁面功能比較混亂，部分邏輯冗余、部分功能存在缺陷等。梳理之后按照業務維度，進行整理和歸納，確定總體優化方案。建立了統一刷新的總體事項和計劃：構建CRM幾大中心的緩存統一管理功能，讓運維人員易懂，功能清晰，支持單值刷新、支持批量刷新，支持緩存值查看；CRM一點刷新能力，涉及關聯關系的緩存數據，根據業務要求做到同步刷新，包括關聯的規格、實例模板等。實現一點刷新，不再需要人為去判斷邏輯順序，可以按照銷售品維度、產品維度等進行全量刷新；CRM緩存刷新操作有跡可循，分布式應用多節點緩存信息可巡檢、對比，刷新操作日志保留，方便運維和開發人員對問題進行定位與跟蹤；提供CRM可視化界面，經過加工的KV值按結構進行展示，可直觀、清晰地查看到分布式緩存、本地緩存、數據庫三者的緩存對象具體值。重新設計后的統一刷新架構如圖優化重構改造第一步：拆除工作--剔除不必要冗余的邏輯經過對功能的拆解和專題設計階段，梳理出散落在各個中心的緩存刷新口徑大概有10多個，口徑多、頁面多，難免給運維人員混淆視聽，這就需要從各中心散落的緩存管理功能中取其精華、去其糟粕，剔除掉散落不一的頁面和冗余的業務邏輯，將各中心保留的頁面功能一并集成到門戶的統一管理頁面中。第二步：隱蔽施工工程--緩存刷新機制統一，zk命令發布監聽模式統一分布式架構中，對于需要更高的性能以及更好的可用性的數據，往往將緩存設計為多級結構，如果有數據更新，需要考慮如何保證各個主機節點進程內緩存數據一致。為保證緩存刷新的一致性，我們使用了新的刷新模式，通過刷新頁面發起緩存刷新請求，當應用接收到緩存刷新請求后，生成緩存刷新命令并且把命令寫入到ZK節點，每個中心后端應用都有一個zookpper提供的api做實時的監聽，當監聽到zk節點數據發生變化后，每臺應用獲取節點的命令、解析命令、調用命令緩存刷新的API，從而刷新本地應用節點的進程內緩存數據。第三步：基礎施工工程--按照使用角色提供刷新界面參與緩存運營工作角色包括版本發布、故障運維人員和規格數據運營三種角色。角色不同、操作習慣也會存在一定的差異，為了讓緩存管理功能更加強大，我們針對不同的角色，提供了個性化的刷新界面和邏輯。1、針對運維或數據運營角色人員，我們提供了key值查看緩存數據并刷新的界面。2、針對版本發布人員，我們只需要提供表、字段對應的KV關系刷新界面即可。第四步：常規裝修--緩存可視化、緩存巡檢、緩存操作日志要解決緩存可視化問題，必須將緩存的內容進行結構化展示。在業務系統中，我們緩存的數據有可能是單一的KV映射值，也可能是復雜的業務對象數據。因此要提供給運維人員一個可視化的展示，我們就需要將key和value值進行內部進行封裝再提供出來。以產商品的配置數據緩存結構為例，它的結構是由不同的子表緩存對象組成。在完成結構化的梳理后，再增加頁面緩存數據結構化展示，使得結果能夠更清晰直觀。完成了刷新緩存動作后，操作是否成功，緩存的數據情況無法查看。為解決這個問題，還需要提供可視化的巡檢功能，操作后可以在頁面發起請求，后端根據key值循環調用每個應用節點，獲取key對應的緩存值進行稽核，對比本地緩存與數據庫是否一致，標記數據不一致應用節點，同時組裝本地緩存對象的數據值。巡檢結果可視化，差異數據對比，效果如下圖所示：巡檢數據差異對比05精修打磨——緩存引擎使用提升舊房翻新經過主體改造之后，基本已經達到入住標準，但是對于改造前房屋主人保留的家具物品等，還需要進行妥善地規整與安置，從而達到拎包入住的水準。俗話說，“三分雕，七分琢”，在完成主體功能優化和重構后，對常用的核心功能也需要進行精修與打磨，從而能夠提升緩存的使用效率：原子能力細化和封裝針對緩存的部分API進行原子化封裝，對每個API給出詳細說明，精益求精，規范及方便后續研發人員的使用。緩存補償和緩存攔截機制為防止系統產生臟數據，需要對異常數據進行預防和清洗。對于緩存數據缺失值，需要采取補償機制；對于異常值，則增加了緩存校驗和攔截機制。打造特色--灰度生產緩存無縫切換CRM灰度環境的應用，讓部分用戶進行版本升級的內測，很大程度地規避了因版本問題產生生產故障的風險。在架構設計時，就將灰度和生產環境的緩存進行了隔離。但這種方式也帶來了一些問題，當灰度驗證的業務數據沒有及時辦結，在灰度切換到生產環境后，原來灰度的業務數據無法在生產被讀取。因此我們對應用進行讀取策略改造，通過生產與灰度共享一套實例數據（用戶、訂單、費用等）緩存，實現灰度環境的訂單也能在生產環境查詢與續辦。用戶在系統切換后，無需重新下單受理，從而實現了灰度和生產環境之間的無縫切換。06感言不同時期業務對系統性能的要求不同，不能性能要求情況下對系統設計的要求也不同，說起來比較拗口，簡言之即是系統在持續的支撐演進過程中，都會出現由于前期設計不充分、不到位的情況所引發的問題。解決此類的問題，可以是小心謹慎，哪里不行醫哪里；也可以是大刀闊斧，橫豎來一刀。對于這種不根治則就會持續纏綿于病榻的問題，修修補補能得一時之爽，但是果斷重構方顯擔當。
改造前期--對現有功能的拆解
設計階段--確定整體風格、進行整體設計
構建CRM幾大中心的緩存統一管理功能，讓運維人員易懂，功能清晰，支持單值刷新、支持批量刷新，支持緩存值查看；
CRM一點刷新能力，涉及關聯關系的緩存數據，根據業務要求做到同步刷新，包括關聯的規格、實例模板等。實現一點刷新，不再需要人為去判斷邏輯順序，可以按照銷售品維度、產品維度等進行全量刷新；
CRM緩存刷新操作有跡可循，分布式應用多節點緩存信息可巡檢、對比，刷新操作日志保留，方便運維和開發人員對問題進行定位與跟蹤；
提供CRM可視化界面，經過加工的KV值按結構進行展示，可直觀、清晰地查看到分布式緩存、本地緩存、數據庫三者的緩存對象具體值。
優化重構改造
第一步：拆除工作--剔除不必要冗余的邏輯
經過對功能的拆解和專題設計階段，梳理出散落在各個中心的緩存刷新口徑大概有10多個，口徑多、頁面多，難免給運維人員混淆視聽，這就需要從各中心散落的緩存管理功能中取其精華、去其糟粕，剔除掉散落不一的頁面和冗余的業務邏輯，將各中心保留的頁面功能一并集成到門戶的統一管理頁面中。
第二步：隱蔽施工工程--緩存刷新機制統一，zk命令發布監聽模式統一
第三步：基礎施工工程--按照使用角色提供刷新界面
參與緩存運營工作角色包括版本發布、故障運維人員和規格數據運營三種角色。角色不同、操作習慣也會存在一定的差異，為了讓緩存管理功能更加強大，我們針對不同的角色，提供了個性化的刷新界面和邏輯。
1、針對運維或數據運營角色人員，我們提供了key值查看緩存數據并刷新的界面。
2、針對版本發布人員，我們只需要提供表、字段對應的KV關系刷新界面即可。
第四步：常規裝修--緩存可視化、緩存巡檢、緩存操作日志
要解決緩存可視化問題，必須將緩存的內容進行結構化展示。在業務系統中，我們緩存的數據有可能是單一的KV映射值，也可能是復雜的業務對象數據。因此要提供給運維人員一個可視化的展示，我們就需要將key和value值進行內部進行封裝再提供出來。以產商品的配置數據緩存結構為例，它的結構是由不同的子表緩存對象組成。
在完成結構化的梳理后，再增加頁面緩存數據結構化展示，使得結果能夠更清晰直觀。
完成了刷新緩存動作后，操作是否成功，緩存的數據情況無法查看。為解決這個問題，還需要提供可視化的巡檢功能，操作后可以在頁面發起請求，后端根據key值循環調用每個應用節點，獲取key對應的緩存值進行稽核，對比本地緩存與數據庫是否一致，標記數據不一致應用節點，同時組裝本地緩存對象的數據值。
巡檢結果可視化，差異數據對比，效果如下圖所示：
巡檢
數據差異對比
原子能力細化和封裝
緩存補償和緩存攔截機制
打造特色--灰度生產緩存無縫切換
浩鯨云計算科技股份有限公司 版權所有 2003-2023
蘇ICP備10224443號-6 蘇公網安備 32011402011374號