數據中心存儲方案范文第1篇
一、云存儲模型分析
對于MCSERS云存儲模型而言, 其主要是利用各種公有云的技術與服務, 構建個人用戶的存儲私有云, 具體如下圖1所示。該模型可分為四層, 每一層都具有一定的承接關系, 下層服務是構建上層服務的基礎, 由上至下分為是服務層、安全存儲層、安全傳輸層、節點層。安全存儲層利用訪問限制和數據加密等技術, 對用戶數據的完整性、可用性和機密性加以保護。安全傳輸層則是在同一安全域中集中較為分散的云存儲模塊, 搭建安全通信通道, 保證傳輸的一致性及安全性, 有效滿足客戶端動態變化和存儲模塊的特性, 簡化資源使用流程, 實現云計算資源的動態分配。計算節點涉及不同的組件, 如信息記錄節點、存儲流程控制節點、存儲節點等, 不同的計算節點具有不同的任務流程, 能夠降運營商存儲造成的內部威脅。
二、云端存儲層的設計
(一) 架構
為了避免惡意用戶截取云存儲數據的機密性, 必須要保證云存儲端存儲和傳輸數據的合法性, 將加解密設置在用戶密鑰的終端。通常MCSERS云存儲層架構包括以下幾個方面:
1) 第三方身份認證服務提供商:其主要是對用戶終端的身份進行認證, 可由任何節點接入云存儲且獲得元數據服務器的信任, 并利用賬戶密鑰和賬戶身份來增強用戶數據的保密性。
2) 存儲節點:其是對用戶數據分片進行存儲, 利用元數據服務器控制來讀取或存儲數據分片。
3) 數據分割處理器:其對數據冗余重組和分割加以負責, 具有強大的吞吐能力與計算機能力, 適用于數據分片的交流工作;而用戶只有證明其合法性, 并利用存儲指令和運數據讀取, 才能獲得元數據服務器的信任。
4) 元數據服務器:其是云端儲存的代理管理節點, 能夠分配編號用戶數據;同時用戶需要實現申請服務器, 然后配置好腳本后接入到云存儲域中。
5) 用戶終端:用戶可以借助終端節點來登錄云存儲域, 并與元數據服務器相連, 將元數據服務器接入到瀏覽器或終端使用軟件中, 通過第三方身份認證服務后可以使用所提供的存儲服務。
(二) 服務流程
用戶在MCSERS云存儲方案中可以任意終端為依據, 接入云存儲域來讀取或存儲數據, 當然這一過程需經過如下步驟:
1) 元數據服務器通過第三方身份認證服務來認證用戶身份, 確認通信實體為數據擁有者后, 由信任終端發出數據存儲讀取指令。
2) 認證完用戶終端之后, 用戶可發出數據存儲指令, 這時元數據服務器可為用戶分配一個計算節點, 以此當成數據分割處理器, 如果用戶接受則可借助用戶密鑰來簽名此次會話, 然后發送至服務器, 繼而確認有效性, 提供存儲位置服務。
3) 在數據分割處理器中上傳加密后的數據, 并在存儲數據分片中使用有效存儲節點地址, 記錄好相關的分片信息。
4) 處理器發出數據讀取操作與分片存儲之后, 元數據服務器應將操作認證信息發送至存儲節點, 當存儲節點確認操作有效后可讀取和存儲數據分片。
以MCSERS云存儲流程為例, 在同一VPN實例內, 用戶即便滿足加入實例的條件, 也有可能無法滿足訪問數據的條件, 這就需要單獨認證處理用戶終端的身份。用戶終端相元數據服務器發送認證請求和必要信息, 當其接收到請求后進行賬戶加密處理, 然后相應的Id P通過解密來認證身份, 并相元數據服務器返回信息真偽。通常云存儲端讀取過程如下:用戶終端以用戶數據編號為依據提出讀取申請, 元數據服務器選取數據分片后發送至處理器, 繼而結合所獲取的讀取許可證發出認證信息, 認證成功后返還相應分片, 由數據分割服務器重組數據分片后返還給用戶終端, 最終保證數據的完整性與可用性。
三、結語
模塊化的云存儲方案設計可以保證存儲過程的靈活性以及選擇的多樣性, 適用于分布式的云存儲場景。而基于MCSERS的云存儲方案主要是利用云端VPN服務, 在統一的安全域中維護存儲組件, 保證數據的安全傳輸, 并通過用戶身份驗證來嚴格管理權限, 以免用戶數據分片被非法人員獲取, 增強用戶數據的保密性。本文構架的方案適用于云服務運營商, 可以有效提高網絡存儲服務的可靠性及安全性, 便于用戶在不同運營商之間進行數據的存儲及遷移。
摘要：在科學技術日新月異的背景下, 云技術被廣泛應用在社會生活的方方面面, 為人們提供了便利的條件。以往運營商在實際經營發展過程中, 僅僅只有單一的云存儲方案, 不能為用戶制定個人的云存儲服務, 難以滿足用戶的多樣化需求。而現階段, 運營商可以利用先進的技術來設計模塊化的云存儲方案, 不僅能保證用戶數據的訪問控制安全、存儲安全和傳輸安全, 還能增強數據的完整性、可用性、機密性, 為用戶提供安全可靠的網絡存儲服務。本文以MCSERS云存儲模型為例來分析數據加密分割的模塊化云存儲方案。
關鍵詞：數據加密分割,模塊化,云存儲方案
參考文獻
[1]鄭洪英, 王博, 陳劍勇.實現加密和分割的數據云存儲方案[J].深圳信息職業技術學院學報, 2014, 01:40-45.
數據中心存儲方案范文第2篇
關鍵詞：FAT32文件系統,嵌入式LINUX,視頻數據存儲系統
1 大容量數據存儲文件系統
嵌入式LINUX設備, 特別是現時流行的平板電腦, 對視頻數據服務需求特別大, 用戶往往對視頻進行頻繁的操作, 如回放, 快進, 快退, 斷點續播等, 為了保證此類設備對視頻數據的讀寫性能, 有必要對大容量數據存儲文件系統進行探究優化。
Linux支持多文件系統, 如EXT3、Reiser FS、HPFS、FAT32等。為了保證視頻數據在Windows上也能處理, 保證兼容性, 本論文采用應用廣泛的基于Windows的FAT32文件系統。
2 FAT32文件系統工作原理
2.1 FAT文件系統組成
FAT (File Allocation Table, 文件分配表) 是微軟開發的基于Windows的文件系統, 歷史共有FAT12、FAT16、FAT32三個版本。
FAT文件系統采用“簇”作為存儲單元, 一個簇由連續的幾個扇區組成, 每個簇包含的扇區數為2的整數次冪, 最多含有64個扇區, 每個扇區512字節, 每簇最大為32KB。
FAT文件系統主要由文件分配表和目錄項組成, 如圖1所示[1]:
1) 保留區主要由系統引導扇區組成, FAT12、FAT16保留區通常只有一個扇區, FAT32保留區則要多一些, 還包含系統引導備份扇區;
2) FAT1和FAT2用來存放大小相等的文件分配表, 即FAT表。FAT表包含該分區上所有簇的分配情況, 并記錄文件跨簇存儲時的簇號;
3) 數據區則保存目錄和文件數據的區域, 根目錄也在此區, 但根目錄不由簇管理, 所以沒有分配簇號, 簇號0和1保留它用, 所以數據區簇號從2開始。
2.2 FAT32文件分配策略
1) 當存儲設備沒有數據時, 新增文件1按簇號順序存儲, 新增文件2按簇號順序尋找空閑空間存儲, 并把簇號寫到FAT表。兩個文件連續存儲在簇號2到5的空間;
2) 刪除文件1后, 存儲該文件的簇號2和3空間釋放, FAT表相關簇號也得到釋放;
3) 此時新增一個占用3簇的文件3, 文件系統從FAT表從簇號2開始尋找空閑空間, 找到2號, 把一部分數據放進簇號2和3的空間, 由于文件2存儲在簇號4和5空間, 所以文件系統往下尋找, 找到簇號7的空間, 把剩余的數據放進該簇。
2.3 FAT32文件刪除過程
上面演示FAT分配文件過程時刪除了文件1, 文件系統首先從FAT表區中尋找名為“文件1”并且具有文件屬性的FAT表, 尋找到文件1的簇鏈, 即簇號2和3, 然后把簇號2和3的FAT項設置為0。如果刪除的是文件3, 簇鏈為簇號2, 3和7, 把簇號2, 3和7的FAT項設置為0。
3 視頻數據在FAT32文件系統存儲的局限性
由FAT文件分配策略來看, 當文件變得很大時, FAT文件系統不得不把文件分成多塊分散存儲, 組成一個文件的數據并不是連續存儲的, 對文件進行操作時需要進行多次磁盤尋道, 耗費大量尋道時間, 影響IO性能。
FAT簇大小固定, 數據塊小于簇大小時, 文件系統仍然用一簇進行存儲該數據塊, 造成磁盤碎片, 當文件變得越來越多時, 這類磁盤無法利用的碎片越來越多, 造成空間浪費。
視頻數據以幀為單位進行處理, FAT以簇為單位進行存儲, 當幀數據存儲在不連續的簇空間時, 對視頻進行操作 (如快進, 快退) 時尋道時間過長, 容易造成卡頓現象, 影響播放體驗。
同一文件的修改時間信息保存在FAT表固定位置, 而視頻數據一般都很大, 監控系統存儲視頻數據需對同一文件進行長時間寫操作, 數據每一次從緩存同步到磁盤時都會更新修改時間, 長時間對FAT表固定位置進行寫操作, 容易造成磁盤耗損。
針對上述局限性, 本論文在存儲結構上對FAT32進行優化。
4 可靠性存儲文件系統方案
4.1 存儲方案目標
在進行方案設計時, 本論文提出了對視頻數據存儲結構的目標:
1) 磁盤IO讀寫性能。存儲方案以提高視頻數據在磁盤上讀寫速度為目標, 同時避免對磁盤同一地方進行寫操作次數過多;
2) 視頻數據存儲連續性。包括兩方面, 保證同一幀數據的連續存儲以及幀幀數據之間的連續存儲;
3) 視頻檢索快速定位準確。由于大部分存儲數據為非關鍵數據, 在回放取證時能快速準確定位;
4) 存儲系統容易安裝卸載, 不影響原來文件系統。為了保證FAT32兼容性, 存儲方案應簡單易行, 方便用戶操作, 不需更改FAT32文件系統底層代碼。
4.2 存儲方案設計
每個磁盤在初次使用時都需格式化, 包括對磁盤進行分區, 確定容量, 簇大小等。經格式化后的磁盤數據區只有根目錄, 剩余空間沒有數據占用, 簇號是連續的。此時若把磁盤數據區分成大小相等的連續若干塊, 每一塊的簇鏈也是連續的, 并且塊與塊之間首尾地址也是連續的, 如圖2所示。
由此分析, 在磁盤進行存儲之前, 磁盤按指定大小把空間分成多個子空間, 每個子空間采用同樣大小的空文件進行占用, 文件之間按簇號順序進行編號, 則每個文件的簇鏈是固定并且簇號連續。當進行視頻數據存儲時, 只需對空文件進行寫操作即可, 文件的簇鏈結構并沒有改變。當前文件寫滿之后, 即對下一編號文件進行寫操作。
視頻數據以視頻幀為存儲單元, 幀一共可分為三種類型:I幀, P幀和B幀。I幀也稱關鍵幀, I幀壓縮方式是全幀壓縮, 不需參考幀, P幀則參考前面的P幀或I幀壓縮而成, B幀則是參考前后兩幀壓縮而成。視頻編解碼器可直接對I幀進行編解碼, 對于P幀和B幀則需要前面的參考幀并且需要I幀才能編解碼。所以, 在視頻數據存儲時, 每個視頻文件需以I幀作為起始幀。
這種策略最大的好處在于文件都是連續存儲, 當對文件進行操作時, 磁盤尋道次數減到最低, 能提高文件讀寫速度。視頻數據被分成多個文件存儲, 而不是對同一視頻文件進行長時間操作, 避免了對文件分配表的同一位置頻繁操作, 降低了對該位置磁盤的損耗。
4.3 存儲方案實現
系統在對磁盤進行初始化分塊時, 使用dd命令進行空文件創建操作:
dd命令作用是按指定大小復制文件, if參數是復制源, 其中/dev/zero是偽文件, 能源源不斷產生二進制NULL流, of參數是復制到的文件名, bs參數是以32k作為復制的塊大小, count是復制的塊數量。根據文獻[2], 在352*288的分辨率下, 每秒30幀, 碼率為250MB每小時的圖像, H.264在不同視頻內容壓縮出來的視頻文件大小如下表所示 (MB每小時) :
由表1可知, 碼率, 幀率, 分辨率和視頻內容都可以影響壓縮的視頻大小, 所以需綜合考慮以上因素決定空文件的大小來給磁盤分塊。
對磁盤初始化之后, 啟動系統對磁盤信息進行讀取, 包括磁盤容量、文件數量、單個文件容量、編號首位文件名和編號末位文件名等。
當系統對視頻數據進行存儲時, 還需對磁盤各個文件信息讀取, 包括文件名、文件容量、文件已使用容量、下一編號文件指針、文件最近修改時間和最近I幀位置等。
存儲系統結構如圖3所示。
系統啟動一個存儲線程, 監聽編碼視頻流緩存, 然后獲取新視頻幀進行存儲操作。此過程涉及對I幀的判斷, 如果在獲取編碼碼流時請求I幀, 便會把I幀標記作為參數傳入存儲模塊, 否則為P幀或B幀。當存儲模塊獲取I幀存入文件后, 便計算當前文件容量, 記錄最新的I幀在當前文件位置。如果存儲模塊獲取的不是I幀, 同時當前文件剩余容量無法存儲該幀時, 便讀取最近I幀位置, 并把I幀及后續內容一起移到新文件進行存儲。
5 結論
本文針對嵌入式LINUX視頻數據存儲方案進行探究, 基于FAT32文件系統采用預分配空間方式對H.264視頻流存儲進行優化。結合H.264格式特點, 對視頻流進行多文件連續存放, 減少磁盤尋道時間, 提高對視頻數據操作的性能。
參考文獻
[1]張明亮, 張宗杰.淺析FAT32文件系統[J].計算機與數字工程, 2005 (1) :56-59
數據中心存儲方案范文第3篇
關鍵詞：Hbase,大對象存儲,nosql數據庫
1緒論
云計算技術的發展使計算模型由傳統的客戶機/服務器(client/server)模式發展到web計算模式,進而發展為如今的云計算架構;電子商務的興起、智能終端的廣泛應用以及社交網絡的普及無不昭示著海量數據時代已經到來。
海量數據的首要特征就是其非結構化,這些數據不僅需要長期的存儲,而且還可能會被隨機訪問,傳統的數據存儲技術已經無法滿足海量數據的這些需求;另外,對大量數據的管理、挖掘和分析也難以使用傳統的關系型數據庫技術實現。
當存在一個包含大量業務數據的數據庫時,如何對其進行存儲,提高存儲和查詢的效率是當前的一個迫切需求。目前已有的技術中,基于Hadoop開源框架的HBase數據庫是一種比較成熟的解決方案。HBase數據庫在存儲數據時和傳統的關系型數據庫不同,是采取列式存儲的;這種存儲方式對于處理非結構化的數據有較大的優勢,如何發揮HBase存儲大對象的優勢,是本文重點研HBase究的內容。究的內容。
2HBase數據庫及其存儲方式
HBase數據庫是建立在Hadoop分布式開源框架上的,其數據存儲在Hadoop的核心組件HDFS文件系統上,能夠提供列式存儲的、高性能并且實時讀寫的分布式數據存儲功能。HBase數據庫是一種介于傳統的關系型數據庫和非關系型數據庫中間的一種數據庫,檢索數據的方式是其主鍵,一般用于存儲非結構化數據。不論是時間開銷,還是存儲方式,傳統的關系型數據庫在處理大對象時都有一定的局限性;而HBase數據庫誕生之初就是為海量數據準備的,可以處理高達PB級別的數據存儲。
HBase數據庫分為HMaster、Region server以及Client三種角色[1],相對于HMaster而言,所有的數據節點又可以稱為Region serv-er,因為它們存儲了相關表的region。region是按大小分隔的數據表的內容。HMaster會為Region server分配region,并在不同的re-gion間進行regionserver的負載均衡。當HMaster發現有region server失效時,會重新分配在此服務器上的所有region。
圖1表示了HBase的存儲架構,其中HBase Client包含訪問Hbase的API接口,它通過此接口和HBase進行交互:當HBase Client要進行管理類操作時,它和HMaster節點進行交互;當要進行數據類操作時,和Region server進行交互。Zookeeper是整個HBase數據庫集群的狀態協調程序,在zookeeper中存儲了HMaster和所有Region server的地址,這樣HMaster就可以感知所有Region server的狀態,一旦有regionserver失效,HMaster就重新分配存儲在此服務器上的所有region到其他可用Regionserver。
Zookeeper能夠有效避免HBase數據庫的單點故障問題:HBase數據庫集群中可以啟動多個master進程,zookeeper通過一定的選舉機制選擇哪個服務器的master進程充當HMaster,所以只要啟動了多個master,zookeeper就可以有效防止HBase集群出現單點故障,以保證HBase數據庫一直處于可用狀態。
HBase數據庫中的表如果比較大,會在行的方向上拆分為多個region,每個表開始時僅僅存在一個region,表的數據不斷增大使region也不斷增大,當增大到一個閥值的時候,一個region就會等分為兩個新的region。Region server中存儲了若干HRegion,對應表的region,每個HRegion由多個HStore文件組成,HStore文件是真正實現存儲大對象數據的數據結構,它又可以分為內存存儲(MemStore)和文件系統文件(HFile)兩部分。Client端寫入到HBase數據庫中的數據首先會被存儲在內存區域MemStore中,當整個MemStore存儲滿之后,這些內存中的數據才會被寫入到HFile中。HBase數據庫中可以存儲的HFile個數是有限的,但數量達到一定的限值后,HBase數據庫會執行合并(compact)操作,將多個HFile文件合并為一個。由HBase的這種存儲機制可以看出,對HBase數據庫的操作其實只有增加數據的操作,所有的更新和刪除操作都在合并過程中完成,因此client端的寫操作可以立即返回,無疑從存儲層次提高了HBase數據庫的I/O讀寫性能。
總而言之,分布式數據庫HBase的性能主要如下[2]:(1) 高擴展性。除了和HDFS集成的擴展性外,HBase數據庫自身就支持可擴展性:當region server中的HFile文件達到一定大小時,HBase會自動進行分裂(split)操作,分裂得到的兩個region會被分發到不同的region server上。通過這樣的方式,可以將海量數據分發到大量服務器上。(2) 高性能優勢。HBase在設計之初就支持高并發的讀寫,數據表被按行分為多個region,每個region被部署到多個region server上,從而支持對數據的并行訪問。
3大對象在HBase數據庫中的存儲
大對象(Large Object)主要有兩種:字符大對象和二進制大對象,日常生活中常見的圖片、視頻、音頻以及各種文檔等都可以看作是大對象。對大對象的存儲需要重點關注其插入、讀取和管理三部分。
目前HBase在存儲大對象數據時,主要有三種解決方案[3]:
1) 大對象數據存儲到HBase的一個列簇(column family)中。HBase數據庫中在存儲數據時都是使用Bytes數組存儲的,而大對象結構很容易轉化為此類結構;另外,HBase數據庫是按照列存儲數據的,每列可以有不同的列簇,所以可以將大對象單獨存儲到一個列簇中。這種大對象存儲方案充分利用了HBase數據庫的列存儲特性,實現簡單;但是,因為大對象數據的容量比較大,所以存儲到一個列簇中的大對象難以避免的會經常進行compact操作和split操作,造成讀寫性能不佳。
2) 基于HDFS的大對象存儲。為避免頻繁的compact操作和split操作,可以不把大對象直接存儲到HBase數據庫中,而是存儲在HBase所依賴的底層文件系統HDFS中。HDFS文件系統中保存了大對象數據本身,而HBase數據庫內只存儲大對象文件的索引,如此一來就避免了大量的split操作和compact操作,提高了讀寫性能。
在具體實現時,可以直接把大對象數據存放為HDFS文件系統的一個文件,而在HBase數據庫中存儲每個大對象文件的地址。這種實現方式實現簡單,直接利用HDFS文件系統的put命令即可實現;但是因為HDFS文件系統數據塊的限制,可能會產生大量的小文件,所以可能影響HDFS文件系統的讀寫性能,從而間接影響HBase的效率,解決此問題的方法是使用HDFS文件系統自身的sequenceFile[4]。把多個大對象數據保存在一個HDFS文件系統的sequenceFile文件中,并將sequenceFile文件的鏈接地址和每個大對象的偏移量存儲在HBase數據庫內。這種方式避免了大量的split操作和compact操作,但由于要存儲每個大對象的偏移量,所以不利于管理。
3) 大對象存儲在定制的HBase列簇中。HBase數據庫的列簇可以進行定制,以控制在往存儲大對象的列簇中插入數據時不執行compact操作。參數hbase.hstore.compaction.min可以定制compact操作,當某region內HFile文件的數量超過此參數的值時,會檢查是否進行compact操作,所以對于存儲大對象數據的列簇,可以將此參數的值設置得大一些,這樣在對此列簇進行寫入操作時就不會頻繁地進行compact操作。這種實現方式的優點是將存儲大對象的列簇和存儲結構化數據的列簇分開,設置不同的hbase.hstore.compaction.min參數值,實現方便;缺點在于只解決了compact操作帶來的影響,并未解決split操作的影響[5]。定制compact操作的示意如圖2所示。
4 結論
數據中心存儲方案范文第4篇
CRM是企業的核心生產運營系統, 在大型企業中數據量巨大, 為提升系統的性能引入分布式數據存儲架構, 采用分布式數據架構, 將傳統的單節點數據存儲分布存放到多個數據節點, 上層的應用如何保障事務一致性, 對應用的建設提出很大的挑戰。
二、關鍵業務場景實現方案
目前對于一個分布式系統的事務處理有三種方式:分布式事務兩階段提交、基于Best Efforts 1PC模式的事務以及事務補償機制。
綜合比較分布式事務一致性技術特性, 集中系統采用事務補償機制進行分布式事務處理。
2.1事務一致性場景
從事務完成后, 跨庫數據同步達到數據最終一致時間, 需要考慮時效要求類型如下:
典型業務場景要求數據最終一致的時效如下:
2.2關鍵業務場景實現方案
事務實現方案: (表2)
2.2.1訂單提交
調整數據保存方案, 將一次訂單提交涉及的訂單數據、客戶資料數據保存到同一數據節點, 將跨數據節點事務調整為單數據節點事務, 規避分布式事務。
場景說明:
客戶訂單提交, 作為一個整體提交
按現有數據存儲模式, 訂單提交需保存的數據涉及訂單中心、客戶資料中心, 存在跨數據節點事務
按現有模式處理, 訂單提交需要作為一個整體, 涉及的數據, 最少考慮也涉及訂單表、檔案表的數據更新或狀態變化
提交數據的下級信息較豐富, 可能做為后續的查詢、展示關鍵信息。如:訂單下級的訂單項等數據, 可能做為后續展示的部分數據。
方案說明:
在訂單庫建立訂單過程表, 將提交的數據都保存在訂單庫, 并且以訂單ID分庫, 規避為單庫內事務。如:
受理直接保存訂單及檔案庫, 需要保持的數據及分片:
訂單, 保存在訂單數據中心訂單表, 根據訂單ID散列的切片;
客戶, 保存在客戶數據中心客戶表, 根據客戶ID散列的切片;
產品實例, 保存在客戶數據中心產品實例表, 根據客戶ID散列的切片
一次訂單提交, 需要保持不同的數據庫節點。
在訂單庫中建立過程表, 將提交的過程數據存放到訂單中心, 并以訂單ID作為分片標識:
訂單, 保存在訂單數據中心訂單表, 根據訂單ID散列的切片;
客戶, 保存在訂單數據中心過程客戶表, 根據訂單ID散列的切片;
產品實例, 保存在訂單數據中心過程產品實例表, 根據訂單ID散列的切片
達到一次訂單提交, 數據保存在同一分片中, 將多數據庫事務, 規避為單數據庫事務。
2.2.2訂單竣工、歸檔
事務拆解, 將事務分解為具有冪等性子執行服務, 通過應用進行異常補償, 保證最終一致。
場景說明:
按現有的數據分片模式, 訂單數據、客戶資料數據存儲的分片不同
訂單竣工, 作為一個整體業務, 需要保證該場景的訂單狀態、流程狀態、客戶資料數據一起更改
方案說明:
將訂單竣工服務, 分解為:訂單節點服務、客戶節點服務、產品檔案節點服務, 進行按順序處理, 最終達到整個訂單竣工的完成。
對訂單表增加一些事務ID、事務狀態等控制字段, 進行處理過程標記。
有單獨的隊列, 對出現異常的訂單進行重復執行, 達到最后數據一致性。
2.2.3數據同步
較長時間時延, 允許12小時及以上, 并且不具有事務性數據, 可以采用時間戳方式進行數據同步。
場景說明
如:數據同步給ODS, 可以采用時間戳方式。每次數據更新, 同時更新時間戳, 定期通過輪詢等方式將數據抽取。
三、結束語
分布式事務是一個大話題, 本文就CRM的關鍵場景的分布式存儲情況下的事務處理方案進行初步設計, 對解決分布式事務一致性提供了參考方案, 后續需要不斷的進行細化。
摘要：借鑒優秀互聯網經驗, 大型企業CRM系統引入分布式數據存儲架構, 采用分布式數據架構, 將傳統的單節點數據存儲分布存放到多個數據節點, 上層的應用如何保障事務一致性, 對應用的建設提出很大的挑戰。本文主要就CRM采用分布式數據存儲, 列舉了分布式事務一致性的技術解決方案, 并提出CRM的關鍵場景的分布式存儲情況下的事務處理方案。
關鍵詞：分布式事務,事務一致性,冪等性
參考文獻
數據中心存儲方案范文第5篇
傳統的故障錄波軟件把故障錄波數據存儲在文件中, 把故障啟動時間以及故障啟動類型, 所屬線路等信息存儲在文件名或者文件中?？梢赃M行簡單的增加查詢更新管理。但是對于復雜管理不是很方便而且效率低下, 比如大量數據查詢, 高級查詢, 網絡共享, 遵循IEC-61970實時數據庫標準等。
針對以往以文件形式存儲故障錄波數據的不足, 作者利用BLOB數據庫存儲技術存儲故障錄波數據可以解決上訴問題, 并在visual c++6.0中編程實現。
(一) BLOB數據庫存儲技術簡介
BLOB (Binary Large Object) 稱作“二進制大對象”, 它最早產生于Informix公司生產的世界上第一個支持多媒體管理的關系型數據庫服務器Informix Online, 它的提出旨在通過多媒體數據庫DBMS提供的統一的數據管理與存儲機制, 不僅能處理文字, 數值等簡單對象, 而且能將其他復雜的媒體對象, 諸如:圖象, 視頻, 語音等考慮合成一個數據操作的原子單元 (如:一個事務) 的一部分進行存取, 查詢和恢復。正如RDBMS中常見的字符, 數值, 邏輯等數據類型一樣, BLOB也是一種數據類型, 他支持大數據量的多媒體數據存儲管理。BLOB可分兩種數據類型:TEXT和BYTE型, TEXT型包含不定長的文本字符序列, 如備注, 一篇文章, 源程序代碼, 摘要等;BYTE型是二進制數據流, 可以包含任意對象, 如電子表格, 圖象, 視頻, 語音, 二進制代碼等可數字化數據。每個BLOB字段最大容量可達2GB, 對BLOB數據的存取可以通過擴展的SQL語言來實現。
電力系統的故障錄波數據也可以看做一段比較長的二進制代碼, 那么就可以當作數據庫的一個BLOB字段存儲下來。
(二) 基于不同數據庫引擎的BLOB存儲實現過程
以SQL Server2000為例介紹作者設計適用于故障錄波的數據庫存儲表結構。
如表1所示此表的關鍵字為編號, 或者根據電力系統中一條線路不可能在同一時間啟動兩次這個特點, 另外一種關鍵字是啟動時間和所屬線路。
應用高級語言編程時訪問底層數據庫, 必須通過數據庫引擎驅動, 目前比較流行的三種訪問數據庫的方式為:ODBC, DAO還有ADO, 甚至于更新的ADO.Net。
1. 通過ODBC訪問帶有BLOB字段的數據庫[1]
Visual c++6.0通過CRecordSet這個類與該存儲表綁定, 通過CLongBinary與BLOB字段綁定, 當存儲故障錄波數據時, 必須通過HGLOBAL CLongBinary::m_hData來讀取BLOB字段, 該方法偏向底層, 編程實現困難。Msdn中不推薦使用。
2. 通過DAO訪問帶有BLOB字段的數據庫
DAO與ODBC沒有太多的不同, DAO中CDaoRecordset和CByteArray相當于ODBC中的CRecordset和CLongBinary, 但缺點就是不支持多線程訪問數據庫, 這給編程帶來不便, 但由于DAO本身就是一組COM接口, 加上MFC的封裝, 在很大程度上會簡化編程。
3. 通過ADO訪問帶有BLOB字段的數據庫
ADO是為Microsoft最新和最強大的數據訪問接口OLE DB而設計的, 是一個便于使用的應用程序層。OLE DB為任何數據源都提供了高性能的訪問, ADO在關鍵的Internet方案中使用最少的網絡流量, 并且在前端和數據源之間使用最少的層數, 這為作者在實現過程中通過ADO高效的訪問網絡數據庫提供保障。同時ADO也支持多線程。
在ADO中通過Connection與數據庫建立連接, 接著通過Command進行擴展的sql語言操作, 然后通過Recordeset與表格綁定, 最后通過Fieled與字段比如BLOB字段綁定。
比較三種方法, ADO的優勢不言而喻, 作者最后選用ado+sql server 2000作為數據庫后臺。
如上圖所示, 故障錄波獨立于主線程之外, 在故障錄波的時候, 主線程也可以對數據進行操作, 至于多線程之間的協調與BLOB存儲的細節, 這里就不詳細介紹了。
(三) 與傳統取文件形式故障錄波的比較分析
1. 從存效率進行比較分析
作者做了一個實驗, 從查找, 讀取, 存儲三個方面比較文件與數據庫存儲的不同, 結果如下表所示。
由表2可以知道除了存儲以外, 數據庫其他兩項操作都要優于文件形式, 特別指出對于查找因為文件形式是以遍歷算法進行查找不同于數據庫優化的select操作, 隨著故障錄波記錄數的增加, 這兩者的區別會越來越明顯。而對于存儲平均每條記錄的存取時間不超過一個工頻周期, 所以數據庫存儲慢的弱點對于故障錄波不造成負面影響。
2. 從可靠性進行比較分析
文件在數據庫存儲中只是作為一個簡單的二進制流存儲對象, 不支持數據完整性檢查, 也不支持備份策略, 也不支持事件觸發。不同于文件存儲, 以sql server 2000為例, 其支持數據完整性檢查, 支持自動備份策略, 支持事件觸發?？梢杂行У靥岣吖收箱洸〝祿鎯Φ目煽啃?。
3. 從網絡共享及安全性進行比較分析
以C/S模型為例, 其中故障錄波數據采集為Serive端, 數據共享查詢為Client端。文件形式的網絡共享一般應用tcp/ip中的ftp協議, 該方法只是簡單的網絡共享, 很難進行查詢更新等操作, 而且因為是以明文傳輸, 如果不對傳輸文件進行加密的話, 很有可能在網絡上被監聽破譯。
以數據庫形式的網絡共享, 不是簡單的數據共享, 它支持sql語言查詢以及身份校驗, 而且支持SSL加密, 提高數據在網絡上傳輸的安全性。
(四) 結束語
應用于故障錄波數據的BLOB數據庫存儲技術無論從存儲效率, 管理維護, 可靠性還有網絡共享與安全都要明顯優于文件形式的保存, 也為故障錄波裝置上傳故障錄波記錄遵循IEC-61970實時數據庫標準提供技術支持。這都依賴于Microsoft提供的ADO+SQL Server強大的應用程序級接口。
參考文獻