1．雙副本介紹
1.1 什麼是雙副本？
待續....
1.2 雙副本的優越性
待續....
1.3 雙副本的缺陷
待續....
2．Glusterfs雙副本在虛拟化中的應用
待續....
3．Glusterfs雙副本實作過程
3.1 同步寫操作
1．對要寫入的檔案進行加鎖操作，先嘗試加上非阻塞鎖，如果失敗去掉之前加的非阻塞鎖，加上阻塞鎖。
原因：避免同時的更新，避免寫和自修複的沖突，多個用戶端的沖突。
2．在檔案副本上标記“changelog”(擴充屬性)，表示pending write，這并不是真正的log，而是一個計數數組，在pre op操作中設定所有節點pending狀态置位為1，上傳到brick，将對應的檔案的擴充屬性加1。
3．在所有的副本上執行實際的寫操作。
4．在op操作後将正常活着的節點對應的pending狀态置為-1，其他為0，上傳到brick，将對應的檔案擴充屬性進行減1或0。
5．當所有節點寫操作和changelog減少完成時，釋放鎖。
Glusterfs寫操作技巧點：
如果另一個寫在執行則跳過changelog增加，同樣的目前者的寫操作完成時，略過changelog的減少。這被稱為“changelog piggbacking”，因為這樣讓第二個寫操作騎在(‘ride along”)第一個寫操作的changelog增加上。
當寫重疊（overlap）時忽略掉unlock和之後的lock,這被稱為“eager locking”，它和change piggybacking類似，除了它是對lock 操作而不是changlog操作的優化。
使用了以上優化算法，最優的情況下一次寫操作的網絡通信次數可以從5次減少到1次，隻剩下1次寫操作。一般情況下write-behind在nfs服務端程序預設是打開的，使得這種通路模式更容易發生，另外，write-behind的緩沖機制（預設為1M）也很大的優化了寫操作。
3.2 修複過程
3.2.1 觸發事件
1．Heal程序檢查到有節點上線，也就是child xlator重新連接配接上brick。
2．Glusterd指令操作。
3．寫入操作。
4．第一次進入某個目錄。
5．Heal程序啟動定時器，預設10分鐘檢查同步。
6．……
3.2.2 修複内容
1．Metadata：中繼資料
2．Data：資料内容
3．Entry：目錄項
3.2.3 修複模式
1．INDEX：一般預設修複模式，對應目錄項修複不作深入遞歸修複。
2．INDEX_TO_BE_HEALED：
3，FULL：遞歸進行修複。
3.2.4 INDEX模式修複步驟簡述
1．判斷是否有另一個修複過程存在，如果存在，則退出；
2．建立一個event事件。
3．在INDEX模式下，需要修複的檔案都存儲在brick上index xlator對應的路徑下，通過設定标記GF_XATTROP_INDEX_GFID和getxattr操作擷取index對應的index gfid。
4．通過index gfid查找或建立一個inode附着于dir_loc中，通過lookup操作擷取iattr，通過iattr->gfid更新dir_loc中的inode，到此，拿到了需要修複檔案所在的目錄對應的gfid。
5．通過更新後的dir_loc查找fd，如果查找不到通過dir_loc->inode建立一個index_fd。
6．通過index_fd進行read_dir操作，擷取到需要修複的檔案清單，存傳入連結表，需要注意的是這裡并不是一次性擷取全部的檔案，而是通過該offset作為标志，循環每次擷取一部分的檔案。
7．有了檔案清單，逐漸的對一個一個檔案進行修複。
8．從檔案連結清單中取出檔案，通過檔案的gfid查找或建立inode，并将inode關聯到loc上，設定字典xdata的"attempt-self-heal"值為1，表示要進行修複，進行afr_lookup操作，擷取兩邊brick的檔案屬性，類型等iattr資訊，字典資料等資訊，字典裡可能包含了meta，data，entry的狀态資訊。
9．afr_lookup_cbk回調函數中判斷前面步驟設定需要修複，這時候開始就進行修複了。
10．我們知道修複一個inode檔案（這裡所說的檔案也包含了檔案夾，ext2，ext3之後，把檔案夾也算作一個inode，隻是ia_type檔案類型進行區分）可能需要修複meta，data，entry，但是照成這些不一緻的可能性有多種，例如有一個節點檔案沒寫完，檔案破損，檔案不存在，或者說兩邊brick相同路徑下的檔案的gfid卻不一樣，或者說兩個檔案的ia_type不一樣，也就是檔案類型不一樣，等等。
11．接下來就是通過兩邊brick的lookup操作傳回的資訊确定需要進行哪些修複并設定，需要注意的事如果有一個節點傳回值是-1的話，預設全部需要修複，這裡的修複類型有：
1．do_data_self_heal：
2．do_metadata_self_heal：
3．do_entry_self_heal：
上面三個的情況比較多，例如可能是檔案權限不同，檔案擁有者不同，檔案大小不同，檔案類型不同，或者檔案擴充屬性裡changelog的那三個字段資料不比對規則，這裡偷懶下，先不說了，先說下下面兩個更不常見的。
4．do_gfid_self_heal：brick傳回成功，但是擷取iattr->ia_gfid卻為null，照成這種錯誤的應用場景是什麼呢？誰想到了告訴我下。
5．do_missing_entry_self_heal：兩邊brick都傳回成功，但是擷取iattr->ia_gfid卻不相等，這樣的應用場景比較好想到，例如一個節點1掉線，節點2建立了一個檔案，節點2掉線，節點1上線，節點1建立了一個相同路徑和名字的檔案，導緻通過檔案卻不同的gfid，這種情況很有可能腦裂了。
12．通過上面的設定，接下判斷是否需要metadata的修複，如果需要中繼資料修複，先判斷是否中繼資料腦裂，這裡判斷中繼資料是否腦裂的依據比較簡單，簡而言之，一句話：通過一定規則是否可以建立和确定metadata修複的source，确定不了就說明腦裂了。
13． Glusterfs這樣擷取source的，首先根據child的個數n建立一個n維數組矩陣matrix[n][n]，每一維數組存儲的事對應的brick通過lookup傳回changelog的關于meta的資料段的值，上面有講到brick的lookup操作會傳回字典xdata，而字典裡面存有檔案changelog擴充屬性，可以通過pending_key[j]（trust.gfid.clientName）作為key擷取到，有了這些資料，就可以填充數組矩陣matrix[n][n]。
14．數組矩陣填充完成之後，開始試着選取source，首先我們先介紹下ChangeLog的數值确定了副本的幾種狀态：
1）WISE，智慧的，即該副本的ChangeLog中對方對應的數值大于0而且自身對應的數值等于0.
2）INNOCENT，無辜的，即該副本上的ChangeLog即不指責對方也不指責自己，ChangeLog全為0.
3）FOOL，愚蠢的，即該副本上的ChangeLog是指責自己的。
套用上面所說的3種狀态，如果該副本對應矩陣matrix[child_index_self][n]全為零，則說明該副本狀态為INNOCENT不指責對方和自己，如果該副本對應自己matrix[child_self_index][child_self]的值是大于零的，說明是FOOL副本，自己指責自己需要修複，如果matrix[child_self_index][child_self] 的值為零，說明自己是WISE副本，滿足source節點的一部分條件。
15．接下來可以通過上面的說的規則給每個child（副本）設定為WISE、INNOCENT或着FOOL，有了每個child的狀态根據不同個組合來斷定誰是source。
1）如果所有副本都為INNOCENT，則最小ia_uid的副本作為source；
2）如果找不到WISE副本則選取最大檔案作為source；
3）如果存在WISE副本，且和其他WISE副本，這時候就腦裂了。
4）如果存在WISE副本，且沒有其他WISE副本或者其他WISE副本沒有沖突，這時候該副本就可以作為source。
5）可能出現多個不沖突的WISE，取第一個作為source。
16．開始對其修複或者設定相應的腦裂辨別，這裡面過程比較多，有點類似寫操，隻是一點點類似，且暫時和需要修改的代碼關系不大，這裡簡單說下meta的修複：
1）加inode鎖，非阻塞。
2）lookup選舉source
3）通過source擷取檔案屬性和擴充屬性。
4）用擷取到的屬性給其他非source副本進行設定。
5）清除之前的changelog擴充屬性。
6）解鎖。
17．Data修複：和meta操作方法相似，這裡不細說
18．Entry修複：同上
4. Glusterfs雙副本一緻性和可用性分析
4.1 CAP原理
一緻性 ( Consistency) ：任何一個讀操作總是能讀取到之前完成的寫操作結果；
可用性 ( Availability) ：每一個操作總是能夠在确定的時間内傳回；
分區可容忍性 (Tolerance ofnetwork Partition) ：在出現網絡分區的情況下，仍然能夠滿足一緻性和可用性；
下面有一篇經典的文章，載自http://baike.baidu.com/view/45961.htm#4
在足球比賽裡，一個球員在一場比賽中進三個球，稱之為帽子戲法(HAT-TRICK)。在分布式資料系統中，也有一個帽子原理(CAP THEOREM)，不過此帽子非彼帽子。CAP原理中，有三個要素：
一緻性(CONSISTENCY)可用性(AVAILABILITY)分區容忍性(PARTITION TOLERANCE)CAP原理指的是，這三個要素最多隻能同時實作兩點，不可能三者兼顧。是以在進行分布式架構設計時，必須做出取舍。而對于分布式資料系統，分區容忍性是基本要求，否則就失去了價值。是以設計分布式資料系統，就是在一緻性和可用性之間取一個平衡。對于大多數WEB應用，其實并不需要強一緻性，是以犧牲一緻性而換取高可用性，是目前多數分布式資料庫産品的方向。
當然，犧牲一緻性，并不是完全不管資料的一緻性，否則資料是混亂的，那麼系統可用性再高分布式再好也沒有了價值。犧牲一緻性，隻是不再要求關系型資料庫中的強一緻性，而是隻要系統能達到最終一緻性即可，考慮到客戶體驗，這個最終一緻的時間視窗，要盡可能的對使用者透明，也就是需要保障“使用者感覺到的一緻性”。通常是通過資料的多份異步複制來實作系統的高可用和資料的最終一緻性的，“使用者感覺到的一緻性”的時間視窗則取決于資料複制到一緻狀态的時間。
最終一緻性(EVENTUALLY CONSISTENT)
對于一緻性，可以分為從用戶端和服務端兩個不同的視角。從用戶端來看，一緻性主要指的是多并發通路時更新過的資料如何擷取的問題。從服務端來看，則是更新如何複制分布到整個系統，以保證資料最終一緻。一緻性是因為有并發讀寫才有的問題，是以在了解一緻性的問題時，一定要注意結合考慮并發讀寫的場景。
從用戶端角度，多程序并發通路時，更新過的資料在不同程序如何擷取的不同政策，決定了不同的一緻性。對于關系型資料庫，要求更新過的資料能被後續的通路都能看到，這是強一緻性。如果能容忍後續的部分或者全部通路不到，則是弱一緻性。如果經過一段時間後要求能通路到更新後的資料，則是最終一緻性。
最終一緻性根據更新資料後各程序通路到資料的時間和方式的不同，又可以區分為：
因果一緻性(CAUSAL CONSISTENCY)
如果程序A通知程序B它已更新了一個資料項，那麼程序B的後續通路将傳回更新後的值，且一次寫入将保證取代前一次寫入。與程序A無因果關系的程序C的通路遵守一般的最終一緻性規則。“讀己之所寫（READ-YOUR-WRITES）”一緻性。當程序A自己更新一個資料項之後，它總是通路到更新過的值，絕不會看到舊值。這是因果一緻性模型的一個特例。會話（SESSION）一緻性。這是上一個模型的實用版本，它把通路存儲系統的程序放到會話的上下文中。隻要會話還存在，系統就保證“讀己之所寫”一緻性。如果由于某些失敗情形令會話終止，就要建立新的會話，而且系統的保證不會延續到新的會話。單調（MONOTONIC）讀一緻性。如果程序已經看到過資料對象的某個值，那麼任何後續通路都不會傳回在那個值之前的值。單調寫一緻性。系統保證來自同一個程序的寫操作順序執行。要是系統不能保證這種程度的一緻性，就非常難以程式設計了。上述最終一緻性的不同方式可以進行組合，例如單調讀一緻性和讀己之所寫一緻性就可以組合實作。并且從實踐的角度來看，這兩者的組合，讀取自己更新的資料，和一旦讀取到最新的版本不會再讀取舊版本，對于此架構上的程式開發來說，會少很多額外的煩惱。
從服務端角度，如何盡快将更新後的資料分布到整個系統，降低達到最終一緻性的時間視窗，是提高系統的可用度和使用者體驗非常重要的方面。對于分布式資料系統：
N — 資料複制的份數W — 更新資料是需要保證寫完成的節點數R — 讀取資料的時候需要讀取的節點數如果W+R>N，寫的節點和讀的節點重疊，則是強一緻性。例如對于典型的一主一備同步複制的關系型資料庫，N=2,W=2,R=1，則不管讀的是主庫還是備庫的資料，都是一緻的。
如果W+R<=N，則是弱一緻性。例如對于一主一備異步複制的關系型資料庫，N=2,W=1,R=1，則如果讀的是備庫，就可能無法讀取主庫已經更新過的資料，是以是弱一緻性。
對于分布式系統，為了保證高可用性，一般設定N>=3。不同的N,W,R組合，是在可用性和一緻性之間取一個平衡，以适應不同的應用場景。
如果N=W,R=1，任何一個寫節點失效，都會導緻寫失敗，是以可用性會降低，但是由于資料分布的N個節點是同步寫入的，是以可以保證強一緻性。如果N=R,W=1，隻需要一個節點寫入成功即可，寫性能和可用性都比較高。但是讀取其他節點的程序可能不能擷取更新後的資料，是以是弱一緻性。這種情況下，如果W<(N+1)/2，并且寫入的節點不重疊的話，則會存在寫沖突
4.2 Glusterfs雙副本上CAP原理分析
Glusterfs雙副本模式工作下，在來回拔插網線、等一些極端的情況下，如果為了隻是一味的追求可用性 ( Availability)，可能會出現腦裂的情況，照成了資料的不一緻性( Consistency)，而類似這種操作照成的腦裂是我們不可以容忍的。
根據CAP原理，如果我們想做到既可以保證glusterfs雙副本的可用性( Availability)，又能夠保證資料的一緻性( Consistency)，這是不可能的，追求這樣的完美隻是徒勞。是以，魚和熊掌不能兼得，必須舍其一。
作為分布式存儲系統的應用場景下，節點都線上的時候，為了提高可用性，允許備用節點暫時沒同步完成，我們隻需要保證兩個節點的弱一緻性，或者說是最終一緻性。但是一個節點離線的情況下，我們必須保證線上的節點資料的強一緻性，是最新的資料。
為了保證資料的一緻性，Glusterfs雙副本引用了一種叫做quorum的機制，而且節點被劃分為主從節點。Quorum規定當線上節點數小于所用節點數的二分之一時，副本變為隻讀模式。當線上節點數等于所有節點數的二分之一，并且線上節點為主節點是，允許其正常工作。
Quorum作用在glusterfs雙副本模式上，也就是說，如果從節點掉線不影響主節點的可用性，資料的一緻性也可以得到保障，但是如果主節點掉線，從節點變為隻讀模式，犧牲了資料的可用性，換取資料的一緻性。
5． Glusterfs針對虛拟化應用優化政策
5.1 Glusterfs雙副本虛拟化應用分析
所謂的Glusterfs雙副本虛拟化應用也就是說，brick上的一個鏡像檔案對應一個作業系統，一個檔案損壞或不可用導緻一個作業系統不可用，而一個brick變得不可用，可能導緻brick上成百上千的作業系統不可用。
glusterfs雙副本預設是不啟動quorum機制的，這樣擁有高可用的性能，但是當在一些極端情況下可能會照成節點間同一檔案沒同步完成的情況下繼續讀寫，照成腦裂這種無法挽回的錯誤。這種機率事件雖然很低，但是随着節點數的增加發生這種情況的機率會随之增高，是遲早得面對和解決的問題。
glusterfs雙副本通過配置啟動quorum機制，前面有說過它是主從節點模式，當從節點離線，主節點正常讀寫，繼保證了高可用，也保證了資料的一緻性。但是如果下線的事主節點，從節點變為隻讀模式，不具備寫權限，就是說節點上所有brick上的所有鏡像檔案都不可寫，對于虛拟化應用，所有brick上的作業系統都不可用了，這無疑使讓人不可接受的。
從上可知，Glusterfs提供的兩套解決方案，在雙副本模式和虛拟化應用場景上，第一種顯得太過追求可用性了，完全沒考慮到一緻性；而第二種為了追求資料一緻性了，過多的犧牲了可用性，特别在虛拟化應用場景中，犧牲的可用性照成的損失無疑會被放大許多倍，所有在虛拟化應用中不得不放棄這種方案。
如上文所訴，兩套方案對于虛拟化應用來說都太過極端了。所有，我們需要有一套自己擇中的方案：
1）為了增加系統的可用性，我們可用降低一緻性，可以把quorum機制對brick的一緻性降低到對檔案的一緻性，即使brick不一緻，但是brick上的檔案時一緻的，仍然允許其正常讀寫。
2）為了保證檔案的一緻性，當檔案沒被同步完成時，我們不得不降低檔案的可用性，讓檔案變為隻讀模式。
5.2 Glusterfs雙副本修改政策
brick程序堆棧：
volume afr_pool-posix
type storage/posix
option volume-id 4d2f0895-db19-4650-a618-0a0362e13964
option directory /vol/file1
end-volume
volume afr_pool-changelog
type features/changelog
option changelog-dir /vol/file1/.glusterfs/changelogs
option changelog-brick /vol/file1
subvolumes afr_pool-posix
end-volume
volume afr_pool-access-control
type features/access-control
subvolumes afr_pool-changelog
end-volume
volume afr_pool-locks
type features/locks
subvolumes afr_pool-access-control
end-volume
volume afr_pool-io-threads
type performance/io-threads
subvolumes afr_pool-locks
end-volume
volume afr_pool-index
type features/index
option index-base /vol/file1/.glusterfs/indices
subvolumes afr_pool-io-threads
end-volume
volume afr_pool-spp_server
type spp/spp_server
option spp_sync_flag /etc/glusterd
option spp_server_index-base /vol/file1/.glusterfs/spp_server
subvolumes afr_pool-index
end-volume
volume afr_pool-marker
type features/marker
option quota off
option gsync-force-xtime off
option xtime off
option timestamp-file /etc/glusterd/vols/afr_pool/marker.tstamp
option volume-uuid 4d2f0895-db19-4650-a618-0a0362e13964
subvolumes afr_pool-spp_server
end-volume
volume afr_pool-quota
type features/quota
option deem-statfs off
option timeout 0
option server-quota off
option volume-uuid afr_pool
subvolumes afr_pool-marker
end-volume
volume /vol/file1
type debug/io-stats
option count-fop-hits off
option latency-measurement off
subvolumes afr_pool-quota
end-volume
volume afr_pool-server
type protocol/server
option auth.addr./vol/file1.allow *
option auth.login.6126bf34-c8c3-4840-8d5c-4cd7730a2bf1.password fc1fd2c1-8e21-4685-9856-4c7890991daa
option auth.login./vol/file1.allow 6126bf34-c8c3-4840-8d5c-4cd7730a2bf1
option transport-type tcp
subvolumes /vol/file1
end-volume
self_heal程序堆棧：
volume afr_pool-client-0
type protocol/client
option password fc1fd2c1-8e21-4685-9856-4c7890991daa
option username 6126bf34-c8c3-4840-8d5c-4cd7730a2bf1
option transport-type tcp
option remote-subvolume /vol/file1
option remote-host 192.168.1.45
end-volume
volume afr_pool-client-1
type protocol/client
option password fc1fd2c1-8e21-4685-9856-4c7890991daa
option username 6126bf34-c8c3-4840-8d5c-4cd7730a2bf1
option transport-type tcp
option remote-subvolume /vol/file1
option remote-host 192.168.1.47
end-volume
volume afr_pool-replicate-0
type cluster/replicate
option udf_client_switch yes
option iam-self-heal-daemon yes
option self-heal-daemon on
option entry-self-heal on
option data-self-heal on
option metadata-self-heal on
option background-self-heal-count 0
subvolumes afr_pool-client-0 afr_pool-client-1
end-volume
volume afr_pool-spp_client-0
type spp/spp_client
option spp_sync_flag /etc/glusterd
option spp_client_nfs_opt no
option spp_client_check_out_sync yes
subvolumes afr_pool-replicate-0
end-volume
volume glustershd
type debug/io-stats
subvolumes afr_pool-spp_client-0
end-volume
nfs程序堆棧：
volume afr_pool-client-0
type protocol/client
option send-gids true
option password fc1fd2c1-8e21-4685-9856-4c7890991daa
option username 6126bf34-c8c3-4840-8d5c-4cd7730a2bf1
option transport-type tcp
option remote-subvolume /vol/file1
option remote-host 192.168.1.45
end-volume
volume afr_pool-client-1
type protocol/client
option send-gids true
option password fc1fd2c1-8e21-4685-9856-4c7890991daa
option username 6126bf34-c8c3-4840-8d5c-4cd7730a2bf1
option transport-type tcp
option remote-subvolume /vol/file1
option remote-host 192.168.1.47
end-volume
volume afr_pool-replicate-0
type cluster/replicate
option udf_client_switch yes
option node-uuid 7d6f8c7e-bc5e-4a81-9bb1-5e9a84258714 (非标準，修改源碼添加)
subvolumes afr_pool-client-0 afr_pool-client-1
end-volume
volume afr_pool-spp_client-0
type udf/udf_client
option spp_sync_flag /etc/glusterd （辨別檔案存儲路徑）
option spp_client_nfs_opt yes
option spp_client_check_out_sync no
subvolumes afr_pool-replicate-0
end-volume
volume afr_pool-dht
type cluster/distribute
subvolumes afr_pool-spp_client-0
end-volume
volume afr_pool-write-behind
type performance/write-behind
subvolumes afr_pool-dht
end-volume
volume afr_pool
type debug/io-stats
option count-fop-hits off
option latency-measurement off
subvolumes afr_pool-write-behind
end-volume
volume nfs-server
type nfs/server
option nfs.afr_pool.disable off
option nfs3.afr_pool.export-dir /afr_share(192.168.10.0/24|192.168.1.0/24)
option nfs.port 2049
option rpc-auth.addr.namelookup off
option nfs3.export-volumes off
option nfs3.export-dirs on
option nfs3.afr_pool.volume-id 4d2f0895-db19-4650-a618-0a0362e13964
option rpc-auth.addr.afr_pool.allow *
option nfs.drc off
option nfs.nlm on
option nfs.dynamic-volumes on
subvolumes afr_pool
end-volume
如上所示，分别在glusterfs的用戶端（nfs服務程序，pfs用戶端程序，self_heal程序）和服務端（brick程序）加入了spp_client和spp_server。
1）：在brick程序中：加入spp_server，這個xlator的作用是擷取自身brick需要被其他brick同步的檔案，而這些檔案存儲在/brick/.glusterfs/spp_server目錄下，模仿index xlator的設計思路。
2）：在self程序中：如節點上線等情況，afr程式開始自我修複時候，會将需要同步的檔案清單從自身brick中取出，notify到上層spp_client，這時候，spp_client拿到了這個檔案清單，将這些檔案清單發送給另一個節點，由雙副本另一個節點的spp_server接收到檔案清單gifd，并存入/brick/.glusterfs/spp_server檔案路徑。并在記錄辨別檔案的值為1，表示已經将檔案清單同步給雙副本的另一個節點。在同步的過程中，當同步完一個檔案時，通知兩端的brick程序，這時brick程序在/brick/.glusterfs/spp_server路徑下将對應的檔案unlink掉。當節點掉線的時候，記錄辨別檔案的值為0。
3）：在nfs程序（或pfs用戶端程序）中：當雙副本節點上線的時候，nfs暫時停止服務（這裡時間很短，可以忽略不計，也可以通過開關設定是否停止服務），spp_client開啟定時器，分别去兩個brick上讀取辨別檔案的值，當讀到兩邊的值都是1時，說明兩邊的brick上需要同步的檔案清單已經更新完成，這時定時讀取兩邊brick需要同步的的檔案清單更新本地檔案過濾連結清單（這時heal程序正在同步，每次讀到的檔案清單會越來越少，千級以上的檔案可以用哈希連結清單）。spp_client過濾功能被觸發時，這時連結清單裡存在的gfid檔案的寫操作将被過濾掉，io寫操作将會被傳回readonly，每個檔案的過濾隻需要一次，結果被記錄在inode的ctx内容裡面，下次遇到相同的檔案則隻需要讀取結果記錄。當強一緻性開關打開時，就算兩個節點同時線上，spp_client過濾功能也啟用，如果關閉，隻有當一個節點掉線的時候，spp_client過濾功能才被觸發。
4）私人測試，僅供參考：
1：不開啟quorum功能，不開啟spp功能（标志glusterfs雙副本測試）：
1.1：可用性百分百，500線程寫入500個檔案測試多次故障，來回拔插網線，斷電，重新開機，腦裂的機率為100%，腦裂檔案上百個。
2：不開啟quorum功能，開啟spp功能後：
2.1：當強一緻性開關打開時，兩節點線上時，需要修複的檔案無法寫入直到修複完成，可用性降低。多次網絡故障，來回拔插網線，斷電，重新開機，腦裂的機率為0。
2.2：關閉強一緻性開關時，兩節點線上，可用性百分百，500線程寫入500個檔案測試多次故障，來回多次拔插網線，腦裂機率大概35%，每次最多腦裂一個檔案，斷電，重新開機腦裂機率為0。腦裂的原因是spp過濾之前有一個時間差，可能導緻很小一部分檔案操作流程已經穿過spp層到達afr層，導緻spp無法過濾到。
雙副本spp狀态機詳解
spp_server狀态機表示圖
nfs程序上spp_client狀态機表示圖
Nfs.spp_client檔案過濾流程
spp協定流程圖