ICS35.240.40CCSA11北京金融科技產業聯盟發布IT/BFIA040—2024前言 2規范性引用文件 3術語和定義 4縮略語 5概述 6技術平臺能力要求 6.1軟負載均衡平臺 6.2分布式服務平臺 6.3分布式事務平臺 6.4分布式消息平臺 6.5分布式數據庫平臺 6.6分布式緩存平臺 6.7分布式批量平臺 T/BFIA040—2024本文件按照GB/T1.1—2020《標準化工作導則第1部分：標準化文件的結構和起草規則》的規定起草。請注意本文件的某些內容可能涉及專利。本文件的發布機構不承擔識別專利的責任。本文件由北京金融科技產業聯盟歸口。本文件起草單位：中國金融電子化集團有限公司、北京金安信息技術有限責任公司、中國工商銀行股份有限公司、建信金融科技有限責任公司、中國農業銀行股份有限公司、中國銀行股份有限公司、中銀金融科技有限公司、上海浦東發展銀行股份有限公司、華為技術有限公司、螞蟻科技集團股份有限公司、騰訊云計算（北京）有限責任公司、中電金信軟件有限公司、安超云軟件有限公司、新華三技術有限公司。本文件主要起草人：姜云兵、班廷倫、馬國照、韓竺吾、李晨曉、王鑫、張家宇、沈力、巫春梅、夏龍飛、施經緯、滕達、徐克寶、吳純波、武文斌、鐘小威、林鎮熙、郝春雨、王海萌、肖飛軍、張正園、隋寧寧、楊永、唐成山、丁陳飛、陳軍、郭維、胡曉磊、郭智慧、蔣增增、李克鵬、駱君柱、王鵬飛、隋成龍、許剛、李培、徐省委。T/BFIA040—2024近年來隨著科技與金融加速融合，金融業務模式逐步朝著線上化和多樣化的方向發展，分布式架構具備高效彈性、開放靈活等特性，可有效適應業務的快速調整和市場的快速變化，為金融信息系統的發展筑牢基石。金融業IT系統分布式架構轉型提升了應用系統海量交易高并發和海量數據處理的整體性能，保證了金融應用系統的可用性，分布式架構是未來金融行業IT系統架構的重要架構形式。當前，仍存在較多的金融IT系統運行于集中式架構之上，IT系統整體進行分布式架構轉型還面臨著業務連續性要求高、海量遺留系統改造難、海量應用管理難、缺少行業級架構設計標準指導以及潛在技術安全風險等共性問題，隨著金融行業數字化轉型的深入，這些問題將影響金融機構數字化轉型質量與進程。為幫助和引導金融機構快速構建自身的分布式架構支撐體系，推動金融行業應用系統的整體分布式架構轉型，提升各金融機構分布式架構轉型的質量和效率，降低實施成本，特編制金融分布式系統系列標準。本文件是金融分布式系統系列標準之一，金融分布式系統系列標準包括：——《金融分布式系統術語》。目的在于給出本標準系列中所使用的專業名詞，是其余各部分閱讀和應用的基礎。——《金融分布式系統IT治理指引》。目的在于給出金融機構分布式架構轉型后IT治理能力建設原則、流程管理、技術要求、技術支撐體系等方面的要求，以指導金融業分布式架構轉型的IT治理能力建設，形成貫穿研發、運維、管理各領域的立體式的深度治理體系。——《金融分布式系統參考架構》。目的在于給出金融機構IT系統分布式架構設計參考，確立金融業IT系統分布式架構的核心模塊、組件以及整體結構，闡明分布式系統架構下各模塊和組件的主要功能以及相互間關系。——《金融分布式系統應用設計原則》。目的在于給出金融應用微服務改造設計的總體要求，闡明微服務設計、單元化設計、一致性方案設計、并行驗證設計以及正確性驗證等通用要求。——《金融分布式系統技術平臺能力要求》。目的在于給出金融應用運行時所需關鍵技術平臺能力的總體要求，闡明軟負載均衡、分布式服務、分布式事務、分布式消息、分布式數據庫、分布式緩存以及批量調度等領域的通用要求和安全擴展要求。——《金融分布式系統應用開發測試原則》。目的在于給出分布式架構下金融應用開發與測試相關要求，闡明分布式應用軟件開發規范、工具方法與測試要求、內容、方法、過程、環境、文檔、工具以及管理的通用要求，保障金融分布式應用的研發質量，更好滿足用戶需求。——《金融分布式系統運維能力要求》。目的在于給出金融應用運維時所需關鍵支撐能力的總體要求，闡明金融應用部署、監控、故障定位與分析、運行保護等領域的通用要求。1T/BFIA040—2024金融分布式系統技術平臺能力要求本文件規定了金融分布式系統技術平臺能力的總體要求，涵蓋軟負載均衡、分布式服務、分布式事務、分布式消息、分布式數據庫、分布式緩存以及批量調度處理等領域的通用要求和安全擴展要求。本文件適用于金融業分布式架構技術平臺建設。2規范性引用文件下列文件中的內容通過文中的規范性引用而構成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對應的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。GB/T40473.7—2021銀行業應用系統非功能需求第7部分：安全性JR/T0203—2020分布式數據庫技術金融應用規范技術架構要求JR/T0205—2020分布式數據庫技術金融應用規范災難恢復要求T/BFIA037-2024金融分布式系統術語3術語和定義T/BFIA037-2024中界定的術語和定義適用于本文件。4縮略語下列符號和縮略語適用于本文件。ACID：原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)和持久性（Durability）CPU：中央處理單元（CentralProcessingUnit）ECMP：等價多路徑路由（Equal-CostMulti-Path）HTTP：超文本傳輸協議（HyperTextTransferProtocol）IPv6：互聯網協議第6版（InternetProtocolVersion6）IPv4：互聯網協議第4版（InternetProtocolVersion4）JVM：虛擬機（javaVirtualMachine）RPO：恢復點目標（RecoveryPointObjective）RTO：恢復時間目標（RecoveryTimeObjective）SQL：結構化查詢語言（StructuredQueryLanguage）TCP：傳輸控制協議（TransmissionControlProtocol）UDP：用戶數據報協議（UserDatagramProtocol）5概述2T/BFIA040—2024分布式系統技術平臺主體由三層七個平臺組成，按照交易處理流程自上而下分為統一接入層、服務集成層和數據處理層。統一接入層為解決傳統硬件負載均衡擴展能力弱的問題，主要涵蓋軟負載均衡技術平臺，支持服務器加軟件的方式，實現高度可定制化的流量分發調度和故障隔離能力，提高接入效率。服務集成層為傳統單體應用拆分提供了方法論和底層基礎支撐框架，主要涵蓋分布式服務、分布式事務、分布式消息三大技術平臺，支持業務系統按照分布式服務架構部署和運行，具備跨系統間事務一致性，高峰緩沖解耦場景下消息通信模式。數據處理層為分布式架構下數據處理和存儲訪問提供平臺支撐，主要涵蓋分布式數據庫、分布式緩存、分布式批量三個技術平臺，支持數據可靠存儲，高效訪問及分布式數據的批量調度等分布式架構下配套的數據處理能力。分布式系統技術平臺架構組成圖見圖1。分布式系統技術平臺統一接入層軟負載均衡平臺統一接入層分布式服務平臺服務集成層分布式服務平臺服務集成層分布式消息平臺分布式事務平臺分布式數據庫平臺分布式批量平臺分布式數據庫平臺分布式批量平臺分布式緩存平臺數據處理層圖1分布式系統技術平臺架構組成圖6技術平臺能力要求6.1軟負載均衡平臺6.1.1總體要求軟負載均衡滿足以下總體要求：a）應支持基于OSI網絡模型第四層協議網絡傳輸層的負載均衡，支持TCP、UDP協議負載均衡；b）應支持基于OSI網絡模型第七層協議應用層的負載均衡，支持HTTP、HTTPS協議負載均衡；c）應支持最少連接數、輪詢、隨機、權重等負載均衡策略；d）應支持自助服務、健康告警、性能分析、應急操作等運維管理能力。6.1.2部署架構要求軟負載均衡分為四層軟負載和七層軟負載。軟負載均衡架構宜采用四七層軟負載的雙層負載均衡的部署架構。四層軟負載集群宜通過ECMP多活模式或虛擬路由冗余協議（VRRP）主備模式來實現集群內節點的高可用性和可擴展性。七層軟負載集群宜通過七層軟負載集群的負載均衡能力來實現高可用性和3T/BFIA040—2024可擴展性。ECMP多活模式示意圖見圖2。圖2ECMP多活模式示意圖VRRP主備模式示意圖見圖3。圖3VRRP主備模式示意圖6.1.3核心能力要求軟負載均衡平臺核心能力要求如下：a）應提供多元化的負載均衡算法，包括但不限于如下配置能力：——最少連接數；——一致性hash。b）應提供包括傳輸層到應用層的負載均衡與調度服務；c）應支持基于TCP、UDP協議的傳輸層負載均衡；d）應支持基于HTTP、HTTPS協議的應用層負載均衡；e）應提供多維度的檢查真實服務節點健康狀態的檢查策略；4T/BFIA040—2024f）應支持基于TCP連接和基于HTTP請求的健康檢查；g）應支持可定制健康檢查方案，包括但不限于如下配置能力：——健康檢查策略；——頻率；——周期。h）應提供主要使用基于IP和基于Cookie會話保持策略的會話保持服務；i）應提供IPv4與IPv6兼容的雙棧負載均衡與調度服務；j）應提供明確的服務異常錯誤碼和錯誤信息，如返回HTTP錯誤碼；k）應具備并發限流能力，支持針對并發連接數、新建連接數等進行限流；l）應具備訪問超時控制能力，并根據業務特征合理配置超時時間；m）宜支持通過插件方式對統一接入層的功能進行動態配置擴展。6.1.4管理面板要求軟負載均衡管理面板要求如下：a）軟負載均衡管理面板應具備獨立性，管理平臺任何服務器異常，不應影響負載均衡流量調度核心功能的可用性；b）軟負載均衡管理面板應滿足可靠性要求，管理面板不應因應用節點異常導致不可用；c）軟負載均衡的運維管理能力應包括以下管理能力：——配置管理能力，應支持用戶通過前端頁面或者接口調用的方式，方便快捷的實現配置管理；——靈活發布能力，應支持對接入服務進行靈活發布，如版本號灰度、百分比灰度、分組發布——監控管理能力，應支持統一監控采集，快速上報監控報警信息，保證處理的時效性和準確——應急管理能力，應支持運維人員通過管控平臺實現快速應急管理操作；——統計分析能力，應支持以視圖或者報表的形式展示運行指標統計結果。6.2分布式服務平臺6.2.1總體要求分布式系統應支持業務通過微服務的形式通信和交互。抽象業務領域的邊界，業務能力應具備內聚和解耦，實現業務服務的高度復用，研發效率和產品組合能力的極大提升。微服務架構在部署上相較于傳統集中式架構，應具備獨立部署和按需擴縮容的特性，具體包括如下：a)注冊中心；b)服務注冊；c)服務訂閱；d)服務調用；e)服務下線。6.2.2核心能力要求注冊中心注冊中心功能要求如下：a)應支持服務注冊與服務注銷，動態獲取服務實例地址及上下線等服務信息；b)應支持服務訂閱，服務調用方能從注冊中心獲取到所有訂閱服務的服務信息；5T/BFIA040—2024c)應支持服務通知，當服務注冊和服務反注冊引起注冊中心信息變更，注冊中心主動通知到服務訂閱方；d)應支持服務健康檢查，定時檢測服務提供方的健康狀態；e)應支持集群內故障容錯，半數以內宕機不影響集群可用性；f)應具備故障不影響服務正常調用；g)宜具備對沖擊性負載的自我保護能力，不因過載負荷導致集群運行故障；h)宜具備故障快速恢復，恢復過程不影響應用服務正常調用；i)宜支持服務信息動態續租；j)宜支持注冊中心多租戶隔離；k)宜支持多集群故障容錯，單個集群故障不影響注冊訂閱服務能力；l)宜支持多集群數據之間的動態同步。服務網關服務網關功能要求如下：a)應支持全鏈路灰度功能，可通過設置灰度標簽路由到灰度提供方；b)應支持限流功能，針對應用級及服務級限流防止某個應用出問題影響其他應用調用；c)應支持泛化調用，提供方發生變化無需重啟網關便可進行調用；d)應支持告警功能，當遇到問題時能及時通知；e)應支持服務網關的生命周期管理；f)應支持API安全管理，支持SSL/TSL加密；g)宜在服務網關開展身份鑒權和白名單管理，網關后路由的微服務可不進行黑白名單管理。服務注冊服務注冊功能要求如下：a)宜具備注冊狀態校驗，宜具備對外提供服務能力時再向注冊中心注冊；b)宜針對服務身份進行驗證，防止服務未經授權注冊。服務訂閱服務訂閱要求如下：a)應包含訂閱服務的名稱；b)應只訂閱有實際調用關系的服務；c)宜對服務訂閱者的身份進行認證，防止未經授權訂閱。服務調用服務調用要求如下：a)消費方應具備直連提供方的能力，在進行服務調用時，不用經過注冊中心等第三方節點，應與提供方點對點調用，服務調用關系示意圖見圖4；6T/BFIA040—2024圖4服務調用關系示意圖b)服務調用應具備負載均衡的能力，消費方在服務調用時應根據服務提供方的技術特性，合理使用負載策略，包括但不限于如下負載策略：——隨機；——最小連接數；——輪循；——一致性hash。c)服務調用應具備失敗容錯的能力，在服務調用時應根據業務特性，包括但不限于如下容錯策略：——合理使用超時重試；——并發限流；——快速失敗。d)服務調用應支持服務降級（如自動開關降級服務提供方和消費方在服務調用時應根據業務特性，合理使用降級策略；e)服務調用宜支持智能化園區優先能力，優先選擇同園區的服務方，當同園區服務提供方數量與同城其他園區對比少于特定閾值，智能切換到同城優先模式，不再執行同園區優先策略；f)服務調用宜提供熔斷機制，當服務調用失敗率超過特定閾值，不再對服務進行真實調用；g)服務調用時應具備超時控制能力，并根據業務特征合理配置超時時間；h)消費方在服務調用時應根據業務特性，合理提供多種流控能力，包括但不限于如下流控能力：——延遲處理；——部分拒絕處理或拒絕處理。i)服務方應具備業務功能預熱啟動能力，提供方在業務功能預熱完成后再對外暴露服務，本地業務規則信息未預熱完成前不允許交易流量接入；j)服務方應具備運行時故障自隔離、自恢復能力，隔離延時在秒級，降低單一節點故障對系統的業務連續性影響；k)服務調用宜滿足GB/T40473.7—2021中3.1規定的要求，拒絕非法服務調用，以使用戶、其他產品或系統具有其授權類型和授權級別一致的數據訪問度。服務注銷服務注銷過程要求如下：a)服務提供方應主動通知注冊中心注銷服務；b)注冊中心應刪除服務注冊相關信息；c)應用側應具備優雅停機能力，保證在途交易執行完成。6.2.3服務治理7T/BFIA040—2024服務治理方面，在業務系統微服務拆分后，系統規模和服務數量增多，應具備對服務進行場景化治理的功能，服務治理通常包括熔斷、限流、容錯、路由等，相關的治理項要求如下：a)應支持微服務自動注冊發現；b)應支持微服務負載均衡策略配置；c)應支持微服務限流策略配置；d)應支持微服務降級策略配置；e)應支持微服務熔斷策略配置；f)應支持微服務容錯策略配置；g)應支持微服務錯誤注入策略配置；h)應支持微服務黑白名單策略的訪問控制配置；i)應支持微服務系統路由策略管理；j)宜支持微服務系統接口級訪問管控策略管理；k)宜支持微服務系統接口報文Schema配置及校驗開關。6.3分布式事務平臺6.3.1事務模型概述根據CAP定理，分布式事務沒有完美的解決方案，應根據不同業務場景需求，采用不同的分布式事務模型。分布式事務平臺應提供XA模型、Saga模型、Tcc模型3種分布式事務典型場景的技術支撐。6.3.2事務接入能力分布式事務應具備統一的接入規則，具體要求如下：a)應提供統一的分布式事務中間件，內置各類事務處理能力，滿足各類事務模型的接入需求；b)分布式事務處理應支持分布式微服務通信協議，如HTTP、Dubbo、gRPC等。6.3.3事務異常處理能力分布式事務平臺應對處理異常機制如下：a)異常自動化處理機制，應滿足包括但不限于如下要求：——通訊異常、處理超時等異常場景下的自動重試機制；——冪等、空回滾、防懸掛等保障機制。b)異常預警能力，若異常的自動化處理機制失效，或無法完全覆蓋異常場景時（即無法通過自動化處理機制確保異常場景下事務最終處理成功），應建立兜底機制及時告警預警；c)異常排查能力，應具備事務狀態監控和統計，以及鏈路回查能力，應提供異常場景下快速排查機制；d)異常手工介入能力，在自動化機制失效，無法有效處理事務時，應具備異常場景下手工運維能力，提供手工快速應急機制，通過可視化的管理前臺進行手工運維。6.4分布式消息平臺6.4.1概述分布式消息是一種分布式系統或組件之間相互協作的通信機制，是分布式系統中的重要組件，廣泛應用于異步解耦、消息通知、流量削峰、數據共享、事務最終一致性等場景。消息服務應具備高安全、高可靠、高性能、可伸縮等企業級特性。消息服務主要涉及消息發布者（Publisher）、消息代理（MessageBroker）、消息訂閱者8T/BFIA040—2024（Subscriber）、管理控制臺（Console）以及監控（Monitor）等核心組件，具體如下：a)消息發布者：送消息的應用系統，消息發布者將消息發送到消息代理組件，支持發送一種或者多種類型的消息；b)消息代理組件：負責接收消息的系統，消息代理可根據消息類型和消息訂閱元數據將消息分發投遞到一個或多個消息訂閱者，分發投遞過程涉及消息類型校驗、消息持久化存儲、消息訂閱關系匹配、消息投遞、消息恢復等核心功能；c)消息訂閱者：閱消息的應用系統，消息訂閱者可訂閱一種或者多種類型消息，消息訂閱者的消息來自消息代理組件；d)管理控制臺：集成消息查詢、節點啟停、擴縮容等常用運維操作，圖形化展示集群運行狀態的組件；e)監控組件：采集集群、節點性能、可用性數據，分析性能、可用性數據組件。6.4.2核心能力要求消息發布、訂閱要求消息發布、訂閱具體要求如下：a)消息發布、訂閱應通過用戶名、用戶標識接入消息服務；b)消息發布、訂閱應具備超時控制能力，可根據業務特性合理配置超時時間，超時可自動進行重試；c)消息交付語義應為至少一次（At-least-once，消息不會丟失，但可能被處理多次）；d)消息訂閱者應支持消息處理冪等性；e)消息發布應支持消息主題分區或全局有序；f)消息訂閱者應支持按集群模式部署，消費組內部分訂閱者實例宕機，其余訂閱者可接管其訂閱分區，不影響業務連續性。消息代理要求消息代理具備高可用、可擴展等企業級特性，具體要求如下；a)消息代理應支持集群方式部署，消息主題（或分區）應支持多副本模式，可通過消息節點多園區部署，消息主題（或分區）副本跨節點分布，支持多中心多活架構，部分節點下宕不影響整個集群的對外服務能力；b)消息集群同城多園區應具備熱切換能力，支持園區故障秒級切換園區，切換過程對業務無影響；c)消息主題應支持多分區部署，可通過橫向擴展分區提高系統整體吞吐量；d)消息代理應支持消息服務的安全認證，對使用消息服務的用戶進行身份鑒別，并控制其訪問不同消息主題的權限；e)消息代理應支持用戶、節點級的限流能力，防止流量突增導致服務不可用；f)消息代理應支持按時間、空間維度制定消息清理策略，數據清理前應進行告警提示，避免數據在訂閱者成功消費前被清理；g)消息代理應具備消息確認機制，消息訂閱者在消費異常時能自動進行消費重試；h)消息代理應具備死信隊列機制，對于多次消費仍無法確認的消息，可按照一定的策略自動清理；i)消息代理應具備數據鏡像復制能力，可在災備場景保障秒級故障恢復能力。6.4.3管理能力要求消息服務在管控層面應具備完備的管控能力，具體要求如下：9T/BFIA040—2024a）臺賬管理：應支持實時查看或管理消息主題、分區、消息發布、訂閱者等信息；b）消息查詢：應支持根據消息偏移量或時間查詢消息；c）消息訂閱查詢：應支持實時查詢在線消費組訂閱狀態；d）消息軌跡查詢：宜支持消息軌跡查詢能力；e）運維操作：應支持節點啟停、動態擴分區等常用運維操作；f）權限管理：應支持按照用戶角色來分配用戶權限，應支持不同角色的自助化服務；g）消息服務監控：對于交易量、發送/訂閱延遲、訂閱者消費進度等系列指標應進行有效監控；h）監控告警：對于運行過程中的異常事件應支持進行實時檢測和報警；i）系統資源監控：對于節點CPU、內存、存儲、連接數等系統狀態應支持進行監控；j）進程狀態監控：對于服務進程的可用性、JVM性能、線程數等跟進程相關的參數應支持進行有效監控。6.5分布式數據庫平臺6.5.1技術架構能力要求分布式數據庫技術架構，具體要求如下：a)應具備靈活的部署的能力，本地部署和云部署方式應至少支持一種；b)應具備基礎SQL語法的能力，應支持分布式事務，滿足ACID特性，至少支持已提交讀、可重復讀、串行化中的一種隔離級別；c)應具備讀寫分離的能力，應支持業務在架構層面進行讀寫分離優化，數據庫集群內宜支持一主多從，即主節點提供讀寫服務，多個從節點提供讀服務；d)應采用存儲和計算分離的技術架構，應支持根據需求可獨立擴展存儲和計算資源；e)應具備并發處理的能力，充分利用節點計算資源，應支持各種數據庫并發操作；f)應具備基本軟硬件的適配的能力，兼容主流的Linux操作系統、開發語言、開源數據庫協議和硬件平臺；g)應具備服務高可用的能力，全鏈路的組件均要求應支持高可用部署，當數據庫系統發生節點級故障時，RTO要求在秒級，RPO要求為0，應支持自動化方式切換；h)應具備數據冗余的能力，結合分布式數據庫一致性協議算法等數據冗余相關技術，實現數據副本間的一致性；i)應具備數據分片的能力，應支持多種常用分片策略；j)應具備彈性擴展能力，應支持水平擴展和垂直擴展的功能；k)應具備多租戶能力，應支持租戶間的資源和數據隔離；l)應具備智能運維的能力，應支持自動化安裝部署、監控告警、性能容量、系統配置、升級維護、數據遷移、數據備份恢復、日志分析等。6.5.2災難恢復能力要求分布式數據庫災難恢復能力，具體要求如下：a)應具備災難恢復的能力，根據JR/T0205—2020中劃分的容災等級，滿足金融領域容災能力6級中RTO和RPO的指標要求；b)應具備災環境建設的能力，應支持同城和異地災備的環境搭建要求，滿足從數據備份、數據處理、網絡能力和運維能力4個要素給出的容災能力等級相關技術要求。c)應具備跨集群數據同步功能，并滿足JR/T0203—2020中8.11規定的數據同步要求。6.5.3數據庫接口能力要求T/BFIA040—2024分布式數據庫接口能力，具體要求如下：a)應具備基礎的數據庫功能接口的能力，支持部署管理接口、節點管理接口、數據庫管理接口、多租戶功能接口等接口，支持數據分布、讀寫分離、并發處理的設置，支持分布式事務、跨庫的聯合查詢、分布式全局唯一且有序遞增的數字序列的能力等；b)應具備運維管理接口的能力，支持服務高可用接口、數據高可靠接口、運維審計接口、節點擴縮容接口、備份恢復接口、導入導出接口、監控告警接口、日志采集接口，支持數據庫滾動升級、補丁管理能力等，導入導出接口應滿足JR/T0203—2020中8.10規定的導入導出要求；c)產品接口參數應支持共用參數和共用錯誤信息。6.6分布式緩存平臺6.6.1基本功能分布式緩存平臺提供以key-value形式存儲數據服務，應滿足數據的存取需求，具體要求如下：a)應支持key的批量寫入和讀取操作；b)應支持在單個key上增刪查改；c)應支持各種key和value的數據寬度；d)應支持value自增/自減運算；e)應具備命令行交互的能力；f)應支持數據的導出和導入能力；g)應支持數據淘汰能力，在內存到達閾值時通過逐出算法保證新數據可正常寫入；h)應支持數據的磁盤持久化的能力；i)應支持數據過期時間設置，自動或手動地對歷史數據進行清理；j)應支持單機模式、主備模式、集群模式，應支持主從數據同步；k)應支持主備數據復制，可在災備場景保障秒級故障恢復能力。6.6.2兼容能力分布式緩存平臺在部署上應兼容多種部署場景，提供多語言場景的接入，具體要求如下：a)應兼容主流X86硬件，ARM或MIPS等異構硬件，不同CPU型號和不同Linux操作系統；b)應支持多種部署方式，可通過虛擬機（KVM/XEN）、容器或其他工具安裝部署；c)客戶端/服務端存在不同版本的數據時，應保證數據讀取正確（向下兼容）；d)應支持C/C++、Java、Python等多語言接入能力。6.6.3管理能力分布式緩存平臺在運維層面應提供完備的管控能力，具體要求如下：a)應支持自動化部署方式；b)應具備全局范圍內的數據庫配置在線管