分佈式設計與開發

#0 系列目錄#

• 分佈式設計與開發

• CAP原理和最終一致性(Eventually Consistency)

• 分佈式算法

• [分佈式Paxos算法]

• 分佈式一致性Hash算法

• 輪循算法（Round Robin）

• Hash求餘算法（Hash）

• 最少鏈接算法（Least Connection）

• 響應速度算法（Response Time）

• 加權算法（Weighted）

• 分佈式消息

• 分佈式發佈訂閱消息系統Kafka架構設計

• 分佈式緩存

• Redis 分佈式

• Memcached 分佈式

• 分佈式存儲

• 分佈式事務

#1 分佈式介紹# 分佈式可繁也能夠簡，最簡單的分佈式就是你們最經常使用的，在負載均衡服務器後加一堆web服務器，而後在上面搞一個緩存服務器來保存臨時狀態，後面共享一個數據庫，其實不少號稱分佈式專家的人也就停留於此，大體結構以下圖所示：

這種環境下真正進行分佈式的只是web server而已，而且web server之間沒有任何聯繫，因此結構和實現都很是簡單。

有些狀況下，對分佈式的需求就沒這麼簡單，在每一個環節上都有分佈式的需求，好比Load Balance、DB、Cache和文件等等，而且當分佈式節點之間有關聯時，還得考慮之間的通信，另外，節點很是多的時候，得有監控和管理來支撐。這樣看起來，分佈式是一個很是龐大的體系，只不過你能夠根據具體需求進行適當地裁剪。按照最完備的分佈式體系來看，能夠由如下模塊組成：

分佈式任務處理服務：負責具體的業務邏輯處理

分佈式節點註冊和查詢：負責管理全部分佈式節點的命名和物理信息的註冊與查詢，是節點之間聯繫的橋樑

分佈式DB：分佈式結構化數據存取

分佈式Cache：分佈式緩存數據（非持久化）存取

分佈式文件：分佈式文件存取

網絡通訊：節點之間的網絡數據通訊

監控管理：蒐集、監控和診斷全部節點運行狀態

分佈式編程語言：用於分佈式環境下的專有編程語言，好比Elang、Scala

分佈式算法：爲解決分佈式環境下一些特有問題的算法，好比解決一致性問題的Paxos算法

所以，若要深刻研究雲計算和分佈式，就得深刻研究以上領域，而這些領域每一塊的水都很深，都須要很底層的知識和技術來支撐，因此說，對於想提高技術的開發者來講，以分佈式來做爲切入點是很是好的，能夠以此爲線索，探索計算機世界的各個角落。

#2 幾種必須瞭解的分佈式算法# 分佈式設計與開發中有些疑難問題必須藉助一些算法才能解決，好比分佈式環境一致性問題，感受如下分佈式算法是必須瞭解的（隨着學習深刻有待添加）：

• Paxos算法
• 一致性Hash算法

##2.1 Paxos算法##

1. 問題描述

分佈式中有這麼一個疑難問題，客戶端向一個分佈式集羣的服務端發出一系列更新數據的消息，因爲分佈式集羣中的各個服務端節點是互爲同步數據的，因此運行完客戶端這系列消息指令後各服務端節點的數據應該是一致的，但因爲網絡或其餘緣由，各個服務端節點接收到消息的序列可能不一致，最後致使各節點的數據不一致。舉一個實例來講明這個問題，下面是客戶端與服務端的結構圖：

當client一、client二、client3分別發出消息指令A、B、C時，Server1~4因爲網絡問題，接收到的消息序列就可能各不相同，這樣就可能因爲消息序列的不一樣致使Server1~4上的數據不一致。對於這麼一個問題，在分佈式環境中很難經過像單機裏處理同步問題那麼簡單，而Paxos算法就是一種處理相似於以上數據不一致問題的方案。

2. 算法自己

透過Paxos算法的各個步驟和約束，其實它就是一個分佈式的選舉算法，其目的就是要在一堆消息中經過選舉，使得消息的接收者或者執行者能達成一致，按照一致的消息順序來執行。其實，以最簡單的想法來看，爲了達到大夥執行相同序列的指令，徹底能夠經過串行來作，好比在分佈式環境前加上一個FIFO隊列來接收全部指令，而後全部服務節點按照隊列裏的順序來執行。這個方法固然能夠解決一致性問題，但它不符合分佈式特性，若是這個隊列down掉或是不堪重負這麼辦？而Paxos的高明之處就在於容許各個client互不影響地向服務端發指令，大夥按照選舉的方式達成一致，這種方式具備分佈式特性，容錯性更好。

說到這個選舉算法自己，能夠聯想一下現實社會中的選舉，通常說來都是得票者最多者獲勝，而Paxos算法是序列號更高者獲勝，而且當嘗試提交指令者被拒絕時（說明它的指令所佔有的序列號不是最高），它會從新以一個更好的序列參與再次選舉，經過各個提交者不斷參與選舉的方式，達到選出大夥公認的一個序列的目的。也正是由於有這個不斷參與選舉的過程，因此Paxos規定了三種角色（proposer，acceptor，和 learner）和兩個階段（accept和learn），另一個國內的哥們寫了個不錯的PPT，還經過動畫描述了paxos運行的過程。不過仍是那句話不要一開始就陷入算法的細節中，必定要多想一想設計這些遊戲規則的初衷是什麼。

Paxos算法的最大優勢在於它的限制比較少，它容許各個角色在各個階段的失敗和重複執行，這也是分佈式環境下常有的事情，只要大夥按照規矩辦事便可，算法的自己保障了在錯誤發生時仍然獲得一致的結果。

3. 算法的實現

Paxos的實現有不少版本，最有名的就是google chubby ，不過看不了源碼。開源的實現可見libpaxos。另外，ZooKeeper 也基於paxos解決數據一致性問題，也能夠看看它是若是實現paxos的。

4. 適用場景

• database replication, log replication等， 如bdb的數據複製就是使用paxos兼容的算法。Paxos最大的用途就是保持多個節點數據的一致性。

• naming service, 如大型系統內部一般存在多個接口服務相互調用。

（1）一般的實現是將服務的ip/hostname寫死在配置中，當service發生故障時候，經過手工更改配置文件或者修改DNS指向的方法來解決。缺點是可維護性差，內部的單元越多，故障率越大。

（2）LVS雙機冗餘的方式，缺點是全部單元須要雙倍的資源投入。

經過Paxos算法來管理全部的naming服務，則可保證high available分配可用的service給client。象ZooKeeper還提供watch功能，即watch的對象發生了改變會自動發notification, 這樣全部的client就可使用一致的，高可用的接口。

• config配置管理

（1）一般手工修改配置文件的方法，這樣容易出錯，也須要人工干預才能生效，因此節點的狀態沒法同時達到一致。

（2）大規模的應用都會實現本身的配置服務，好比用http web服務來實現配置中心化。它的缺點是更新後全部client沒法當即得知，各節點加載的順序沒法保證，形成系統中的配置不是同一狀態。

這裏列舉了一些常見的Paxos應用場合，對於相似上述的場合，若是用其它解決方案，一方面不能提供自動的高可用性方案，同時也遠遠沒有Paxos實現簡單及優雅。

##2.2 一致性Hash算法##

1. 問題描述

分佈式經常用Hash算法來分佈數據，當數據節點不變化時是很是好的，但當數據節點有增長或減小時，因爲須要調整Hash算法裏的模，致使全部數據得從新按照新的模分佈到各個節點中去。若是數據量龐大，這樣的工做經常是很難完成的。一致性Hash算法是基於Hash算法的優化，經過一些映射規則解決以上問題。

2. 算法自己

實際上，在其餘設計和開發領域咱們也能夠借鑑一致性Hash的思路，當一個映射或規則致使有難以維護的問題時，能夠考慮更一步抽象這些映射或規則，經過規則的變化使得最終數據的不變。一致性hash實際就是把之前點映射改成區段映射，使得數據節點變動後其餘數據節點變更儘量小。這個思路在操做系統對於存儲問題上體現不少，好比操做系統爲了更優化地利用存儲空間，區分了段、頁等不一樣緯度，加了不少映射規則，目的就是要經過靈活的規則避免物理變更的代價。

3. 算法實現

一致性Hash算法自己比較簡單，不過能夠根據實際狀況有不少改進的版本，其目的無非是兩點：

• 節點變更後其餘節點受影響儘量小
• 節點變更後數據從新分配儘量均衡

實現這個算法就技術自己來講沒多少難度和工做量，須要作的是創建起你所設計的映射關係，無需藉助什麼框架或工具，sourceforge上卻是有個項目libconhash，能夠參考一下。

分佈式環境中大多數服務是容許部分失敗，也容許數據不一致，但有些最基礎的服務是須要高可靠性，高一致性的，這些服務是其餘分佈式服務運轉的基礎，好比naming service、分佈式lock等，這些分佈式的基礎服務有如下要求：

• 高可用性
• 高一致性
• 高性能

對於這種有些挑戰CAP原則的服務該如何設計，是一個挑戰，也是一個不錯的研究課題，Apache的ZooKeeper也許給了咱們一個不錯的答案。ZooKeeper是一個分佈式的，開放源碼的分佈式應用程序協調服務， 它暴露了一個簡單的原語集，分佈式應用程序能夠基於它實現同步服務，配置維護和命名服務等。