序言

最近花了很多時間在分布式存儲上面，不想在這個上面再花費很多時間了，所以用這篇文章做一個最后的總結(jié)。

在面對分布式存儲的時候，分為兩種角度，一種是客戶側(cè)，一種是運維側(cè)，客戶是上帝，所以不談上帝的操作，專注于運維側(cè)的系統(tǒng)構(gòu)建。

其實所有的系統(tǒng)構(gòu)建，都應(yīng)該分成兩個緯度，一個是客戶緯度，專注于客戶體驗，進行各種定制化輸出；一個是運維緯度，專注于底層的運維，各種監(jiān)控數(shù)據(jù)，各種操作，都使用白屏的操作，而不是天天命令行操作，使用平臺層面，可以防止誤操作，系統(tǒng)扛了大部分的責(zé)任，也可以讓運維不用每天記憶那些傻逼命令，傻逼參數(shù)，減輕低等級的操作，讓大腦有更多的空間來想想其他的事情。。。例如，看看藍天白日黃昏。。。。

[[227132]]

分布式存儲運維系統(tǒng)構(gòu)建

分布式的架構(gòu)一般如下所示：

在分布式系統(tǒng)中，主要有幾個對象。

運維測對象：一個是master，控制節(jié)點對象，主要用來提供元數(shù)據(jù)的保存，統(tǒng)計相關(guān)的信息，對外提供統(tǒng)一的API；一個是chunkserver，工作節(jié)點對象，主要是用來存儲數(shù)據(jù)。

master涉及到動作有：查詢master節(jié)點，進行master節(jié)點切換，備份元數(shù)據(jù)，生成checkpoint文件用于恢復(fù)，生成操作日志用于同步，修改master啟動參數(shù)，重啟master進程。

chunkserver涉及到動作有：查詢chunkserver列表，顯示總的空間大小，剩余的空間大小，磁盤的狀態(tài)，進程狀態(tài)，修改chunkserver進程參數(shù)，重啟chunkserver進程，擴容，縮容。

客戶側(cè)對象：一個是目錄，一個是文件，在此主要涉及到的動作有，查看目錄，查看文件，查看分片數(shù)量，設(shè)置分片數(shù)量，檢查分片數(shù)量，處理分片異常，設(shè)置用戶的邏輯空間占用多少，物理空間占用多少，目錄文件遷移，設(shè)置回收策略，設(shè)置文件的replica數(shù)量。

以下為對動作的解釋，為什么需要這些動作：

1、 主節(jié)點為三個，主要是因為使用了paxos算法來進行選主操作，為什么要有一個主？提供服務(wù)的高可用，而使用三個節(jié)點，則是為了防止分區(qū)的情況出現(xiàn)。

2、 為什么要生成checkpoint文件，當(dāng)master存儲了大量的元數(shù)據(jù)的時候，這些數(shù)據(jù)都放在磁盤上，如果服務(wù)器宕機，那么在啟動進程的時候，會將所有的數(shù)據(jù)都要加載進內(nèi)存，時間上來說，是不可以接受的，從而定時生成checkpoint文件，便于宕機恢復(fù)，或者是進程掛了進行恢復(fù)。

3、 為什么要有操作日志，操作日志主要是在三個master節(jié)點上，都使用的是相同的一份數(shù)據(jù)，在master與其他的slave進行同步的時候，使用操作日志進行同步。

4、 為什么要有立刻生成chenckpoint文件和操作日志的動作，一般生成checkpoint都是定時生成的，當(dāng)我要進行升級，或者修改參數(shù)的時候，需要保證數(shù)據(jù)的一致性，從而即可生成，在啟動的時候，減少啟動的時間。

5、 為什么要顯示chunkserver的磁盤空間，chunkserver主要是用來存儲的，那么必然要顯示磁盤的剩余空間和總的空間，這個也是分布式存儲的主要作用。

6、 修改chunkserver進程的參數(shù)是為了在重啟chunkserver進程的時候，無須去服務(wù)器上手動進行修改相關(guān)的參數(shù)。

7、 擴容縮容一鍵化操作，大大減少運維操作的復(fù)雜性。

8、 為什么要處理分片異常，在有些異常的情況下，分片有的時候少了，有的時候沒有，有的時候沒有達到期望值，從而需要對分片異常的情況進行處理，這個主要是為了保障數(shù)據(jù)安全。。。而在這個進行操作的時候，可以使用replica的自動刪除和添加機制，也就是修改一下文件的分片數(shù)量，從而也就會刪除老版本的分片，并且將分片數(shù)量達到自己期望的狀態(tài)。

9、 在分布式文件系統(tǒng)中，刪除數(shù)據(jù)是有策略的，一般會設(shè)置一個回收站，當(dāng)刪除數(shù)據(jù)的時候，會將數(shù)據(jù)加入到回收站中，保留一天或者兩天時間，如果還沒有進行恢復(fù)，那么說明數(shù)據(jù)可以刪除，會有一個定時任務(wù)來定時清理這些數(shù)據(jù)，從而需要一個回收刪除的策略。

10、 設(shè)置文件的replica數(shù)量，這個是最基本的功能了，分布式存儲的可靠性和可用性的唯一保障就是分片數(shù)量，一般為三份。

如果說，你看了上面的那么多內(nèi)容，還不能做出一個運維測的分布式運維系統(tǒng)，那我也就無話可說了，對象有了，動作有了，剩下的就是代碼了。。。

等風(fēng)來。。。。

閑扯。。。

分布式存儲就像風(fēng)一樣，你不知道花落誰家，你也可能找不到它到底存儲在哪個節(jié)點的哪個chunk上，。。。其實是可以找到的，哈哈

分布式系統(tǒng)用來保證數(shù)據(jù)的可靠性，分片是唯一手段，保存來保存去，其實還是保存在磁盤上，無論你怎么跑，你要么存儲在ssd磁盤上，要么存儲在sata磁盤上。

分布式存儲的可用性，無論怎么可用，最后都是使用linux系統(tǒng)中，無論怎么存儲，都是使用的操作系統(tǒng)提供的文件系統(tǒng)，所以不管你是不是分布式存儲，分布式文件，分布式表格，分布式鍵值，都存在于ext3？ext4文件系統(tǒng)中。。。。那么問題來了，在存儲的時候，都是先寫入內(nèi)存，然后返回客戶端寫成功，如果。。。這個時候服務(wù)器宕機了，是不是就丟失數(shù)據(jù)了呢？？？

丟數(shù)據(jù)，有什么關(guān)系，但是，可以不丟么，可以的。。。只要禁用swap，禁用操作系統(tǒng)層面的緩存就可以了，損失了部分性能，換取了更強的可靠性。

在使用分布式存儲的時候，使用ssd，使用sata，可以優(yōu)化么？那是必須可以的，在操作系統(tǒng)層面，總是存儲各種元數(shù)據(jù)，例如atime，diratime，但是在分布式系統(tǒng)中，可以不存儲已提高性能，在進行掛載的時候，加入這些參數(shù)就好了。。

這就是所謂的優(yōu)化？？？是的，就那么幾個參數(shù)，也算是優(yōu)化。。。你不能修改源碼進行適配，所以。。。加幾個參數(shù)就算是優(yōu)化了，這個。。。算是一種搞笑的行為，不過。。很多人以為這種優(yōu)化酷斃了。。。。淡然一笑。。。不語。。。

有的時候，感覺有的操作很酷，因為在構(gòu)建一個運維平臺的時候，不僅僅有各種測試數(shù)據(jù)，各種TPS，各種QPS，各種http latency，還有。。。我做這個動作需要幾步。。。例如我擴容，點擊3次，輸入3次，就完成了一次擴容。。?？煽氐娘L(fēng)險，可控的升級。。。。這種還是極好的。。。

沒有冪等性，如何做到唯一性？？？在使用分布式系統(tǒng)的時候，可能會經(jīng)常碰到超時，那么這種超時，怎么辦？？？業(yè)務(wù)方面一般認為存儲系統(tǒng)是可靠的，返回成功就是成功，而返回失敗則是失敗，而沒有考慮到如果服務(wù)端處理成功，客戶端超時沒接受到響應(yīng)，咋整。。。。業(yè)務(wù)序列號的唯一性，查詢此筆業(yè)務(wù)的序列號，然后查詢記錄，從而可以得到成功或者失敗，只能根據(jù)歷史情況查詢。。。

突然記起來了，在分布式存儲中，還有一個動作就是數(shù)據(jù)打散，也就是rebalance，這種操作感覺好高端，例如。。。在擴容的時候，新上線的機器需要遷移數(shù)據(jù)，例如，在使用DHT算法的時候，需要將相鄰的數(shù)據(jù)遷移到新上限的機器上，那么進行rebalance，如果此時數(shù)據(jù)量過大，可能會影響整體分布式存儲的IO能力，從而在進行rebalance的時候，需要手動進行操作，進行限流，也就是限制遷移的速度，可能是20M/S，也可能是100M.S，主要看你的帶寬來進行評估了。。。不要讓屁股決定腦袋。。。

突然記起來上次一個故障，客戶端寫存儲，寫不進去，業(yè)務(wù)報錯，查詢，發(fā)現(xiàn)客戶端響應(yīng)碼，5XXX，內(nèi)部錯誤，查詢?nèi)罩?，發(fā)現(xiàn)是，，，分區(qū)未找到。。。初步判斷為可能服務(wù)器宕機，不可能。。。進程重啟。。。不可能，都沒收到報警。。。那么就認定為是服務(wù)器內(nèi)部進行了rebalance的操作。。。但是最后再一看，發(fā)現(xiàn)所有的rebalance都必須手動，自動進行rebalance的操作都已經(jīng)關(guān)閉，然后查詢對應(yīng)的時間點，發(fā)現(xiàn)。。。對應(yīng)的chunkserver上面的進程進行了重啟。。。。然后再查為什么重啟，發(fā)現(xiàn)是進程使用的內(nèi)存過大，而cgroup對這個進程使用的內(nèi)存做了限制，從而把這個進程殺了，然后監(jiān)控進程一看，這個傻逼掛了，然后又把它給啟動了，。。。裝作什么事都沒有發(fā)生。。。而就在一分鐘之內(nèi)，啪啪啪，報錯報錯。。。。那么問題來了，啟動一個chunkserver進程需要一分鐘么。。。那么問題又來了，前端的nginx或者lvs發(fā)現(xiàn)了進程掛了15S，拉起來進程，假設(shè)是15S，那么檢查間隔15S，大于45S，再加上各種延時，考慮一下服務(wù)器的負載，差不多一分鐘。。。。那么這種問題。。。主管判斷？日志檢查？這種才是好玩的問題排查。。。。

JUST FUCK...............好了，這篇文章只花一個小時，浪費太多時間不好