研究Glusterfs半年多了，通過實際操作以及源代碼分析，對它有了越來越深的了解，由衷的贊嘆Gluster的整體架構。今天時間不早了，想寫點關于Glusterfs的冗余鏡像產生腦裂的原因。

首先，簡單描述一下腦裂，所謂腦裂，就是指兩個或多個節點都“認為”自身是正常節點而互相“指責”對方，導致不能選取正確的節點進行接管或修復，導致腦裂狀態。這種現象出現在數據修復、集群管理等等高可用場景。

Glusterfs的冗余鏡像（下文簡稱AFR）提供了數據副本功能，能夠在即使只有一個冗余節點的情況下仍能正常工作，不中斷上層應用。當節點恢復后，能夠將數據修復到一致狀態，保證數據的安全。

AFR 工作原理

AFR數據修復主要涉及三個方面：ENTRY，META，DATA，我們以冗余度為2即含有兩個副本A和B的DATA修復為例進行講解。記錄描述副本狀態的稱之為ChangeLog，記錄在每個副本文件擴展屬性里，讀入內存后以矩陣形式判斷是否需要修復以及要以哪個副本為Source進行修復。初始值以及正常值為0.（注：ENTRY和META,DATA分布對應著一個數值）。

Write的步驟可分解為：

1）下發Write操作。

2）加鎖Lock。

3）向A，B副本的ChangeLog分別加1，記錄到各個副本的擴展屬性中。

4）對A，B副本進行寫操作。

5）若該副本寫成功則ChangeLog減1，若該副本寫失敗則ChangLog值不變，記錄到各個副本的擴展屬性中。

6）解鎖UnLock。

7）向上層返回，只要有一個副本寫成功就返回成功。

上述在AFR中是完整的一個transaction動作。根據兩個副本記錄的ChangeLog的數值確定了副本的幾種狀態：

1）WISE，智慧的，即該副本的ChangeLog中對方對應的數值大于0而且自身對應的數值等于0.

2）INNOCENT，無辜的，即該副本上的ChangeLog即不指責對方也指責自己，ChangeLog全為0.

3）FOOL，愚蠢的，即該副本上的ChangeLog是指責自己的。

4）IGNORANT，忽略的，即該副本的ChangeLog丟失。

所以一般情況下，會選取WISE的副本作為Sourse進行修復。但是當兩個節點都是WISE狀態時，這就出現了聲名狼藉的腦裂狀態。

AFR 腦裂

兩個副本均為WISE時發生腦裂，那么在哪種場景下會產生腦裂呢？我們還是以冗余度為2的情況舉一個簡單的例子：某文件X的兩個副本位于物理機A和物理機B上，在A和B上分別運行著進程a和進程b，a和b持續通過各自所在的物理機上的客戶端對文件X進行不同的寫操作。然后物理機A和B之間網絡中斷，因為AFR在一個副本的情況下仍能不中斷上層應用，所以進程a和進程b仍會持續運行，但因為網絡中斷，文件X在A和B上的副本數據不再一致且都認為對方是異常的，當網絡恢復時，兩個副本互相“指責”，即出現了腦裂。當然這是腦裂發生的場景之一，有時候是有可能發生腦裂，而有時候是必然發生腦裂。腦裂，也是很多人關心的一個問題，不能一概而論。

關于腦裂，我個人認為不同的場景處理方法也是不同的，甚至某些場景的腦裂是無法避免的，只能盡量避免腦裂的發生。好了，今天就寫到這里吧。晚安~

原文出處：

Glusterfs冗余鏡像（AFR）修復原理以及腦裂分析

http://www.iesool.com/forum.php?mod=viewthread&tid=90&fromuid=2
(出處: 吖Sool- 社區 )

Glusterfs冗余鏡像（AFR）修復原理以及腦裂分析