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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

也不是只有google一家公司獨大，另外一家公司也是有高可用關系的競爭能力的，Amazon，亞馬遜在云計算領域，連google都比不上，還有一家是FB，facebook，但是歷史積淀太短，一定程度上來講，也是社交媒體公司，facebook最近的技術也是爆發一樣，很多產品一旦發布就立即開源，并貢獻給ASF

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

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

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

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

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

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

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

可以結合docker，直接基于容器啟動
也比較適合存儲圖片
這個項目來講還算是比較活躍的
mogilefs 維護率很低，是因為這個產品已經成熟了，沒有什么bug需要修復

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。