1：什麼是分佈式互斥
分佈式進程常常需要協調他們的動作，如果一組進程共享一個或一組資源，那麼訪問這些資源時，需要互斥來防止干擾並保證一致性。在分佈式系統裏，這種排他性的資源訪問方式，叫作分佈式互斥（Distributed Mutual Exclusion），而這種被互斥訪問的共享資源就叫作臨界資源（Critical Resource）。
2：互斥算法
2.1 中央服務器算法
中央服務器算法也叫集中式算法，上面提到的互斥機制，最簡單的方法是使用一個服務器來授權訪問臨界資源的許可，該服務器充當 “協調者” 的角色。每個進程在訪問臨界資源時，先給該協調者發送一個請求並等待協調者應答。如果當前沒有其他進程使用這個臨界資源，協調者直接應答該進程請求。如果有其他進程在使用臨界資源，則協調者不會立即應答，而是將該請求放入隊列，併爲該請求 “排號”。如果有進程使用完資源，則通知協調者，協調者從 “排號” 的隊列裏取出排在最前面的請求，並給它發送授權消息。拿到授權消息的程序，可以直接去訪問臨界資源。
如圖所示，程序 1、2、3、4 爲普通運行程序，另一個程序爲協調者。當程序 2 和程序 4 需要使用臨界資源時，它們會向協調者發起申請，請求協調者授權。
如果此時，程序 3 正在使用臨界資源。協調者會根據程序 2 和 4 的申請時間順序，依次將它們放入等待隊列。在這個案例裏，程序 4 的申請時間早於程序 2，因此排在程序 2 的前面。
程序 3 使用完臨界資源後，通知協調者釋放授權。此時，協調者從等待隊列中取出程序 4，並給它發放授權。這時，程序 4 就可以使用臨界資源了。
從上述流程可以看出，一個程序完成一次臨界資源訪問，需要如下幾個流程和消息交互：向協調者發送請求授權信息，1 次消息交互；協調者向程序發放授權信息，1 次消息交互；程序使用完臨界資源後，向協調者發送釋放授權，1 次消息交互。
因此，每個程序完成一次臨界資源訪問，需要進行 3 次消息交互。
可以看到，集中式互斥算法的優點在於簡單，容易理解和實現，並且所有進程只需要和協調者進行交互，進程之間無需通信。但是，也存在一定問題：
1：協調者服務器會成爲系統的性能瓶頸，協調者處理的消息數量會隨着需要訪問的臨界資源的進程數量線性增加；
2：由於是集中式處理，協調者服務器如果出現單點故障，會導致所有進程均無法訪問臨界資源，導致整個系統不可用。
因此，如果使用中央服務器算法（集中式算法），那麼要考慮選擇性能好並且可靠性高的服務器來運行協調者。
總結：集中式算法具有簡單、易於實現的特點，但可用性、性能易受協調者影響。在可靠性和性能有一定保障的情況下，比如中央服務器計算能力強、性能高、故障率低，或者中央服務器進行了主備，主故障後備可以立馬升爲主，且數據可恢復的情況下，集中式算法可以適用於比較廣泛的應用場景。
2.2 分佈式算法
分佈式算法又稱使用組播算法和邏輯時鐘算法，Ricahrt和Agraawala 在1981年開發了一個基於組播實現的N個對等進程間互斥的算法。該算法的基本思想是要進入臨界資源的進程組播一個請求消息，並且只有在其他進程都應答了這個消息時才能進入。
舉例，如下圖所示：程序 1、2、3 需要訪問共享資源 A。在時間戳爲 8 的時刻，程序 1 想要使用資源 A，於是向程序 2 和 3 發起使用資源 A 的申請，希望得到它們的同意。在時間戳爲 12 的時刻，程序 3 想要使用資源 A，於是向程序 1 和 2 發起訪問資源 A 的請求。
如圖所示，此時程序 2 暫時不訪問資源 A，因此同意了程序 1 和 3 的資源訪問請求。對於程序 3 來說，由於程序 1 提出請求的時間更早，因此同意程序 1 先使用資源，並等待程序 1 返回同意消息
如圖所示，程序 1 接收到其他所有程序的同意消息之後，開始使用資源 A。當程序 1 使用完資源 A 後，釋放使用權限，向請求隊列中需要使用資源 A 的程序 3 發送同意使用資源的消息，並將程序 3 從請求隊列中刪除。此時，程序 3 收到了其他所有程序的同意消息，獲得了使用資源 A 的權限，可以使用臨界資源。
從上述流程可以看出，一個進程完成一次臨界資源的訪問，需要進行如下的信息交互：向其他 n-1 個進程發送訪問臨界資源的請求，總共需要 n-1 次消息交互；需要接收到其他 n-1 個進程回覆的同意消息，方可訪問資源，總共需要 n-1 次消息交互。因此，一個進程訪問臨界資源至少需要 2*(n-1) 次消息交互。
如果現在系統中的 n 個進程都要訪問臨界資源，則會同時產生 2n*(n-1) 條消息。因此，在大型系統中使用分佈式算法，消息數量會隨着需要訪問臨界資源的進程數量呈指數級增加，容易導致高昂的“溝通成本”。
綜上，分佈式互斥算法根據“先到先得”以及“投票全票通過”的機制，讓每個程序按時間順序公平地訪問資源，優點是簡單粗暴、易於實現。但是這個算法可用性很低，主要包括兩個方面的原因：
- 當系統內需要訪問臨界資源的進程增多時，容易產生“信令風暴”，也就是程序收到的請求完全超過了自己的處理能力，而導致自己正常的業務無法開展。
- 一旦某一程序發生故障，無法發送同意消息，那麼其他程序均處在等待回覆的狀態中，使得整個系統處於停滯狀態，導致整個系統不可用。所以，相對於集中式算法的協調者故障，分佈式算法的可用性更低。
針對分佈式互斥算法的可用性低的缺陷，改進的辦法是：如果檢測到一個程序故障，則直接忽略這個程序，無需再等待它的同意消息。但同時，每個進程都需要對其他進程進行故障檢測，這也帶來了更大的複雜性。
因此，分佈式算法適合節點數目少，且變動不頻繁的系統，並且每個進程之間均需通信交互，因此適合P2P結構的系統。
我們熟悉的Hadoop分佈式系統，其中的HDFS文件修改就是一個典型的分佈式算法的場景。
- 計算機 1 向計算機 2、3 發送文件修改請求；
- 計算機 2、3 發現自己不需要使用資源，因此同意計算機 1 的請求；
- 計算機 1 收到其他所有計算機的同意消息後，開始修改該文件；
- 計算機 1 修改完成後，向計算機 2、3 發送文件修改完成的消息，併發送修改後的文件數據；
- 計算機 2 和 3 收到計算機 1 的新文件數據後，更新本地的備份文件。
2.2 令牌環算法
所有進程構成一個環結構，令牌按照順時針或逆時針方向在進程之間傳遞，收到令牌的進程有權限訪問臨界資源，訪問完成後將令牌傳送到下一個進程；如果進程不需要訪問臨界資源，則直接把令牌傳送給下一個進程。
在分佈式領域，這個算法叫做令牌環算法，也成爲基於環的算法。
如圖所示：
在使用臨界資源前，不需要像分佈式算法那樣挨個徵求其他進程意見了，相對而言，令牌環算法裏單個進程具有更高的通信效率，在一個週期內，每個進程都能訪問到臨界資源，算法公平性更好。但是優點也是缺點，因爲無論環中的進程是否想要訪問資源，都需要接受並傳遞令牌，導致帶來一些無效的通信。比如有100個進程，那麼進程1訪問臨界資源後，即使其他99個進程不需要訪問，也必須要等令牌子在其他99個進程傳遞完成後，才能訪問資源，降低了系統的實時性。
綜上所述，令牌環互斥算法適合通信模式爲令牌環方式的分佈式系統。算法的公平性高，在改進單點故障後，穩定性也很高，適用於系統規模較小，並且系統中每個程序使用臨界資源的頻率高且使用時間比較短的場景。
3：優缺點總結
| 算法 | 方法 | 優點 | 缺點 | 應用場景 |
|---|---|---|---|---|
| 集中式方法 | 引入一個協調者，將所有請求者進行排序，先到先得 | 簡單易於實現，通信高效 | 可用性低，存在單點故障，性能受協調者影響 | 在協調者的性能和可靠性受保障的情況下，可適用較廣泛的場景 |
| 分佈式算法 | 徵求其他進程意見同意後，纔可以訪問臨界資源 | 適用性高 | 通信成本高，複雜度高 | 臨界資源適用率低並且規模比較小的場景 |
| 令牌環算法 | 所有進程組成一個環，輪流使用臨界資源 | 單個參與者通信效率高，可用性高 | 當參與者對臨界資源使用頻率比較低，導致無效的通信比較多 | 系統規模比較小，並且系統中每個進程使用共享資源頻率 |
4：問題延伸
針對中央服務器算法（集中式算法）、分佈式算法和令牌環算法存在的缺陷，有哪些可以改進的地方？
- 集中式算法：可參照redis集羣通信模式，通過哈希算法將大量的請求分散到不同的master,以處理大量請求,每個master由小集羣主從節點來保障單點故障
- 分佈式算法：分佈式算法可在集羣中過半數同意就識爲其同意，降低通信數，如分佈式選舉場景
- 令牌環算法：可根據參與者使用頻率列出權重，結合平滑加權輪詢算法選出下一個參與者