**中小站點(diǎn)的前端引用，且不考慮使用的CDN等技術(shù)，假如用戶請求到達(dá)站點(diǎn)以后，前端首先到達(dá)的應(yīng)該是調(diào)度器，調(diào)度器通常是一個nginx，或者是一個haproxy，對大多數(shù)站點(diǎn)使用nginx和haproxy足夠了，為了避免成為單表，
一般做基于keepalived的高可用
**
當(dāng)用戶請求到達(dá)以后，基于站點(diǎn)需要（比如電商類）站點(diǎn)程序會經(jīng)常更新的，但是此前用戶所發(fā)布的文章，還有各種各樣生成的圖片，一般都不會變，除非用戶自己刪除，所以一般都需要單獨(dú)找一個存儲，然后使用url調(diào)用站點(diǎn)上，基于應(yīng)用程序布局以后進(jìn)行顯示的，因此應(yīng)用程序需要經(jīng)常更新的那一部分內(nèi)容是單獨(dú)存放的
圖片需要單獨(dú)存放，所以對于圖片而言，基于某一url，通常是單獨(dú)發(fā)送到一組主機(jī)上，對于圖片內(nèi)容來講，應(yīng)該是可以做緩存的，所以在前端調(diào)度時(shí)，所有靜態(tài)內(nèi)容，應(yīng)該都是能夠基于緩存進(jìn)行加速的因此，.js,css,img結(jié)尾的文件，一般都發(fā)送到同一組服務(wù)器上，這個服務(wù)器通常是緩存服務(wù)器（varnish代表）
為了使命中更高，在使用haproxy或nginx的時(shí)候，需要根據(jù)目標(biāo)url進(jìn)行調(diào)度，這樣調(diào)度以后可以使得命中率提升，為了避免一臺varnish宕機(jī)，導(dǎo)致所有緩存不可用，需要使用一致性hash算法，來實(shí)現(xiàn)hash環(huán)構(gòu)建

**動態(tài)內(nèi)容不能緩存就需要發(fā)往動態(tài)內(nèi)容服務(wù)器，雖然稱為應(yīng)用程序服務(wù)器，但是這上面內(nèi)容，除了動態(tài)內(nèi)容（。jsp之外）一般而言需要隨著更新的還有.cs,.js各種跟網(wǎng)頁本身相關(guān)的文件，而非用戶數(shù)據(jù)，所以通常都在這一類主機(jī)上，
所以這些主機(jī)存放的是站點(diǎn)應(yīng)用程序，以及跟站點(diǎn)本身構(gòu)架相關(guān)的內(nèi)容，js文件，css文件，jsp文件
因此基于varnish反代時(shí)，也需要分別代理的，js文件，css文件，jsp文件存儲應(yīng)該到下面的應(yīng)用程序服務(wù)器
而對圖片存儲到另外一 主機(jī)上（varnish反代只能反代http協(xié)議，所以后端必須是一個http主機(jī)，對這臺主機(jī)來講，如果一臺主機(jī)不足以承載這么多用戶請求，更重要的是，圖片數(shù)量可能會非常大，單臺主機(jī)存儲也是比較難以解決問題，因此需要多臺主機(jī)，也需要負(fù)載均衡，由于是圖片存儲，怎么反代都可以）
**

對此處來講，下面部分也是靜態(tài)內(nèi)容，也可以隨意調(diào)度
但是下面的動態(tài)調(diào)度可不能隨意調(diào)度，對動態(tài)內(nèi)容是需要保存session的，對session而言需要去如何構(gòu)建，
上面是靜態(tài)內(nèi)容
下面是動態(tài)內(nèi)容
圖片內(nèi)容量會非常大，任何單臺主機(jī)都無法解決問題，一次需要使用共享存儲，NFS,SAMBA，但無論是NFS還是SAMBA在單個主機(jī)之上，且不說是單點(diǎn)故障所在，還有網(wǎng)絡(luò)IO和磁盤IO也不足以承擔(dān)龐大訪問量
所以應(yīng)該是一個可以橫向擴(kuò)展的存儲系統(tǒng) ，就是分布式存儲（假設(shè)是一個多臺主機(jī)構(gòu)建的集群，分布式存儲，就是數(shù)據(jù)并不是一臺主機(jī)上存放的，每臺主機(jī)上，都各自存放了整個 數(shù)據(jù)集的一部分，因此前端的主機(jī)，再向后端發(fā)送請求時(shí)，就需要知道數(shù)據(jù)到底在哪臺主機(jī)上，（數(shù)據(jù)由元數(shù)據(jù)和數(shù)據(jù)組成））
可以嘗試把每一個文件的元數(shù)據(jù)不跟數(shù)據(jù)一起存放在節(jié)點(diǎn)上，而是分開存放，找一個節(jié)點(diǎn)用來當(dāng)中心節(jié)點(diǎn)，它知道一共有哪些文件，并且文件位于哪個主機(jī)上，所以這就稱為有中心節(jié)點(diǎn)的架構(gòu)
前端主機(jī)去訪問數(shù)據(jù)時(shí)會首先找元數(shù)據(jù)這臺節(jié)點(diǎn)，它會告訴請求的客戶端，數(shù)據(jù)在哪臺主機(jī)上，于是就去找真正存放數(shù)據(jù)的主機(jī)，如果有30臺主機(jī)，每一臺主機(jī)上都存放了30分之一的數(shù)據(jù)，所以前端大量請求會被30臺主機(jī)均勻分?jǐn)?#xff0c;因此無論是網(wǎng)絡(luò)IO還是磁盤IO的窘境都能得到解決
但是會有新的問題，單點(diǎn)，元數(shù)據(jù)服務(wù)器就成了單點(diǎn)，因此需要做高可用，這個高可用可以嘗試的是，如果可以的話，不共享數(shù)據(jù)就比較麻煩，文件創(chuàng)建時(shí)，第一臺主機(jī)更新，第二臺改如何解決

因此他們兩還需要用到共享存儲，沒有共享存儲就不能把第一臺主機(jī)數(shù)據(jù)更新到第二臺主機(jī)上，確實(shí)有一些解決訪問，比如使用mysql來存元數(shù)據(jù)，把元數(shù)據(jù)放在表當(dāng)中，mysql對于數(shù)據(jù)創(chuàng)建慢，但是讀還可以，如果遇到壓力過大，mysql做主從，所有寫操作發(fā)給主節(jié)點(diǎn)，讀操作發(fā)給從節(jié)點(diǎn)，但是mysql也屬于單點(diǎn)，mysql的單點(diǎn)可以用MHA或者直接使用PCRA集群

使用mysql并不是一種理想的解決方案，但是有些分布式存儲確實(shí)是使用mysql，來解決名稱節(jié)點(diǎn)的宕機(jī)
還有第二種方式，
可以使用zk集群，zookeeper，把數(shù)據(jù)放到zookeeper上，zookper自身也是集群，基于分布式zookeeper的原子協(xié)議，讓數(shù)據(jù)在多節(jié)點(diǎn)之間冗余，任何一個節(jié)點(diǎn)宕機(jī)了不會導(dǎo)致數(shù)據(jù)丟失的，而且zk在數(shù)據(jù)接口上是用文件系統(tǒng)方式展現(xiàn)的，但是非常簡單基于內(nèi)存工作，因此性能不錯，也算是一種解決方案

可以使用所謂的集中式的解決方案，而且世界上各種各樣的分布式解決方案當(dāng)中，應(yīng)該有百分之90以上都是集中式的解決方案，不同的是，有些解決方案使用了mysql做后端存儲，有些是用ZK，也有一些使用其他 的比如redis之類的，這取決于你的程序員開發(fā)時(shí)的需要，
還有一種為了高效直接放到本地內(nèi)存中，這樣就不能與其他共享，只能定期同步到磁盤上去，類似redis持久化一樣，AOF,RDB一樣，一旦出現(xiàn)故障，找一個備用節(jié)點(diǎn)，利用持久化恢復(fù)過來，只要持久化數(shù)據(jù)沒有丟失，但是這個過程會比較慢，可能需要20,30分鐘
類似微博的站點(diǎn)也是經(jīng)常出現(xiàn)問題，每年也有一次的例行維護(hù)，賬號不能創(chuàng)建，有各種各樣的限制，所以任何解決方案都沒有良好的解決機(jī)制，通常也需要一些理性維護(hù)來解決技術(shù)手段無法解決的所有問題，
這是一種方式有集中節(jié)點(diǎn)的解決方案、
分布式系統(tǒng)確實(shí)能把網(wǎng)絡(luò)IO和磁盤IO擴(kuò)散出去

還有一種叫無中心節(jié)點(diǎn)的解決方案，類似于redis的 cluster，把數(shù)據(jù)和元數(shù)據(jù)，數(shù)據(jù)是分散存儲在系統(tǒng)的每一個節(jié)點(diǎn)上的的，但是元數(shù)據(jù)在每個節(jié)點(diǎn)上都有，你可以找到任何一個節(jié)點(diǎn)，都能知道哪些數(shù)據(jù)在哪些節(jié)點(diǎn)上存儲
好處是節(jié)點(diǎn)故障了，客戶端只要能夠知道其他節(jié)點(diǎn)是誰，就能跟此前一樣獲取數(shù)據(jù)，對于這種集群來講的確拜托了單點(diǎn)的束縛，但也有其他問題，
元數(shù)據(jù)的一次更新，需要在多個節(jié)點(diǎn)進(jìn)行同步

另外無論是有中心節(jié)點(diǎn)還是無中心節(jié)點(diǎn)的集群，自身都應(yīng)該擁有這種功能，數(shù)據(jù)自動分片，
所謂數(shù)據(jù)自動分片，代表無論你怎么存數(shù)據(jù)，這個數(shù)據(jù)都不會只存一副副本，不會只存在一個節(jié)點(diǎn)上，
(仍然以中心節(jié)點(diǎn)的解決方案為例，比較好理解)
一般來講用戶需要存數(shù)據(jù)的時(shí)候，會首先向名稱節(jié)點(diǎn)，現(xiàn)在要存數(shù)據(jù)，該存到哪里，名稱節(jié)點(diǎn)會根據(jù)數(shù)據(jù)分布均衡性等或根據(jù)當(dāng)前節(jié)點(diǎn)的空閑性，，各種指標(biāo)的特點(diǎn)，選擇一個主機(jī)，返回給客戶端，客戶端現(xiàn)在就連接到這臺主機(jī)上，通過它的API來發(fā)送數(shù)據(jù)存儲請求
存下來以后，中心節(jié)點(diǎn)主機(jī)一般會告訴存數(shù)據(jù)主機(jī)，把這個數(shù)據(jù)至少冗余一份或多份，冗余到哪個節(jié)點(diǎn)上也是 由中心節(jié)點(diǎn)主機(jī)挑選的，這個文件不止要存一份，還需要發(fā)給集群中的一臺主機(jī)存儲
到底哪個節(jié)點(diǎn)，就需要中心節(jié)點(diǎn)告訴，只要這兩個節(jié)點(diǎn)不同時(shí)故障，這個數(shù)據(jù)就能正常訪問，更重要的是它們還有自動副本檢測功能，為了確保數(shù)據(jù)的安全和可靠性，假如每個文件都有兩個副本，任何一個節(jié)點(diǎn)宕了，就會導(dǎo)致文件就一份了，此時(shí)集群會自動啟動，找其他節(jié)點(diǎn)，把哪些小于指定副本數(shù)量的文件，再重新創(chuàng)建一次，因此有達(dá)到了每個文件有多個副本的條件，不用等到節(jié)點(diǎn)修復(fù)了，，重新上線再創(chuàng)建這個樣子，，可以理解為有自動治愈的功能，
多數(shù)的分布式文件系統(tǒng)都可以這樣子，如果每一個文件都有2個副本，那壞一個沒有問題，有3個副本，壞兩個節(jié)點(diǎn)沒有問題，但是副本數(shù)量越大，浪費(fèi)空間越多，可以理解為文件級別的raid。如果存放下圖片文件，每個都要復(fù)制，這樣的代價(jià)就比較大，所以一般分布式存儲時(shí)，還有兩類管理機(jī)制

第一類風(fēng)格可能只適合存儲大文件，比如視頻站點(diǎn)，一部電影就幾個G，都是大文件，一般這樣都是把大文件切成固定比例的塊，每一塊都當(dāng)做一個單獨(dú)的文件體被單獨(dú)存放和管理，每一塊都有副本，那么元數(shù)據(jù)就知道一個服務(wù)器被分為了幾塊，而塊里有什么數(shù)據(jù)，之間是怎么組織起來的，是有記錄的，每一塊存儲在哪些節(jié)點(diǎn)上都有記錄，所以才可以化整為零才能拼湊起來。
第二種方案，對于某些站點(diǎn)，社交電商，有大量圖片，但每個圖片不會太大，一般幾十K，幾兆，這種就屬于海量的小文件，很可能達(dá)到幾億個，可以創(chuàng)建一個容器，把圖片放到一個個容器了，每個圖片放到哪個節(jié)點(diǎn)的容器，名稱節(jié)點(diǎn)服務(wù)器都會記錄，
找一個理想的折中大小的機(jī)制，來解決，這兩種方式一個是化大為小，一個是積小為大
但是如果一個站點(diǎn)既要存儲大文件又要存儲小文件，如果又需要還是需要分開的，不過有些存儲是的確可以海納百川，比如淘寶的TFS，是用來設(shè)計(jì)存儲淘寶大量圖片的
TFS淘寶開源出來的圖片存儲，
創(chuàng)業(yè)公司一般超過1年的不超過百分之20

這就是分布式存儲的一些基礎(chǔ)邏輯和常見的解決思路，有了分布式存儲，就需要思考一個問題。
存儲用的都是存儲協(xié)議，但nginx向后端反代是http協(xié)議，意味這些存儲需要提供http接口，nginx才能打交道，沒有http接口。(有些分布式存儲還是能輸出http協(xié)議的，但是大多數(shù)是不可能輸出http接口。所以nginx要實(shí)現(xiàn)反代后，還能去存儲上找到文件)
無非就是幾種方式：
1.找一個中間節(jié)點(diǎn)，代理，這個程序一側(cè)代理http，一側(cè)支持存儲，或者是nginx本身也是模塊化的，給它開發(fā)一個模塊，這個模塊能適配這個存儲協(xié)議，增進(jìn)nginx的功能，但需要自己開發(fā)

我們上傳圖片是通過專門的應(yīng)用程序發(fā)布的，程序允許你點(diǎn)擊上傳，意味著動態(tài)站點(diǎn)應(yīng)用，一旦用于要上傳，就需要上傳到分布式系統(tǒng)
這樣前端才能看到數(shù)據(jù)，像這種能存儲在文件系統(tǒng)之上的，都是非關(guān)系型數(shù)據(jù)，非結(jié)構(gòu)化數(shù)據(jù)，（比如發(fā)朋友圈，有圖片有文字，如果沒有什么關(guān)聯(lián)可以存到非關(guān)系型數(shù)據(jù)庫，但是有些數(shù)據(jù)需要嚴(yán)格做事務(wù)的，比如和朋友之間的關(guān)系，用戶信息，還是需要存到關(guān)系型數(shù)據(jù)庫）每一種存儲都需要冗余
對有些數(shù)據(jù)庫來講，可能性能較差，還需要做緩存，任何系統(tǒng)性能差，速度慢，要么換要么就是加中間層

那么有些程序需要發(fā)布，可以基于灰度發(fā)布，可以基于混合模型構(gòu)架
運(yùn)維的日常工作，發(fā)布（腳本），變更（可以使用配置管理系統(tǒng)，ansible），故障處理，去構(gòu)建整個結(jié)構(gòu)的時(shí)間是很少的，可以做個配置管系統(tǒng)，里面保存了整個系統(tǒng)架構(gòu)里面主機(jī)需要用到的配置，任何一主機(jī)出現(xiàn)故障，下了，新主機(jī)上來，配置好地址，配置系統(tǒng)自動連接上，把安裝包等一些程序直接安裝，啟動
以手工勞動為恥，以自動為榮，所以需要一個配置系統(tǒng)里面存儲好整個環(huán)境中每臺主機(jī)的配置，而后它可以去周期檢查每個主機(jī)是否是正確狀態(tài)，還能自動改回來，ansible就是，saltstack
對于大型應(yīng)用來講，這種配置系統(tǒng)是不足以解決需要的。國內(nèi)的BAT，都會有自己的自研系統(tǒng)，到了這種公司首先要學(xué)習(xí)業(yè)務(wù)流程，崗位上的操作

故障處理，需要一個監(jiān)控系統(tǒng)，隨時(shí)監(jiān)控著向集群中的每一個節(jié)點(diǎn)，甚至包括監(jiān)控系統(tǒng)自己，出現(xiàn)故障就報(bào)警，小故障，可以寫一些監(jiān)控系統(tǒng)腳本放那里，或者連接到配置系統(tǒng)，讓二者聯(lián)動起來，對于一些小故障，能夠觸發(fā)腳本或者觸發(fā)配置系統(tǒng)，來完成自動修復(fù)的功能
比如監(jiān)控的一個web服務(wù)停了，先重啟服務(wù)，解決不了，一次不行，再次重啟，第三次就聯(lián)系配置系統(tǒng)，進(jìn)行配置變更，查看是否配置出問題，還有問題可以呼叫人工接入

ansible比較來講還是過于簡單了，企業(yè)中用的比較多的pulic。saltstack，但是在紅帽的推廣下，ansible還是有很大的用武之地的，尤其是在紅帽系統(tǒng)上

分布式的解決方案有非常多，可以在git hub搜索 distrubutable FS，有很多

google，facebook，阿里云等這些大公司需要海量的數(shù)據(jù)存放，因此要么自己把通用解決方案做二次研發(fā)，要么自己從頭構(gòu)建，它們都面臨大數(shù)據(jù)絲帶面臨的問題
1數(shù)據(jù)增長爆炸式，
2信息鏈接呈現(xiàn)越來越復(fù)雜性
3訪問并發(fā)增大
4數(shù)據(jù)結(jié)構(gòu)多樣性（結(jié)構(gòu)化數(shù)據(jù)，非結(jié)構(gòu)化數(shù)據(jù)（日志文件，圖片文件））

對于這些都會帶來巨大挑戰(zhàn)，尤其是數(shù)據(jù)存儲，對于海量數(shù)據(jù)，無論多大中心存儲需要存下來，這個是第一點(diǎn)，
第二存下來以后如何基于IO壓力來讓前端應(yīng)用程序裝載以后，去進(jìn)行分析處理，（把上T的數(shù)據(jù)加入內(nèi)存分析，這在單臺主機(jī)上是簡直無法完成的）
像這種，就有一些思路，如果需要在某些數(shù)據(jù)上排名，不會把數(shù)據(jù)存下來以后再事后慢慢去分析，而是數(shù)據(jù)剛來的時(shí)候直接做好統(tǒng)計(jì)緩存到系統(tǒng)上，比如每個商品有個id在redis中表示，即便是有1000萬個商品，都在做交易，1000萬個商品每一天可能都不止一筆交易，每個交易都在redisincr就可以，不用再去分析將來的記錄
利用前端程序讓其統(tǒng)計(jì)在redis中也不失為一個解決方案，
真正如果需要去分析就需要強(qiáng)大的分布式數(shù)據(jù)存儲和分析工具，首先需要是一個存儲，把數(shù)據(jù)分割存儲到每一個節(jié)點(diǎn)上，每一個節(jié)點(diǎn)上的數(shù)據(jù)最好能自成體系，能夠被單獨(dú)分析，，因此這樣一來，大問題切割成了很多小問題來實(shí)現(xiàn)，hadoop就是類似
一個hadoop早期的平臺構(gòu)成，底層是一個分布式存儲，一個MapReduce，MapReduce就是一個分布式運(yùn)算框架，如果要做一個聚合計(jì)算的話，可以把一個大的聚合計(jì)算，可以拆分成N個小的，每個節(jié)點(diǎn)上只負(fù)責(zé)一部分，但每個節(jié)點(diǎn)上統(tǒng)計(jì)的排名不是最終排名，把每個結(jié)果統(tǒng)計(jì)出來的排名再合并到一塊，重新再來，把一個大問題拆成很多小問題以后，合并成二級的，大問題，再拆小問題，合并成三次的大問題，最終一定能得出結(jié)果來
基于這種邏輯層層切割，層層遞進(jìn)來完成分析的

面臨大數(shù)據(jù)存儲首先應(yīng)該是早期的搜索引擎公司，他們的爬蟲把互聯(lián)網(wǎng)上各家的數(shù)據(jù)爬過來，存下來，需要大量存儲，還需要給這些頁面做關(guān)鍵詞分析，就需要排名關(guān)鍵詞
對于google來講，同一個關(guān)鍵詞可能存在上億的網(wǎng)站上，哪個網(wǎng)站質(zhì)量最好，還需要做很多運(yùn)算，比如這個站點(diǎn)被鏈接次數(shù)，這次出現(xiàn)正在頁面中的次數(shù)，這個詞出現(xiàn)在其他頁面的次數(shù)，這個分析是非常復(fù)雜的部分，

google的這種算法叫page rank，google的創(chuàng)始人有個叫做佩奇，page，算法叫page rank，頁面排名算法，這個是google的最高機(jī)密
google為什么搜索精準(zhǔn)，就是因?yàn)楸澈蟮膒age rank
所以現(xiàn)在大多數(shù)企業(yè)現(xiàn)在面臨的，其實(shí)在google幾年前就已經(jīng)面臨和解決了，后來google把上一代技術(shù)把開源了，發(fā)不了論文，照著整個論文進(jìn)行山寨，hadoop就是這么來的，山寨了google第一代分布式存儲和分布式計(jì)算的思想而來的。
在google內(nèi)部很有可能不用了，也包括容器
docker只是把容器推進(jìn)了，讓容器走進(jìn)了千家萬家，內(nèi)部就把內(nèi)部用的K8S發(fā)布出來了，K8S已經(jīng)成為容器調(diào)度的標(biāo)準(zhǔn)框架，所以google一般出手，就所向披靡

技術(shù)發(fā)展是呈加速態(tài)勢的，好在第一個吃螃蟹的和后面的吃的，花費(fèi)的代價(jià)是不一樣的，所以現(xiàn)在看到的大數(shù)據(jù)處理方案或多或少都有著google的影子，hadoop其實(shí)就是山寨了google的 產(chǎn)品，包括hadoop后來的各種各樣的解決方案，比如HBASE（山寨的google的page table，也是后來google公布的論文）

也不是只有g(shù)oogle一家公司獨(dú)大，另外一家公司也是有高可用關(guān)系的競爭能力的，Amazon，亞馬遜在云計(jì)算領(lǐng)域，連google都比不上，還有一家是FB，facebook，但是歷史積淀太短，一定程度上來講，也是社交媒體公司，facebook最近的技術(shù)也是爆發(fā)一樣，很多產(chǎn)品一旦發(fā)布就立即開源，并貢獻(xiàn)給ASF

目前在全球環(huán)境中可用的開源產(chǎn)品，都是山寨google，或者google貢獻(xiàn)的，要么是亞馬遜的，twitter也在不斷地貢獻(xiàn)出開源工具，使得原來讓哪些開源技術(shù)賺錢的公司黯然失色，比如redhat

大數(shù)據(jù)帶來的挑戰(zhàn)，其實(shí)在十幾年前，搜索引擎公司都已經(jīng)面臨過了，有技術(shù)并不能解決所有問題，商業(yè)模式才是王道，真正早期做搜索引擎的其實(shí)是雅虎，必應(yīng)，這種應(yīng)用就是強(qiáng)者通吃
因此云計(jì)算亞馬遜起來以后，其他公司想起來特別難，
搜索引擎市場占有率，除了我國，google展百分之90以后，其他的加起來不足10.基本上處于壟斷地位，能壟斷就擁有角色支配權(quán)，事實(shí)上并沒有壟斷技術(shù)做太多事情，因?yàn)檫@家公司文化是不作惡
正是因?yàn)檫@種不作惡的文化，才能吸收越來越多的公司合作，就能吸納各家優(yōu)秀先進(jìn)的公司的文化和思想，很多技術(shù)好的人都去了google，google甚至允許70%的時(shí)間完成工作，30%的開發(fā)自己喜歡的產(chǎn)品

我們的存儲和要存的數(shù)據(jù)
傳統(tǒng)的存儲NAS ,SAN，這種存儲都是集中式的，各個服務(wù)器在需要使用數(shù)據(jù)的 時(shí)候，通過集中的交換和網(wǎng)絡(luò)來實(shí)現(xiàn)數(shù)據(jù)存儲，這樣的IO是有限的，無論是網(wǎng)絡(luò)IO還是磁盤IO，更重要的是也不利于擴(kuò)展，無論是磁盤空間，還是磁盤IO還是網(wǎng)絡(luò)IO擴(kuò)展起來及其困難，所以必須要突破這種局面，就出現(xiàn)了分布式存儲，
分布式存儲也有很多挑戰(zhàn)和問題需要解決，這些問題甚至于是不能忽略的，比如
1.節(jié)點(diǎn)之間如何通信，
2.數(shù)據(jù)存儲如何完成
3.數(shù)據(jù)存儲的時(shí)候怎么均衡使得各個節(jié)點(diǎn)都能獲得存儲
4.容錯，一個節(jié)點(diǎn)出現(xiàn)故障百分之一，10個就是百分之10，有100個主機(jī)，幾乎每天都有壞的，如何容錯，就需要是在設(shè)計(jì)初就需要考慮的問題
5.文件系統(tǒng)支持

分布式存儲也只能滿足CAP理論中的兩種
可用性
分區(qū)容錯性
數(shù)據(jù)一致性
要確保我們的系統(tǒng)的可用的，其次分區(qū)容錯性，
數(shù)據(jù)一致，經(jīng)過每個節(jié)點(diǎn)去訪問的數(shù)據(jù)應(yīng)該一致，對于有集中節(jié)點(diǎn)的來講，這個集中節(jié)點(diǎn)能確定數(shù)據(jù)是一致的，如果說是無中心節(jié)點(diǎn)，那就要講弱一致，最終一致性
所以就要求元數(shù)據(jù)存儲足夠高效
數(shù)據(jù)本身要有冗余

分布式文件系統(tǒng)設(shè)計(jì)目標(biāo)要滿足這些特性
任何簡單出現(xiàn)故障，對客戶端來講是無所感知的，客戶端并不知道哪些節(jié)點(diǎn)壞了，所以叫失效透明
并發(fā)透明一樣的道，大量訪問的時(shí)候，客戶端并不知道自己是如何被分布的，
但是訪問的IO和性能依然可用
復(fù)制透明
遷移透明
一個數(shù)據(jù)不只一個副本，這個副本還需要分布到其他節(jié)點(diǎn)上去，所以這個復(fù)制過程對于用戶來講是透明的，不管復(fù)制何時(shí)發(fā)生，用戶訪問數(shù)據(jù)該訪問訪問
遷移，如果新增了10個節(jié)點(diǎn)進(jìn)來，要把有些數(shù)據(jù)遷移到新加入的節(jié)點(diǎn)上，以實(shí)現(xiàn)更好的均衡，這個過程對用戶來講也是透明的，為了加進(jìn)節(jié)點(diǎn)進(jìn)來，自動遷移和備份

**分布式文件系統(tǒng)的代表產(chǎn)品
1.最早最著名的是google file system（現(xiàn)代意義上的分布式系統(tǒng)，簡稱GFS）
2.HDFS hadoop distrubuted filesystem 山寨GFS
3.TFS 淘寶的 是HDFS二次衍生，幾乎支撐了淘寶內(nèi)部的所有圖片存儲和服務(wù)
GlusterFS 無中心節(jié)點(diǎn)和redis節(jié)點(diǎn)相似，主要是對象存儲，每一個文件在存儲時(shí)，是一個數(shù)據(jù)對象，自己自帶元數(shù)據(jù)，cluster對于元數(shù)據(jù)可以調(diào)度，但是有些元數(shù)據(jù)是在文件之上調(diào)度的，以為不需要事先提供文件系統(tǒng)，還需要格式化之類的，不需要這個過程
Lustre 是oracle的分布式文件系統(tǒng)，常用的構(gòu)建，,HPC高性能的計(jì)算機(jī)集群
Ceph 被收錄進(jìn)linux內(nèi)核，是內(nèi)核級的linux分布式文件系統(tǒng)，現(xiàn)在應(yīng)該還不是特別穩(wěn)定，文件系統(tǒng)一般都是內(nèi)核級的，但是前面這些都不是，是在應(yīng)用程序之上實(shí)現(xiàn)的，都是用戶空間的文件系統(tǒng)，基于內(nèi)核本地的文件系統(tǒng)做了二次抽象而已，但是ceph原生就是內(nèi)核級的，自己原生就是分布式的
mogile filesystem （分布式存儲）使用perl語言研發(fā)，早期和memcached是一個組織研發(fā)的
API（php，java，perl，python）大眾點(diǎn)評和豆瓣都使用mogile fs來存儲自己的圖片，所以對很多中小企業(yè)來講，mogileFS還算是不錯的解決方案，
moosefilesystem MFS 還算是不錯的分布式文件系統(tǒng)
fastdfs 是C語言研發(fā)的Mogile filesystem （perl語言研發(fā)，要運(yùn)行在perl虛擬機(jī)上，元數(shù)據(jù)存放在mysql中），而fastdfs是C語言，不依賴mysql，而且是國內(nèi)作者研發(fā)的
國內(nèi)中小企業(yè)用MFS.FASTDFS都可以
**

nginx反代的驅(qū)動
這個三個都可以作為圖片存儲

可以結(jié)合docker，直接基于容器啟動
也比較適合存儲圖片
這個項(xiàng)目來講還算是比較活躍的
mogilefs 維護(hù)率很低，是因?yàn)檫@個產(chǎn)品已經(jīng)成熟了，沒有什么bug需要修復(fù)

總結(jié)

以上是生活随笔為你收集整理的2019/07/08 分布式文件系统概述(01)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。