分布式存儲介紹、FastDFS 部署

什么是分布式系統？

簡單來說，多臺主機提供同一個服務，例如負載均衡集群，就是一個分布式系統。

什么是分布式存儲？

看看某寶，上面多少圖片，如果使用傳統的單機存儲，需要準備多大的磁盤空間？讀寫性能如何提升？

上圖就是一個分布式存儲的結構，此處存儲節點不在是磁盤，而是多個主機組成，多個主機內部通信實現數據副本，客戶端發來的請求發往前端，前端分發至后端，有點像負載均衡集群中的調度器（此處描述不精確，但便于理解）

分布式存儲給我們帶來了復雜性。并且還有一個問題

在理論計算機科學中，CAP定理（CAP theorem），又被稱作布魯爾定理（Brewer’s theorem），它指出對于一個分布式計算系統來說，不可能同時滿足以下三點：

• 一致性（Consistence) （等同于所有節點訪問同一份最新的數據副本）
• 可用性（Availability）（每次請求都能獲取到非錯的響應——但是不保證獲取的數據為最新數據）
• 分區容錯性（Network partitioning）（以實際效果而言，分區相當于對通信的時限要求。系統如果不能在時限內達成數據一致性，就意味著發生了分區的情況，必須就當前操作在C和A之間做出選擇。）

根據定理，分布式系統只能滿足三項中的兩項而不可能滿足全部三項。理解CAP理論的最簡單方式是想象兩個節點分處分區兩側。允許至少一個節點更新狀態會導致數據不一致，即喪失了C性質。如果為了保證數據一致性，將分區一側的節點設置為不可用，那么又喪失了A性質。除非兩個節點可以互相通信，才能既保證C又保證A，這又會導致喪失P性質。

以上摘自維基百科，指出如果要保證數據一致性就會丟失可用性或者分區容錯性，但我們在生產環境中可用性是最最最應該保證的，那么就會丟失分區容錯性，但分區容錯性又是分布式的基礎，（我們在集群環境里了解到，在集群環境里如果網絡發生了分區，我們應該理解通過投票機制，選舉出票數大于半數的主機以保證可用性）相比較此兩者，一致性的要求就稍次一些，我們保證他最終一致即可，所以一般架構中我們會選擇滿足可用性和分區容錯性，盡量提高一致性。

ps：說了一大堆，單獨理解還好，揉在一起也不是那么容易想明白，慢慢來吧。

分布式的分類

    提供存儲，并且提供文件系統接口，可以掛載使用的，我們稱之為分布式文件系統。

    提供存儲，但不提供文件系統接口，使用特有的API進行訪問，我們稱之為分布式存儲。

分布式存儲的分為兩類

    數據節點中，元數據集中存儲管理，數據節點只存儲數據，被稱為專用的元數據節點

    數據節點中，所有節點均完整存儲元數據數據，只存儲部分數據，被稱為無專用的元數據節點

FastDFS

C語言開發，各節點通過tcp/ip自有協議通信，沒有數據庫節點，元數據都存儲于storage節點，storage節點自行向tracker報告，國人研發。

三個組件

tracker：跟蹤服務器，主要負責調度，在內存中記錄所有存儲組，和存儲服務器的狀態信息，這里相對mogilefs有個存儲組的概念，簡單的說就是提供storge的兩個或多個節點組成一個組，所以內存占用并不大

storage server： 存儲服務器，存儲文件和文件屬性

client： 客戶端，通過專用接口協議與tracker以及storage server進行交互，向tracker提供group_name并發送請求，如果上傳，則會接受到storage，響應的group_name 。

fid格式：

group_name/M##/&&/&&/file_name
group_name:存儲組的組名；上傳完成后，需要客戶端自行保存
M##：服務器配置的虛擬路徑，與磁盤選項store_path#對應
兩級以兩位16進制數字命名的目錄

文件名，與原文件名并不相同，由storage server 根據特定信息生成，文件名包含，源服務器的IP地址，文件創建時間戳、文件大小、隨機數和文件擴展名等

fid是什么？ 簡單的說 文件有文件名，但是在我們分布式環境中會有很多文件存在，為了提高搜索的效率，把文件名做了hash計算，把計算出來的值前面2位相同的放一個目錄，后面2位在此相同的又放一個目錄，這樣當請求一個文件時，直接對請求的文件名做hash計算，得出前面四位去快速定位位置。

提供兩臺centos7 一臺安裝tracker和storage節點  一臺只提供storage

安裝：

git clone  https://github.com/happyfish100/fastdfs.git 

作者交由github托管，克隆此節點

git clone https://github.com/happyfish100/libfastcommon.git

依賴此庫

接著先安裝libfastcommon

./make.sh

./make.sh install

fastdfs目錄執行相同操作

完成后

可以看到關于fdfs的一大堆命令。

接著我們進入配置文件目錄，復制一份配置文件，并修改配置文件。

[root@localhost fastdfs]# cd /etc/fdfs/
[root@localhost fdfs]# cp tracker.conf.sample tracker.conf

配置文件按需修改這里實驗用只修改了日志的目錄

fdfs_trackerd /etc/fdfs/tracker.conf start                #指明配置文件，啟動。

檢查端口是否啟用，然后就按上面的步驟繼續修改storage節點的配置文件

fdfs_storaged /etc/fdfs/storage.conf start        #指明配置文件，啟動

tracker_server=192.168.20.103:22122         #這里一定記得修改tracker服務器的路徑。

檢查端口都是否正常啟動

第二個節點接著上面的操作重復進行~

fdfs_monitor STORAGE.CONF         #指明storage節點的配置文件，可以看到當前節點狀況了~

會顯示出來一大堆的信息，其他的我們先不管，只管看兩個箭頭所指，寫了active 說明兩個節點都準備就緒啦。

group_name=group1                #兩個storage節點需配置同一個組

接著我們繼續修改客戶端的配置文件

tracker_server=192.168.20.103:22122            #同樣，記得修改此行指向tracker服務器的地址

接著就可以上傳一個文件試試了

[root@localhost fdfs]# fdfs_upload_file client.conf /etc/fstab                 #指明配置文件，指明上傳的文件

group1/M00/00/00/wKgUZ1i-6f-AJiocAAABvCXI6iY2960552                    #同時我們可以看到storage節點已經向我們返回了此文件的fid

我們再次去查看監控

[root@localhost fdfs]# fdfs_monitor storage.conf    

接著可以看到兩個存儲節點的狀態，從返回數據可以看到，我們執行的時候應該是寫入到左邊一個服務器上了，右邊服務器同步了左邊的服務器

接著我們來測試一下他的心跳檢測狀態

[root@localhost fdfs]# vi storage.conf            #編輯此配置文件看清楚啊，是storage的配置節點，我們開篇就說了，是storage節點像tracker報告自己的信息.

storage.conf:heart_beat_interval=1               #此行改為1，單位為秒

先看下下載

[root@localhost fdfs]# fdfs_download_file  client.conf group1/M00/00/00/wKgUZ1i-6f-AJiocAAABvCXI6iY2960552 /tmp/fstab
[root@localhost fdfs]# cat /tmp/fstab 
#
# /etc/fstab
# Created by anaconda on Tue Jan 24 06:51:26 2017
#
# Accessible filesystems, by reference, are maintained under ‘/dev/disk’
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=6a58d807-3b42-49da-aa3c-f7e0fe97d643 /                       btrfs   subvol=root     0 0
UUID=45df57d0-4193-4c30-bf3f-3601e4b7cac8 /boot                   xfs     defaults        0 0
/dev/sr0 /media iso9660 defaults 0 0

可以看到能正常下載，接著我去關掉那臺節點主機~

關掉過后仍能下載，并且馬上執行fdfs_monitor 已經顯示另一個節點已經offline了~ 就不截圖了~自行嘗試下吧。

FastDFS和MogileFS適用于相同場景，一般是在有大量>4KB、<512MB圖片和文件環境被用來當做解決方案。