????? 應一個朋友的承諾，整理一下當前業界存在的幾種優秀的分布式系統。特別對淘寶的后臺系統做了一些分析，看看在未來的幾年，symantec能夠在未來的云計算，云存儲的浪潮中，機會點在哪里? 當然,這里主要指的是技術切入點.
一? 眼下業界存在的幾種分布式系統
| Company using | Distributed Filesystem | Master Node (Y/N) |
| GFS&Bigtable | Y | |
| Amazon | Dynamo | N |
| Microsoft | Azure | Y |
| Yahoo | PNUTS | Y |
有中心節點的分布式架構：
無中心節點的分布式系統架構:
???? 眼下對數據訪問的幾大問題： 高吞吐，高并發，低延遲
幾個文件系統的分析：
GFS&Bigtable
GFS主要有八個特點：
??? 1? 大文件和大數據塊：數據文件的大小普遍在GB級別，并且其每一個數據塊默認大小為64MB，這樣做的優點是降低了元數據的大小，從而能使Master節點能夠非常方便地將元數據都放置在內存中以提升訪問效率。
??? 2? 操作以加入為主：文件非常少會被刪減或者覆蓋，通常僅僅是進行加入或者讀取操作，這樣能充分考慮到硬盤線性吞吐量大，但隨機讀寫慢的特點。
??? 3? 支持容錯：首先，盡管當時為了設計方便，採用了單Master的方案，可是整個系統會保證Master節點會有其相相應的替身（Shadow），以便于當Master節點出現故障
??? 4? 時進行切換。其次，在Chunk層，GFS已經在設計上將節點失敗視為常態，所以能非常好地處理Chunk節點失效的問題。
??? 5? 高吞吐量：盡管以單個節點來看，GFS的性能不管是從吞吐量還是延遲都非常普通，但因為其支持上千的節點，所以總的數據吞吐量是非常驚人的。
??? 6? 保護數據：文件被切割成固定尺寸的數據塊以便于保存，并且每一個數據塊都會被系統至少復制三份。
??? 7? 擴展能力強：因為元數據偏小，使得一個Master節點能控制和管理上千個存數據的Chunk節點。
??? 8? 支持壓縮：對于那些稍舊的文件，能夠通過對它進行壓縮，來節省硬盤空間，并且壓縮率非常驚人，有時甚至接近90%。
??? 9? 基于用戶空間：GFS主要執行于系統的用戶空間（User Time），盡管在效率方面，用戶空間比內核空間略低，可是更便于開發和測試，還有，就是能更好利用Linux的自帶的一些POSIX API。?
????? 因為GFS主要是為了存儲海量搜索數據而設計的，所以它在吞吐量（Throughput）和伸縮性（Scalability）這雙方面表現非常優異，可謂業界的“翹楚”，可是因為其主要以64MB數據塊形式存儲，所以在隨機訪問方面速度并不優秀，盡管這點可謂是它的“軟肋”，可是這本身也是其當初為了吞吐量和伸縮性所做的權衡。
?
二? 淘寶分布式數據服務系統的分析和思考
三? symantec的機會點
未來幾年中，symantec做為業界率先的軟件提供商，機會點在哪里？
這里面有兩關，必須過，一個是數據安全性，一個是收費模式（事實上就是商業模式）
數據安全性，能夠用一個比喻來完畢，非常早曾經，才出現銀行這個概念，可是在美國西部，銀行常常被打劫，大家的錢都被搶走。可是隨著銀行的安全的提高，如今，大家都已經非常喜歡的把錢放入銀行。通過這個比喻，我們能夠看到，事實上，一方面，我們確實要加強云端的數據安全性，不能再傳輸以及存儲計算過程中被偷窺，篡改，和丟失。另外一個，須要培養客戶對云端的信心，這個就須要比較長的時間了。
安全軟件，無疑是symantec的強項。 在云端，詳細怎樣保護數據，可能又須要非常長的一個篇幅來探討這個問題了。我相信symantec在這個方向是，是肯定大有作為的。
再看一看商業模式的問題，早在2002年，沃達豐就已經有過這樣的概念的提出，極力希望能夠將云設備掛在運營商的后端，然后向前端提供各種服務。也就比較相似亞馬遜的EC2，PAAS。可是，關鍵問題來了，沒有找到盈利點。這個游戲須要全部人得到優點，才可能玩的下去。因此，這個時候須要一個比較好的游戲規則。
因此，我們能夠看到：運營商提供的是接入云端的網絡，設備商提供的是大量的計算 存儲和網絡資源，而symantec可繼續在軟件上面大作文章。比方：幫助淘寶等 完畢底層軟件的構筑（與SSD裸設備直接讀寫，去掉文件系統那一層，速度能夠提高5-6倍。業界成功的有 百度的MySQL在SSD上的應用 ，通過改動MySQL存儲引擎，實現了MySQL Flashcache的功能，通過軟件與硬件結合的方式，實現了SSD性能的最大化利用，在SSD應用的方面，百度走在了國內同行的前面。） ，完畢統一的平臺管理
最后就是接入軟件的駕馭：主要是瀏覽器???? 以及?? client與云端的通信軟件
經過這一系列的分析，我們能夠看到，不管是哪一種分布式系統，都是以 應用為中心 ，環繞它展開：便有了數據可用性，數據安全性，數據的讀寫效率，以及方便的管理，自己主動化的
References：
Key Value 數據模型:
Key-value這樣的數據模型在結構方面和傳統的關系型相比較簡單，有點相似常見的HashTable，一個Key相應一個Value，可是其能提供非常快的查詢速度、大的數據存放量和高并發地操作，并非常適合通過主鍵（Key）來對數據進行查詢和改動等操作，盡管不支持復雜的操作，可是能夠通過上層的開發來彌補這個缺陷。
http://forchenyun.javaeye.com/blog/ 744935
http://www.ibm.com/developerworks/cn/opensource/os-cn-cassandra/
EAV 數據模型： Entity – Attribute – Value 的縮寫，是數據庫模型的一種，使用eav建模的優點是能夠動態為數據模型添加或移除屬性。比方: 最早用于醫學用途，醫生在就診時須要記錄非常多病人的參數，如體溫，年齡，過敏藥等情況，而這些參數并非每一個病人都須要記錄的。
http://en.wikipedia.org/wiki/Entity-attribute-value_model
ER數據模型: 數據庫模型，數據之間的relation
NoSQL（非關系型的數據庫）: 隨著互聯網web2.0站點的興起，傳統的關系數據庫在應付web2.0站點，特別是超大規模和高并發的SNS類型的web2.0純動態站點已經顯得力不從心，暴露了非常多難以克服的問題，而非關系型的數據庫則因為其本身的特點得到了非常迅速的發展。
1、High performance - 對數據庫高并發讀寫的需求
???? web2.0站點要依據用戶個性化信息來實時生成動態頁面和提供動態信息，所以基本上無法使用動態頁面靜態化技術，因此數據庫并發負載非常高，往往要達到每秒上萬次讀寫請求。關系數據庫應付上萬次SQL查詢還勉強頂得住，可是應付上萬次SQL寫數據請求，硬盤IO就已經無法承受了。事實上對于普通的BBS站點，往往也存在對高并發寫請求的需求。
2、Huge Storage - 對海量數據的高效率存儲和訪問的需求
對于大型的SNS站點，每天用戶產生海量的用戶動態，以國外的Friendfeed為例，一個月就達到了2.5億條用戶動態，對于關系數據庫來說，在一張2.5億條記錄的表里面進行SQL查詢，效率是極其低下乃至不可忍受的。再比如大型web站點的用戶登錄系統，比如騰訊，盛大，動輒數以億計的帳號，關系數據庫也非常難應付。
3、High Scalability && High Availability- 對數據庫的高可擴展性和高可用性的需求
????? 在基于web的架構其中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，你的數據庫卻沒有辦法像web server和app server那樣簡單的通過加入很多其它的硬件和服務節點來擴展性能和負載能力。對于非常多須要提供24小時不間斷服務的站點來說，對數據庫系統進行升級和擴展是非常痛苦的事情，往往須要停機維護和數據遷移，為什么數據庫不能通過不斷的加入服務器節點來實現擴展呢？
如今主流的NoSQL數據庫有BigTable、HBase、Cassandra、SimpleDB、CouchDB、MongoDB和Redis等。
CAP理論：
2000年，Eric Brewer教授在ACM分布式計算年會上指出了著名的 CAP理論 ：
Brewer, E. A. 2000. Towards robust distributed systems. In Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing (July 16-19, Portland, Oregon)
即分布式系統 不可能滿足 一致性 ( C: Consistency)， 可用性 ( A : Availability)和 分區容錯性 ( P : Tolerance of network Partition)這三個需求。
大約兩年后，Seth Gilbert 和 Nancy lynch兩人證明了CAP理論的正確性：
Gilbert , S., Lynch, N. 2002. Brewer's conjecture and the feasibility of consistent, available, partition-tolerant Web services. ACM SIGACT News 33(2)
盡管關系型數據庫已經在業界的數據存儲方面占領不可動搖的地位，可是因為其天生的幾個限制，比方擴展困難、讀寫慢、成本高和有限的支撐容量等，使其非常難滿足上面這幾個需求。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
