無單點故障的存儲架構

『壹』 藍鯨集群文件系統(BWFS)的功能特點

1.異構平台文件級數據共享--採用全局命名空間，支持Windows/Linux/Mac操作系統平台間的文件級數據共享。
2.卓越的性能優勢--採用直接數據存取模式和帶外（out-of-band）數據傳輸架構，最大限度發揮SAN環境的帶寬和性能優勢，這一優勢在配合高端存儲系統和大規模存儲環境下表現得更加淋漓盡致。
3.系統支持多文件系統、多存儲策略，從而能更靈活支持用戶不同類型應用的不同存儲需求。
4.強大的可擴展能力--支持高達ZB級的系統存儲容量和2PB的巨型文件，支持上億規模的目錄和文件數量。通過增加存儲設備，系統可以在線擴展存儲容量、IO帶寬和負載能力。
5.企業級的數據可靠性--擁有多項專利技術的SAN文件系統BWFS，通過文件系統日誌和快速FSCK以及獨特的文件級故障隔離技術和多文件系統支持，為用戶提供最大程度的數據可靠性保證。通過歷經上百個大型數據應用項目的長期穩定運行和經驗積累，現已成為BWFS數據可靠性的信心來源。
6.系統高可用能力--採用冗餘架構設計的MDC，配合全冗餘的SAN架構，支持FC和iSCSI環境下的Multipath配置，從而實現存儲系統無單點故障，確保存儲系統整體連續運行。
7.系統具有客戶端和元數據控制器端智能故障檢測與性能計數器功能，既可以幫助用戶定位多種故障原因，又可以定位和分析IO特徵，從而進行性能分析和優化。系統內置的抗碎片分配演算法和在線碎片整理工具，讓用戶不必擔心系統長期運行碎片化的問題。
8.支持配額(quota)、ACL、快照、數據遷移介面等豐富的數據管理功能，也能配合第三方產品形成持續數據保護，數據歸檔等解決方案。
9.靈活的存儲方案配置：支持第三方盤陣，並且在多盤陣的環境中，既可以通過存儲虛擬化將所有存儲空間（LUN）虛擬成單一存儲空間使用，也可以通過多文件系統支持，將不同的LUN獨立成不同的文件系統使用，方便用戶根據需求配置靈活的解決方案。內置原生多路徑支持，不必依賴盤陣多路徑軟體就可以實現多路徑功能，使得用戶在盤陣和操作系統平台選擇上更加靈活。
.支持4Gb/s或2Gb/s的高性能硬碟和高容量SATA硬碟混用，滿足了分層存儲和ILM解決方案的需求。

『貳』 運用哪幾種方法可以解決存儲過程的數據安全問題

在這個信息爆炸的年代，現代人每天不論於公於私， 都面臨必須經手大量數字信息、 而在數據安全問題上會出現各種麻煩；另一方面， 隨著數據量的增加，人們對存儲認識程度也日益加深， 特別是企業對於存儲過程中數據安全問題尤為關注。一個穩定、 安全、可靠的存儲基礎架構對企業來說是必不可少的。 企業的信息系統不可避免地受到來自外界的安全危脅， 包括自然災害、網路、硬體、軟體等方面，也包括人員的操作失誤。 數據存儲的任何失誤都可能給企業帶來巨大的經濟損失。 隨著數據價值不斷提升，以及存儲網路化不斷發展， 數據遭受的安全威脅日益增多，若無存儲安全防範措施， 一旦攻擊者成功滲透到數據存儲系統中， 其負面影響將是無法估計的。這要求企業在特定存儲系統結構下， 從存儲安全性綜合考慮。 而企業在業務運作的過程中最常面臨的存儲安全問題， 主要是由自然災害，網路、硬體，人員的操作失誤這幾方面引起的。 自然災害導致數據存儲安全 首先，這個不是一個人為的行為， 大量的數據存儲在企業的伺服器存儲系統中， 業務在運營中由於停電或是數據傳輸過程中的線路突然短路導致的數 據的丟失情況，對於企業是一個不小的損失，在這種狀態下， 由於自然災害原因導致企業數據的丟失可以說對於一個企業的數據信 息是一個很大的安全威脅，系統的正常運行，資料庫的合理優化， 操作人員的完善的操作程序都確保數據的穩定安全，而突發的停電、 火災以及後備電源的不到位對於中小企業是時常面臨的問題， 同時數據的存儲安全成為面對該情況時必須要解決的問題， 也是企業及時需要應對的措施，保證數據的安全， 但如何面對該情況應對企業數據的存儲安全呢？ 網路硬體 其次， 企業數據的硬體環境方面的問題也會導致存儲過程中數據安全， 眾所周知信息化快速發展的今天，硬體的更新換代速度之快， 從而使得企業的傳統的存儲環境已經難以應對如今海量的數據需求， 企業也要升級換代才可以適應現在數據存儲的環境要求。 硬體環境的老化導致傳輸速率的降低， 同時網路的優化也需要良好的硬體環境作為基礎， 在傳輸數據的過程中如果數據量過於龐大， 而企業的硬體環境沒有改善那麼網路的延遲導致系統的崩潰， 從而丟失數據會造成巨大的經濟損失，而對於這些方面， 就需要企業根據業務發展的需要有針對性地升級存儲伺服器的配置， 提高網路的良性環境，保證存儲過程數據安全。 人員的操作失誤 「金無足赤，人無完人」 是對於當今任何企業在數據管理人員方面的一句良言， 每個人在工作的過程中不可避免的犯錯誤或者在操作上失誤， 特別是對於從事資料庫管理工作的人員，數據量之大， 系統運行之繁瑣，都會給工作中帶來不必要的失誤， 從而對於企業的數據上的安全和完整性存在危脅， 同時中小企業的數據管理人員還肩負存儲系統的運維工作， 這就對其數據存儲過程中的安全性提出了更高的要求， 面對著企業存儲過程數據安全問題，應該如何的解決， 採取什麼樣的措施保證數據的安全是擺在每個企業面前的主要問題， 數據是企業運營的核心， 強大的數據的支持保障企業在市場中能夠乘風破浪， 如何解決存儲過程數據安全問題， 下面針對以上的問題給以簡單的建議。 一般而言，解決存儲過程中的數據安全問題， 企業有很多可以採用的方案： 異地備份可以避免發生自然災害時的數據損失；採用RAID( 獨立磁碟冗餘陣列)可以減少磁碟部件的損壞；採用鏡像技術 可以減少存儲設備損壞；快照可以迅速恢復遭破壞的數據， 減少宕機損失。 而這些技術採用可以很好的應對企業面臨的自然災害，網路、硬體， 人員的操作失誤這幾方面引起的數據的安全問題。 異地備份 異地備份是保護數據的最安全的方式，無論發生什麼情況自然災害， 那怕是火災、地震，當其他保護數據的手段都不起作用時， 異地容災的優勢就體現出來了，異地備份問題在於速度和成本， 這要求擁有足夠帶寬的網路連接和優秀的數據復制管理軟體。 通常狀態下主要三方面實現異地備份，一是基於磁碟陣列， 通過軟體的復制模塊，實現磁碟陣列之間的數據復制， 這種方式適用於在復制的兩端具有相同的磁碟陣列。 二是基於主機方式，這種方式與磁碟陣列無關。 三是基於存儲管理平台，它與主機和磁碟陣列均無關。 RAID RAID系統使用許多小容量磁碟驅動器來存儲大量數據， 並且使可靠性和冗餘度得到增強。對計算機來說， 這樣一種陣列就如同由多個磁碟驅動器構成的一個邏輯單元。 所有的RAID系統共同的特點是「熱交換」能力： 用戶可以取出一個存在缺陷的驅動器，並插入一個新的予以更換。 對大多數類型的RAID來說，不必中斷伺服器或系統， 就可以自動重建某個出現故障的磁碟上的數據。 鏡像 這個技術是針對如果故障發生在異地分公司，可以使用鏡像技術， 進行不同卷的鏡像或異地卷的遠程鏡像， 或採用雙機容錯技術自動接管單點故障機， 保證無單點故障和本地設備遇到不可恢復的硬體毀壞時， 仍可以啟動異地與此相同環境和內容的鏡像設備， 以保證服務不間斷。當然，這樣做必然會提升對設備的投資力度。 快照 在數據保護技術中，快照技術(snapshot) 是極為基礎和熱門的技術之一，應用在很多存儲過程中， 比如數據復制和備份都在使用這種技術。 IBM的FlashCopy、IBM NAS的PSM軟體以及VERITAS的FlashSnap軟體 都是快照技術的代表。快照可以迅速恢復遭破壞的數據， 減少宕機損失， 可以針對與資料庫管理人員在操作中的失誤進行數據恢復。 綜述： 對於企業在存儲過程中的數據安全問題，還有很多解決的方案， 存儲安全固然十分重要， 但是存儲安全只是數據中心整個安全解決方案的一個組成部分。 安全是一個內涵很廣泛的話題， 存儲在業務流程中扮演的並非是主角，但確實是關鍵角色， 因為存儲包含了公司絕大部分記錄，如果沒有存儲， 很多業務流程將沒法繼續。因此， 對於面對存儲過程數據安全問題每個企業應該注視起來， 投入更多的精力，數據是一個企業的核心競爭力， 安全強大的數據是企業騰飛的保證，存儲技術的發展， 硬體環境的完善相信會給企業數據安全無疑提供強有力的支持。

『叄』 分布式存儲技術有哪些

中央存儲技術現已發展非常成熟。但是同時，新的問題也出現了，中心化的網路很容易擁擠，數據很容易被濫用。傳統的數據傳輸方式是由客戶端向雲伺服器傳輸，由伺服器向客戶端下載。而分布式存儲系統QKFile是從客戶端傳送到 N個節點，然後從這些節點就近下載到客戶端內部，因此傳輸速度非常快。對比中心協議的特點是上傳、下載速度快，能夠有效地聚集空閑存儲資源，並能大大降低存儲成本。

在節點數量不斷增加的情況下，QKFile市場趨勢開始突出，未來用戶數量將呈指數增長。分布式存儲在未來會有很多應用場景，如數據存儲，文件傳輸，網路視頻，社會媒體和去中心化交易等。網際網路的控制權越來越集中在少數幾個大型技術公司的手中，它的網路被去中心化，就像分布式存儲一樣，總是以社區為中心，面向用戶，而分布式存儲就是實現信息技術和未來網際網路功能的遠景。有了分布式存儲，我們可以創造出更加自由、創新和民主的網路體驗。是時候把網際網路推向新階段了。

作為今年非常受歡迎的明星項目，關於QKFile的未來發展會推動互聯網的進步，給整個市場帶來巨大好處。分布式存儲是基於網際網路的基礎結構產生的，區塊鏈分布式存儲與人工智慧、大數據等有疊加作用。對今天的中心存儲是一個巨大的補充，分布式時代的到來並不是要取代現在的中心互聯網，而是要使未來的數據存儲發展得更好，給整個市場生態帶來不可想像的活力。先看共識，後看應用，QKFile創建了一個基礎設施平台，就像阿里雲，阿里雲上面是做游戲的做電商的視頻網站，這就叫應用層，現階段，在性能上，坦白說，與傳統的雲存儲相比，沒有什麼競爭力。不過另一方面來說，一個新型的去中心化存儲的信任環境式非常重要的，在此環境下，自然可以衍生出許多相關應用，市場潛力非常大。

雖然QKFile離真正的商用還有很大的距離，首先QKFile的經濟模型還沒有定論，其次QKFile需要集中精力發展分布式存儲、商業邏輯和 web3.0，只有打通分布式存儲賽道，才有實力引領整個行業發展，人們認識到了中心化存儲的弊端，還有許多企業開始接受分布式存儲模式，即分布式存儲 DAPP應用觸達用戶。所以QKFile將來肯定會有更多的商業應用。創建超本地高效存儲方式的能力。當用戶希望將數據存儲在QKFile網路上時，他們就可以擺脫巨大的集中存儲和地理位置的限制，用戶可以看到在線存儲的礦工及其市場價格，礦工之間相互競爭以贏得存儲合約。使用者挑選有競爭力的礦工，交易完成，用戶發送數據，然後礦工存儲數據，礦工必須證明數據的正確存儲才能得到QKFile獎勵。在網路中，通過密碼證明來驗證數據的存儲安全性。采礦者通過新區塊鏈向網路提交其儲存證明。通過網路發布的新區塊鏈驗證，只有正確的區塊鏈才能被接受，經過一段時間，礦工們就可以獲得交易存儲費用，並有機會得到區塊鏈獎勵。數據就在更需要它的地方傳播了，旋轉數據就在地球范圍內流動了，數據的獲取就不斷優化了，從小的礦機到大的數據中心，所有人都可以通過共同努力，為人類信息社會的建設奠定新的基礎，並從中獲益。

『肆』 Redis 和 Memcached 各有什麼優缺點，主要的應用場景是什麼樣的

Redis的作者Salvatore Sanfilippo曾經對這兩種基於內存的數據存儲系統進行過比較：

1、Redis支持伺服器端的數據操作：Redis相比Memcached來說，擁有更多的數據結構和並支持更豐富的數據操作，通常在Memcached里，你需要將數據拿到客戶端來進行類似的修改再set回去。這大大增加了網路IO的次數和數據體積。在Redis中，這些復雜的操作通常和一般的GET/SET一樣高效。所以，如果需要緩存能夠支持更復雜的結構和操作，那麼Redis會是不錯的選擇。

2、內存使用效率對比：使用簡單的key-value存儲的話，Memcached的內存利用率更高，而如果Redis採用hash結構來做key-value存儲，由於其組合式的壓縮，其內存利用率會高於Memcached。

3、性能對比：由於Redis只使用單核，而Memcached可以使用多核，所以平均每一個核上Redis在存儲小數據時比Memcached性能更高。而在100k以上的數據中，Memcached性能要高於Redis，雖然Redis最近也在存儲大數據的性能上進行優化，但是比起Memcached，還是稍有遜色。

具體為什麼會出現上面的結論，以下為收集到的資料：

1、數據類型支持不同

與Memcached僅支持簡單的key-value結構的數據記錄不同，Redis支持的數據類型要豐富得多。最為常用的數據類型主要由五種：String、Hash、List、Set和Sorted Set。Redis內部使用一個redisObject對象來表示所有的key和value。redisObject最主要的信息如圖所示：

type代表一個value對象具體是何種數據類型，encoding是不同數據類型在redis內部的存儲方式，比如：type=string代表value存儲的是一個普通字元串，那麼對應的encoding可以是raw或者是int，如果是int則代表實際redis內部是按數值型類存儲和表示這個字元串的，當然前提是這個字元串本身可以用數值表示，比如:」123″ 「456」這樣的字元串。只有打開了Redis的虛擬內存功能，vm欄位欄位才會真正的分配內存，該功能默認是關閉狀態的。

1）String

• 常用命令：set/get/decr/incr/mget等；

• 應用場景：String是最常用的一種數據類型，普通的key/value存儲都可以歸為此類；

• 實現方式：String在redis內部存儲默認就是一個字元串，被redisObject所引用，當遇到incr、decr等操作時會轉成數值型進行計算，此時redisObject的encoding欄位為int。

2）Hash

• 常用命令：hget/hset/hgetall等

• 應用場景：我們要存儲一個用戶信息對象數據，其中包括用戶ID、用戶姓名、年齡和生日，通過用戶ID我們希望獲取該用戶的姓名或者年齡或者生日；

• 實現方式：Redis的Hash實際是內部存儲的Value為一個HashMap，並提供了直接存取這個Map成員的介面。如圖所示，Key是用戶ID, value是一個Map。這個Map的key是成員的屬性名，value是屬性值。這樣對數據的修改和存取都可以直接通過其內部Map的Key(Redis里稱內部Map的key為field), 也就是通過 key(用戶ID) + field(屬性標簽) 就可以操作對應屬性數據。當前HashMap的實現有兩種方式：當HashMap的成員比較少時Redis為了節省內存會採用類似一維數組的方式來緊湊存儲，而不會採用真正的HashMap結構，這時對應的value的redisObject的encoding為zipmap，當成員數量增大時會自動轉成真正的HashMap,此時encoding為ht。

3）List

• 常用命令：lpush/rpush/lpop/rpop/lrange等；

• 應用場景：Redis list的應用場景非常多，也是Redis最重要的數據結構之一，比如twitter的關注列表，粉絲列表等都可以用Redis的list結構來實現；

• 實現方式：Redis list的實現為一個雙向鏈表，即可以支持反向查找和遍歷，更方便操作，不過帶來了部分額外的內存開銷，Redis內部的很多實現，包括發送緩沖隊列等也都是用的這個數據結構。

4）Set

• 常用命令：sadd/spop/smembers/sunion等；

• 應用場景：Redis set對外提供的功能與list類似是一個列表的功能，特殊之處在於set是可以自動排重的，當你需要存儲一個列表數據，又不希望出現重復數據時，set是一個很好的選擇，並且set提供了判斷某個成員是否在一個set集合內的重要介面，這個也是list所不能提供的；

• 實現方式：set 的內部實現是一個 value永遠為null的HashMap，實際就是通過計算hash的方式來快速排重的，這也是set能提供判斷一個成員是否在集合內的原因。

5）Sorted Set

• 常用命令：zadd/zrange/zrem/zcard等；

• 應用場景：Redis sorted set的使用場景與set類似，區別是set不是自動有序的，而sorted set可以通過用戶額外提供一個優先順序(score)的參數來為成員排序，並且是插入有序的，即自動排序。當你需要一個有序的並且不重復的集合列表，那麼可以選擇sorted set數據結構，比如twitter 的public timeline可以以發表時間作為score來存儲，這樣獲取時就是自動按時間排好序的。

• 實現方式：Redis sorted set的內部使用HashMap和跳躍表(SkipList)來保證數據的存儲和有序，HashMap里放的是成員到score的映射，而跳躍表裡存放的是所有的成員，排序依據是HashMap里存的score,使用跳躍表的結構可以獲得比較高的查找效率，並且在實現上比較簡單。

2、內存管理機制不同

在Redis中，並不是所有的數據都一直存儲在內存中的。這是和Memcached相比一個最大的區別。當物理內存用完時，Redis可以將一些很久沒用到的value交換到磁碟。Redis只會緩存所有的key的信息，如果Redis發現內存的使用量超過了某一個閥值，將觸發swap的操作，Redis根據「swappability = age*log(size_in_memory)」計算出哪些key對應的value需要swap到磁碟。然後再將這些key對應的value持久化到磁碟中，同時在內存中清除。這種特性使得Redis可以保持超過其機器本身內存大小的數據。當然，機器本身的內存必須要能夠保持所有的key，畢竟這些數據是不會進行swap操作的。同時由於Redis將內存中的數據swap到磁碟中的時候，提供服務的主線程和進行swap操作的子線程會共享這部分內存，所以如果更新需要swap的數據，Redis將阻塞這個操作，直到子線程完成swap操作後才可以進行修改。當從Redis中讀取數據的時候，如果讀取的key對應的value不在內存中，那麼Redis就需要從swap文件中載入相應數據，然後再返回給請求方。 這里就存在一個I/O線程池的問題。在默認的情況下，Redis會出現阻塞，即完成所有的swap文件載入後才會相應。這種策略在客戶端的數量較小，進行批量操作的時候比較合適。但是如果將Redis應用在一個大型的網站應用程序中，這顯然是無法滿足大並發的情況的。所以Redis運行我們設置I/O線程池的大小，對需要從swap文件中載入相應數據的讀取請求進行並發操作，減少阻塞的時間。

對於像Redis和Memcached這種基於內存的資料庫系統來說，內存管理的效率高低是影響系統性能的關鍵因素。傳統C語言中的malloc/free函數是最常用的分配和釋放內存的方法，但是這種方法存在著很大的缺陷：首先，對於開發人員來說不匹配的malloc和free容易造成內存泄露；其次頻繁調用會造成大量內存碎片無法回收重新利用，降低內存利用率；最後作為系統調用，其系統開銷遠遠大於一般函數調用。所以，為了提高內存的管理效率，高效的內存管理方案都不會直接使用malloc/free調用。Redis和Memcached均使用了自身設計的內存管理機制，但是實現方法存在很大的差異，下面將會對兩者的內存管理機制分別進行介紹。

Memcached默認使用Slab Allocation機制管理內存，其主要思想是按照預先規定的大小，將分配的內存分割成特定長度的塊以存儲相應長度的key-value數據記錄，以完全解決內存碎片問題。Slab Allocation機制只為存儲外部數據而設計，也就是說所有的key-value數據都存儲在Slab Allocation系統里，而Memcached的其它內存請求則通過普通的malloc/free來申請，因為這些請求的數量和頻率決定了它們不會對整個系統的性能造成影響Slab Allocation的原理相當簡單。 如圖所示，它首先從操作系統申請一大塊內存，並將其分割成各種尺寸的塊Chunk，並把尺寸相同的塊分成組Slab Class。其中，Chunk就是用來存儲key-value數據的最小單位。每個Slab Class的大小，可以在Memcached啟動的時候通過制定Growth Factor來控制。假定圖中Growth Factor的取值為1.25，如果第一組Chunk的大小為88個位元組，第二組Chunk的大小就為112個位元組，依此類推。

當Memcached接收到客戶端發送過來的數據時首先會根據收到數據的大小選擇一個最合適的Slab Class，然後通過查詢Memcached保存著的該Slab Class內空閑Chunk的列表就可以找到一個可用於存儲數據的Chunk。當一條資料庫過期或者丟棄時，該記錄所佔用的Chunk就可以回收，重新添加到空閑列表中。從以上過程我們可以看出Memcached的內存管理制效率高，而且不會造成內存碎片，但是它最大的缺點就是會導致空間浪費。因為每個Chunk都分配了特定長度的內存空間，所以變長數據無法充分利用這些空間。如圖 所示，將100個位元組的數據緩存到128個位元組的Chunk中，剩餘的28個位元組就浪費掉了。

Redis的內存管理主要通過源碼中zmalloc.h和zmalloc.c兩個文件來實現的。Redis為了方便內存的管理，在分配一塊內存之後，會將這塊內存的大小存入內存塊的頭部。如圖所示，real_ptr是redis調用malloc後返回的指針。redis將內存塊的大小size存入頭部，size所佔據的內存大小是已知的，為size_t類型的長度，然後返回ret_ptr。當需要釋放內存的時候，ret_ptr被傳給內存管理程序。通過ret_ptr，程序可以很容易的算出real_ptr的值，然後將real_ptr傳給free釋放內存。

Redis通過定義一個數組來記錄所有的內存分配情況，這個數組的長度為ZMALLOC_MAX_ALLOC_STAT。數組的每一個元素代表當前程序所分配的內存塊的個數，且內存塊的大小為該元素的下標。在源碼中，這個數組為zmalloc_allocations。zmalloc_allocations[16]代表已經分配的長度為16bytes的內存塊的個數。zmalloc.c中有一個靜態變數used_memory用來記錄當前分配的內存總大小。所以，總的來看，Redis採用的是包裝的mallc/free，相較於Memcached的內存管理方法來說，要簡單很多。

3、數據持久化支持

Redis雖然是基於內存的存儲系統，但是它本身是支持內存數據的持久化的，而且提供兩種主要的持久化策略：RDB快照和AOF日誌。而memcached是不支持數據持久化操作的。

1）RDB快照

Redis支持將當前數據的快照存成一個數據文件的持久化機制，即RDB快照。但是一個持續寫入的資料庫如何生成快照呢？Redis藉助了fork命令的 on write機制。在生成快照時，將當前進程fork出一個子進程，然後在子進程中循環所有的數據，將數據寫成為RDB文件。我們可以通過Redis的save指令來配置RDB快照生成的時機，比如配置10分鍾就生成快照，也可以配置有1000次寫入就生成快照，也可以多個規則一起實施。這些規則的定義就在Redis的配置文件中，你也可以通過Redis的CONFIG SET命令在Redis運行時設置規則，不需要重啟Redis。

Redis的RDB文件不會壞掉，因為其寫操作是在一個新進程中進行的，當生成一個新的RDB文件時，Redis生成的子進程會先將數據寫到一個臨時文件中，然後通過原子性rename系統調用將臨時文件重命名為RDB文件，這樣在任何時候出現故障，Redis的RDB文件都總是可用的。同時，Redis的RDB文件也是Redis主從同步內部實現中的一環。RDB有他的不足，就是一旦資料庫出現問題，那麼我們的RDB文件中保存的數據並不是全新的，從上次RDB文件生成到Redis停機這段時間的數據全部丟掉了。在某些業務下，這是可以忍受的。

2）AOF日誌

AOF日誌的全稱是append only file，它是一個追加寫入的日誌文件。與一般資料庫的binlog不同的是，AOF文件是可識別的純文本，它的內容就是一個個的Redis標准命令。只有那些會導致數據發生修改的命令才會追加到AOF文件。每一條修改數據的命令都生成一條日誌，AOF文件會越來越大，所以Redis又提供了一個功能，叫做AOF rewrite。其功能就是重新生成一份AOF文件，新的AOF文件中一條記錄的操作只會有一次，而不像一份老文件那樣，可能記錄了對同一個值的多次操作。其生成過程和RDB類似，也是fork一個進程，直接遍歷數據，寫入新的AOF臨時文件。在寫入新文件的過程中，所有的寫操作日誌還是會寫到原來老的AOF文件中，同時還會記錄在內存緩沖區中。當重完操作完成後，會將所有緩沖區中的日誌一次性寫入到臨時文件中。然後調用原子性的rename命令用新的AOF文件取代老的AOF文件。

AOF是一個寫文件操作，其目的是將操作日誌寫到磁碟上，所以它也同樣會遇到我們上面說的寫操作的流程。在Redis中對AOF調用write寫入後，通過appendfsync選項來控制調用fsync將其寫到磁碟上的時間，下面appendfsync的三個設置項，安全強度逐漸變強。

• appendfsync no 當設置appendfsync為no的時候，Redis不會主動調用fsync去將AOF日誌內容同步到磁碟，所以這一切就完全依賴於操作系統的調試了。對大多數Linux操作系統，是每30秒進行一次fsync，將緩沖區中的數據寫到磁碟上。

• appendfsync everysec 當設置appendfsync為everysec的時候，Redis會默認每隔一秒進行一次fsync調用，將緩沖區中的數據寫到磁碟。但是當這一次的fsync調用時長超過1秒時。Redis會採取延遲fsync的策略，再等一秒鍾。也就是在兩秒後再進行fsync，這一次的fsync就不管會執行多長時間都會進行。這時候由於在fsync時文件描述符會被阻塞，所以當前的寫操作就會阻塞。所以結論就是，在絕大多數情況下，Redis會每隔一秒進行一次fsync。在最壞的情況下，兩秒鍾會進行一次fsync操作。這一操作在大多數資料庫系統中被稱為group commit，就是組合多次寫操作的數據，一次性將日誌寫到磁碟。

• appednfsync always 當設置appendfsync為always時，每一次寫操作都會調用一次fsync，這時數據是最安全的，當然，由於每次都會執行fsync，所以其性能也會受到影響。

對於一般性的業務需求，建議使用RDB的方式進行持久化，原因是RDB的開銷並相比AOF日誌要低很多，對於那些無法忍數據丟失的應用，建議使用AOF日誌。

4、集群管理的不同

Memcached是全內存的數據緩沖系統，Redis雖然支持數據的持久化，但是全內存畢竟才是其高性能的本質。作為基於內存的存儲系統來說，機器物理內存的大小就是系統能夠容納的最大數據量。如果需要處理的數據量超過了單台機器的物理內存大小，就需要構建分布式集群來擴展存儲能力。

Memcached本身並不支持分布式，因此只能在客戶端通過像一致性哈希這樣的分布式演算法來實現Memcached的分布式存儲。下圖給出了Memcached的分布式存儲實現架構。當客戶端向Memcached集群發送數據之前，首先會通過內置的分布式演算法計算出該條數據的目標節點，然後數據會直接發送到該節點上存儲。但客戶端查詢數據時，同樣要計算出查詢數據所在的節點，然後直接向該節點發送查詢請求以獲取數據。

相較於Memcached只能採用客戶端實現分布式存儲，Redis更偏向於在伺服器端構建分布式存儲。最新版本的Redis已經支持了分布式存儲功能。Redis Cluster是一個實現了分布式且允許單點故障的Redis高級版本，它沒有中心節點，具有線性可伸縮的功能。下圖給出Redis Cluster的分布式存儲架構，其中節點與節點之間通過二進制協議進行通信，節點與客戶端之間通過ascii協議進行通信。在數據的放置策略上，Redis Cluster將整個key的數值域分成4096個哈希槽，每個節點上可以存儲一個或多個哈希槽，也就是說當前Redis Cluster支持的最大節點數就是4096。Redis Cluster使用的分布式演算法也很簡單：crc16( key ) % HASH_SLOTS_NUMBER。

為了保證單點故障下的數據可用性，Redis Cluster引入了Master節點和Slave節點。在Redis Cluster中，每個Master節點都會有對應的兩個用於冗餘的Slave節點。這樣在整個集群中，任意兩個節點的宕機都不會導致數據的不可用。當Master節點退出後，集群會自動選擇一個Slave節點成為新的Master節點。

『伍』 18、以下哪些拓撲結構不會產生單點故障（ ） A）匯流排型 B）環型 C）網狀結構 D）星形

首先要理解什麼是單點故障，單點故障（英語：single point of failure，縮寫SPOF）是指系統中一點失效，就會讓整個系統或者大部分系統無法運作的部件，換句話說，單點故障即會整體或大部分故障。
再從網路結構上來分析，匯流排型 ：匯流排是屬於整個系統的一部分，如果匯流排段了是會影響到所有節點都不能正常使用的。

環型網路（早期的）環形拓撲結構是由多個首尾相連接的中繼器組成，每一個中繼器連接一個工作站，中繼器從一端發送數據從另一端接受數據，環中是單向傳輸數據的（注意是單向劃重點）。所以一個數據從本節點A發送會經過所有節點最終從本節點的B端接收。如果任意一個系統一部分故障都會導致整個網路故障。
星型網路：有一個中心節點，中心節點屬於整個系統的一部分，那中心節點故障了整個網路就出現故障，其他部分故障不影響整個網路。
網狀結構：具有較高的可靠性，某一線路或節點有故障，不會影響整個網路工作。應為每個節點和其他節點都有連線，也稱全網狀。
故本題選擇 C

『陸』 超融合基礎架構（HCI）和傳統基礎架構相比，有什麼優勢

一、架構和資源管理模式對比
如下以SmartX 超融合產品為例，分別給出了下超融合架構和傳統架構的部署區別和資源管理模式區別。

『柒』 雲計算儲存跟傳統的儲存有什麼區別

雲計算儲存跟傳統的儲存區別有:
當雲計算系統運算和處理的核心是大量數據的存儲和管理時，雲計算系統中就需要配置大量的存儲設備，那麼雲計算系統就轉變成為一個雲存儲系統，所以雲存儲是一個以數據存儲和管理為核心的雲計算系統。

由於用戶數量眾多，存儲系統需要存儲的文件將呈指數級增長態勢，這就要求存儲系統的容量擴展能夠跟得上數據量的增長，做到無限擴容，同時在擴展過程中最好還要做到簡便易行，不能影響到數據中心的整體運行，如果容量的擴展需要復雜的操作，甚至停機，這無疑會極大地降低數據中心的運營效率。
雲時代的存儲系統需要的不僅僅是容量的提升，對於性能的要求同樣迫切，與以往只面向有限的用戶不同，在雲時代，存儲系統將面向更為廣闊的用戶群體，用戶數量級的增加使得存儲系統也必須在吞吐性能上有飛速的提升，只有這樣才能對請求作出快速的反應，這就要求存儲系統能夠隨著容量的增加而擁有線性增長的吞吐性能，這顯然是傳統的存儲架構無法達成的目標。
傳統的存儲系統由於沒有採用分布式的文件系統，無法將所有訪問壓力平均分配到多個存儲節點，因而在存儲系統與計算系統之間存在著明顯的傳輸瓶頸，由此而帶來單點故障等多種後續問題，而集群存儲正是解決這一問題，滿足新時代要求的一劑良葯。
雲存儲技術與傳統存儲技術
性能問題。由於數據量的激增，數據的索引效率也變得越來越為人們關注。而動輒上TB的數據。甚至是幾百TB的數據，在索引時往往需要花上幾分鍾的時間。
傳統的存儲技術是把所有數據都當作對企業同等重要和同等有用來進行處理，所有的數據集成到單一的存儲體系之中，以滿足業務持續性需求。但是在面臨大數據時就顯得捉襟見肘：
成本激增。在大型項目中，前端圖像信息採集點過多，單台伺服器承載量有限，就造成需要配置幾十台，甚至上百台伺服器的狀況。這就必然導致建設成本、管理成本、維護成本、能耗成本的急劇增加;
磁碟碎片問題。由於視頻監控系統往往採用回滾寫入方式，這種無序的頻繁讀寫操作，導致了磁碟碎片的大量產生。隨著使用時間的增加，將嚴重的影響整體存儲系統的讀寫性能，甚至導致存儲系統被鎖定為只讀，而無法寫入新的視頻數據;
與傳統存儲相比，雲存儲則具有以下幾點突出的優勢：
量身定製。這個主要是針對於私有雲。雲服務提供商專門為單一的企業客戶提供一個量身定製的雲存儲服務方案，或者可以是企業自己的IT機構來部署一套私有雲服務架構。私有雲不但能為企業用戶提供最優質的貼身服務，而且還能在一定程度上降低安全風險;
成本低。就目前來說，企業在數據存儲上所付出的成本是相當大的，而且這個成本還在隨著數據的暴增而不斷增加。為了減少這一成本壓力，許多企業將大部分數據轉移到雲存儲上，讓雲存儲服務提供商來為他們解決數據存儲的問題。這樣就能花很少的價錢獲得最優的數據存儲服務;
管理方便。其實這一項也可以歸納為成本上的優勢。因為將大部分數據遷移到雲存儲上去後，所有的升級維護任務都是由雲存儲服務提供商來完成，節約了企業存儲系統管理員上的成本壓力。還有就是雲存儲服務強大的可擴展性，當企業用戶發展壯大後，突然發現自己先前的存儲空間不足，就必須要考慮增加存儲伺服器來滿足現有的存儲需求。而雲存儲服務則可以很方便的在原有基礎上擴展服務空間，滿足需求。;
要知道，傳統的存儲模式已經不再適應當代數據暴增的現實問題，如何讓新興的雲存儲發揮它應有的能力，在解決安全、兼容等問題上，我們還需要不斷的努力，而目前，雲計算是一個很好的選擇，作為其核心的雲存儲必將成為未來存儲技術的必然趨勢。

『捌』 選擇軟體定義存儲/分布式存儲還是超融合一體機

肯定選擇分布式存儲，非常強調數據安全性，可以規避很多硬碟、伺服器損壞、靜默數據損毀等常見數據丟失風險。如果是普通的中小企業，主要部署一些靜態網站，存儲需求量不大，對數據安全性要求不高，能夠容忍一定的數據丟失風險的，可以用超融合一體機。我們司負責IT的就10來個人，採用的VMware虛擬機加元核雲分布式統一存儲的方案

『玖』 國內一流的分布式存儲廠商有哪些

杉岩數據是其中之一。

作為一款國產分布式存儲軟體產品，技術架構上採用業內領先的全分布式高可用設計，全平台無單點故障，並且可以提供文件存儲、塊存儲和對象存儲三種不同類型的存儲模塊。

這些存儲模塊可以靈活的組合搭配，提供快速簡便的訪問方式，滿足新一代應用的敏捷開發需求，能夠根據應用的發展進行靈活的彈性擴展。

提供了全語義、跨協議數據訪問，幫助企業打通數據孤島、實現傳統應用間的數據共享，一體化極簡架構與分鍾級擴容、秒級數據檢索，加速企業上雲轉型。在數據安全和價值發掘領域，採用全國密演算法，確保數據絕對的安全。

(9)無單點故障的存儲架構擴展閱讀：

杉岩數據優勢

1、多種數據冗餘模式

杉岩數據提供多副本和糾刪碼兩種數據冗餘策略，多副本策略以數據鏡像的方式提供數據冗餘，確保冗餘數據的完整性，同時也縮短了數據讀取路徑。

2、完善的容災體系

存儲系統支持多站點容災機制、數據跨地域存放、延展集群、非同步災備，保證數據的安全性和最高空間利用率，極大的降低RPO和RTO。

3、數據脫敏

USP採用數據脫敏技術，幫助企業提高安全性和保密等級，防止數據被濫用。同時幫助企業符合安全性規范要求，以及由管理/審計機關所要求的隱私標准。

『拾』 資料庫-架構和資料庫-管理指的是什麼

資料庫架構：

下面是基於SQLserver資料庫來談的。
SQLServer經過這些年的發展，其實已經有很多很好的技術可以使用，如Replication、SSB、Cluster、Mirroring等（可以參考我在SQLServer DBA 三十問和SQLServer 高可用、高性能和高保護延伸 中的一些技術方面的知識），而且這些技術在可靠性方面已經通過了市場的認可，有很多公司在為提高其程序的可靠性、安全性和高效性等方面或多或少的採用了其中的某些技術，以下就我接觸過的這些技術方面的應用，主要針對網站這種流量很大，讀多寫少的應用，就資料庫架構方面做些探討，希望對各位有所幫助，如有不對的地方，歡迎大家指正和交流。

資料庫架構需要考慮的問題：
數據可靠和一致性；
數據容災；
當數據量和訪問壓力變大時，方便擴充；
高度可用，出問題時能及時恢復，無單點故障；
不應因為某一台機器出現問題，導致整網性能的急劇下降；
方便維護。

資料庫管理：

資料庫管理(Database Manager)是有關建立、存儲、修改和存取資料庫中信息的技術，是指為保證資料庫系統的正常運行和服務質量，有關人員須進行的技術管理工作。負責這些技術管理工作的個人或集體稱為資料庫管理員(DBA)。資料庫管理的主要內容有：資料庫的調優、資料庫的重組、資料庫的重構、資料庫的安全管控、報錯問題的分析和匯總和處理、資料庫數據的日常備份. 資料庫的建立：資料庫的設計只是提供了數據的類型、邏輯結構、聯系、約束和存儲結構等有關數據的描述。這些描述稱為數據模式。