分佈式系統技術概要算法
如今互聯網應用,尤爲是大型互聯網公司的應用已經發展爲大規模或超大規模的分佈式的,集羣化的應用。而中小規模的分佈式應用也已普遍出如今各個領域。將來,隨着雲計算向社會生活的方方面面去滲透,分佈式應用將更加地普及。因此,任何一個要從事服務器端應用開發的人員,都有具有對分佈式應用的基本認識。數據庫
本文將簡要介紹分佈式應用的各基本領域的相關技術。這些技術在一個分佈式應用中都會有或多或少的設計,即使暫時沒有涉及到,設計人員也要有所考慮,保證系統有進一步發展的空間。服務器
1. 集羣管理併發
關鍵字:Apache Zookeeper、Paxos 算法、Etcd、Raft、Apache Curator框架
在一個分佈式系統中,存在着一些和系統運行,以及重要業務緊密相關的數據,如節點相關的數據、應用服務和數據服務相關的數據等,這些數據對集羣的正常運行相當重要。分佈式
服務器節點相關數據:服務器的地址、狀態雲計算
服務相關數據:服務的IP、端口、版本、協議、狀態、主備節點信息設計
數據庫相關數據:路由規則、分庫分表規則隊列
這些重要的數據在分佈式系統中存在着多份拷貝,以保證高可用性。但這產生了另一個問題,就是如何保證這些數據的一致性。由於這些數據是如此重要,不一致的數據會產生嚴重甚至致命的錯誤。在一個小規模的分佈式系統中,由於能夠用一兩臺服務器去作集羣管理,因此數據的一致性容易實現。可是對於一個大規模的分佈式系統,一兩臺集羣配置管理服務器沒法支撐整個集羣所帶來的大量併發讀寫操做,因此要使用幾臺、十幾臺,甚至更多的服務器去支撐這些請求。此時,就須要一個保持這些服務器中集羣配置數據的一致性的方案了。路由
這衆多方案中,Paxos 算法算是最佳方案之一。關於 Paxos 算法的內容,不在這裏詳述了。簡單描述就是集羣中各節點相互以提議的方式通訊(對一項數據的修改),提議中帶有不斷增長的 ID 號,節點永遠贊成當前 ID 號最大的提議,並拒絕其它提議。當有半數以上節點贊成一項提議以後,這個提議便被整個節點所接受並採納。
1.1. Apache Zookeeper
Paxos 算法的語言表述看上去不難,可是其中的技術難點並很多。好在如今已經有了不少的解決方案,其中最爲著名的即是 Apache Zookeeper。Zookeeper 不只能夠用來存儲配置數據,還能夠用來實現集羣 Master 選舉、分佈式鎖等場景。Apache Curator 是 Zookeeper 的客戶端,能夠簡化對 Zookeeper 的使用,實現各式的場景。
Zookeeper 是一個分佈式的服務管理框架。Zookeeper 的典型的應用場景包括配置文件的管理、集羣管理、分佈式鎖、Leader 選舉、隊列管理等。Zookeeper 可工做在集羣模式下,zoo.cfg 中記錄着集羣中全部 Zookeeper 服務器的地址,每一個服務器有本身惟一的 ID。同時,每一個服務器在本身的 dataDir 目錄下還要有一個 myid 文件,以標示本身的 ID。在 Zookeeper 中,數據以樹狀的結構存儲,相似於 LDAP 數據庫。
如今相似 Zookeeper 的項目還有使用 go 語言實現的 Etcd。