分布式化網站遇到的典型問題

發布：2018-11-28 15:43:08 瀏覽：4068

在大型分布式互聯網系統中，Session問題是典型的分布式化過程中會遇到的難題。因為Session數據必須在服務端的機器中共享，并要保證狀態的一致性。

ZooKeeper是一個分布式的，開放源碼的分布式應用程序協調服務，它是一個為分布式應用提供一~致性服務的軟件，所提供的功能包括:配置維護、域名服務、分布式同步、組服務等。下面我們介紹一下典型的分布式環境下遇到的一些典型問題的解決辦法。

1.集群管理(GroupMembership)

ZooKeeper能夠很容易地實現集群管理的功能，如圖1.15所示。如果多臺Server組成一個服務集群，那么必須有一個“總管”知道當前集群中每臺機器的服務狀態，一旦有機器不能提供服務，就必須知會集群中的其他集群，并重新分配服務策略。同樣，當集群的服務能力增加時，就會增加一臺或多臺Server，這些也必須讓“總管”知道。

Zo0Keeper不僅能夠維護當前集群中機器的服務狀態，而且能夠選出一個“總管”，讓“總管”來管理集群一這就是ZookeeperI的另一個功能LeaderElection。

它的實現方式是在Zookeeper上創建一個EPHEMERAL類型的目錄節點，然后每個Server在它們創建目錄節點的父目錄節點上調用getchildrenfStringpath，Booleanwatch)方法并設置watch為true。由于是EPHEMERAL目錄節點，當創建它的Server死去時，這個目錄節點也隨之被刪除，所以Children將會變化；這時getChildren上的Watch將會被調用，通知其他Server某臺Server已死了。新增Server也是同樣的原理。

那么，Z0Keeper如何實現LeaderElection，也就是選出一個MasterServer呢?和前面的一樣，每臺Server創建一個EPHIEMERAL目錄節點，不同的是它還是一個SEQUENTIAL目錄節點，所以它是個EPHEMERALSEQUENTIAL目錄節點。之所以它是EPHEMERALSEQUENTIAL目錄節點，是因為我們可以給每臺Serverg編號。

我們可以選擇當前最小編號的Server為Master，假如這個最小編號的Server死去，由于它是EPHEMERAL節點，死去的Server對應的節點也被刪除，所以在當前的節點列表中又出現一個最小編號的節點，我們就選擇這個節點為當前Master。這樣就實現了動態選擇Master，避免傳統上單Master容易出現的單點故障問題。

2.共享鎖(Locks)

在同一個進程中，共享鎖很容易實現，但是在跨進程或者不同Server的情況下就不好實現了。然而Zookeeper能很容易地實現這個功能，它的實現方式也是通過獲得鎖的Server創建一個EPHEMERALSEQUENTIAL目錄節點，再通過調用getchildren方法，查詢當前的目錄節點列表中最小的目錄節點是否是自己創建的目錄節點，如果是自己創建的，那么它就獲得了這個鎖；如果不是，那么它就調用exists(Stringpath，Booleanwatch)方法，并監控Zookeeper上目錄節點列表的變化，直到使自己創建的節點是列表中最小編號的目錄節點，從而獲得鎖。釋放鎖很簡單，只要刪除前面它自己所創建的目錄節點即可。

3.隊列管理

Keener可以外理以下兩種型的隊列

其一，同步隊列。即當一個隊列的成員都聚齊時，這個隊列才可用，否則一直等待所有成員到達。

其二，隊列按照FIFO方式進行入隊和出隊操作，例如實現生產者和消費者模型。用Zo0Keeper實現同步隊列的實現思路如下。

創建一個父目錄/synchronizing，每個成員都監控標志(SetWatch)位目錄/synchronizing/start是否存在，然后每個成員都加人這個隊列；

加人隊列的方式就是創建/synchronizing/memberi的臨時目錄節點，之后每個成員獲取/synchronizing目錄的所有目錄節點，也就是member_i；?判斷i的值是否已經是成員的個數，如果小于成員個數等待/'synchronizing/start的出現，如果已經相等就創建/synchronizing/star。

用Zookeeper實現FIFO隊列的思路如下。

在特定的網站制作目錄下創建 SEQUENTIAL類型的子目錄 queue I，這樣就能保證所有成員加入隊列時都是有編號的；出隊列時通過 get Children()方法返回當前所有隊列中元素，再消費其中最小的一個，這樣就能保證FIFO。