Openck_Swift源代碼分析——添加、刪除設備時算法詳細的實現過程
1 初始加入設備後、上傳Object的詳細流程
前幾篇博客中，我們講到環的基本原理即詳細的實現過程，加入我們在初始創建Ring是執行例如以下幾條命令：
?swift-ring-builder object.builder create 5 3 1 ?swift-ring-builder object.builder add z1-127.0.0.1:6010/sdb1 100 ?swift-ring-builder object.builder add z2-127.0.0.1:6020/sdb2 100 ?swift-ring-builder上面幾條命令語句中，黑色的為初始創建Ring。綠色部分為向Ring中加入設備，四個設備分別位於不同的Zone中。且權重是一樣的。加入完設備後須要對Ring進行平衡，以便得到replica2part2dev_id。當中關於create add rebalance方法的詳細實現過程請參考OpenStack_Swift源代碼分析——Ring的rebalance算法源代碼詳細分析
圖1 初始平衡Ring後 replica2part2dev_id的映射
上圖中第一行為分配編號(在create時輸入的power為5。故為32個分區)。三個list分別代表了三個備份。上圖中一個設備又同一時候相應多個不同的分區，例如以下圖所看到的：
圖 2 設備反映射分區
結合圖1和圖2。一個設備相應讀個分區，這些在存儲數據時，能更好的解決平衡性問題。
在得到了replica2part2dev_id 後，如今我們向集群中存入一個對象。其步驟例如以下所看到的:
圖3 存入一個對象
向集群中存入對象的流程例如以下圖所看到的：
圖4 存入對象的流程
存入對象時，首先依據對象的名稱（account/container/object），計算其hash值。的到hash值後，取hash值的前四字節，且向右移動32-power位得到當前object相應的分區號。如15，得到分區號後。利用分區號到replica2part2dev_id中找到此分區相應的三個設備的Id，如圖1所看到的的設備ID為3 1 4 。依據這三個設備的ID，到devs中找到詳細的設備，依據設備的IP。port已經存儲文件的磁盤所掛載的目錄，如sdb1。
將數據存如設備中。數據存入設備中的目錄結構為srv/node/sdb1/objects/15/hash值後位/hash/.data文件。當中15為分區號，所以文件右移動得到的分區號為15的在該設備中都存入此目錄下。
2 添加設備
假如系統執行了一段時間後。因須要存儲很多其它的對象，現須要對系統進行擴展，例如以下。我們如今添加一個設備：
swift-ring-builder object.builder add z1-127.0.0.1:6050/sdb5 100
在zone1裏面右添加了一個設備，其權重仍為100。加入設備後，每個設備的part_wanted值會變化，之前被分配的設備。會因新加入設備後其會超出其先須要的part_wanted故須要把他們收集回來，分配給新添加的設備，收集的詳細算法實現請參見我前幾篇博客，裏面有詳細的介紹。加入設備後，又一次對Ring進行平衡，平衡後replica2part2dev_id例如以下圖所看到的：
圖５ 加入設備後映射的變化
如上圖（圖中紅線上部分為加入設備後的新映射，紅線下部分為沒加入設備前的映射）所看到的，再加入了設備後。被收集的分區是從第一個備份（第一行）先開始收集。假設第一個備份都被收集完，則再從第二個備份開始收集。如今僅僅加入了一個設備。不會收集到第二個備份的分區，故如綠框中所看到的後兩個分區中分區所相應的設備ID都沒有變化。圖中小紅框和小綠框中所看到的的，第一次平衡和新加入一個設備後平衡的分區15所相應的設備Id 當中一個由3變為5。
這樣的變化，數據的一致性是怎樣保證的呢？為保證因又一次移動平衡而帶來的分區和設備映射的變動，Replicator在保證數據的一致性方面起到至關關鍵的數據。
由於Replicator這個守護進程在每個server上都有執行。故對於設備3 。它首先依據分區目錄的名字獲得分區號然後利用Ring類對外通過的方法。得到此分區相應的設備，此時它發現新的replica2part2dev_id中沒有了其本身。這時它會把目錄名為15及其下的全部文件都刪除。而對於分區15所相應是新設備5，它是怎樣得到這些文件的呢？我們知道，Swift數據的同步是基於推送模式的。也就是4和3 會把其目錄下的文件推送給設備5。比方設備4，其Replicator，在獲得分區15所相應的設備後，和3對照，發現沒有文件不同，故不推送數據，而發現5下沒有分區15所相應的內容，故其須要將自己分區15所相應的文件推送給它，設備3也是相同的原理。
3 刪除設備
集群又執行了一些時間。當中有些設備。由於執行時間較長。設備老化，現須要將其從集群刪掉，Swift設備的刪除，不是直接的物理刪除，先將其weight設置為0，當其weight變為0後，其它的設備的part_wanted就好變大，故在rebalnace時須要先把設備1（加入刪除設備1）所相應的分區都收回，然後再又一次分配給其它分區。
這個過程中replica2part2dev_id變化例如以下：
圖6 刪除設備後replica2part2dev_id的變化
如圖6所看到的（綠線上方為刪除設備後的新映射，綠線和和藍線之間為沒有刪除設備前加入設備後的分區映射。最底下為起初的映射）設備1所相應的全部分區都被收集了。而每個分區所相應的新的設備都會經過其它兩個設備，來將他們文件下的對象推送給新映射的設備。
Openck_Swift源代碼分析——添加、刪除設備時算法詳細的實現過程