Storm之Zookeeper安裝部署

ZooKeeper 導讀

CAP理論概述

一個分布式系統最多只能同時滿足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance）這三項中的兩項。

CAP的定義

Consistency 一致性:

一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客戶端完成后，所有節點在同一時間的數據完全一致。對于一致性，可以分為從客戶端和服務端兩個不同的視角。從客戶端來看，一致性主要指的是多并發訪問時更新過的數據如何獲取的問題。從服務端來看，則是更新如何復制分布到整個系統，以保證數據最終一致。一致性是因為有并發讀寫才有的問題，因此在理解一致性的問題時，一定要注意結合考慮并發讀寫的場景。

從客戶端角度，多進程并發訪問時，更新過的數據在不同進程如何獲取的不同策略，決定了不同的一致性。對于關系型數據庫，要求更新過的數據能被后續的訪問都能看到，這是強一致性。如果能容忍后續的部分或者全部訪問不到，則是弱一致性。如果經過一段時間后要求能訪問到更新后的數據，則是最終一致性。

Availability 可用性:

可用性指“Reads and writes always succeed”，即服務一直可用，而且是正常響應時間。對于一個可用性的分布式系統，每一個非故障的節點必須對每一個請求作出響應。也就是，該系統使用的任何算法必須最終終止。當同時要求分區容忍性時，這是一個很強的定義：即使是嚴重的網絡錯誤，每個請求必須終止。好的可用性主要是指系統能夠很好的為用戶服務，不出現用戶操作失敗或者訪問超時等用戶體驗不好的情況。通常情況下可用性和分布式數據冗余，負載均衡等有著很大的關聯。

Partition Tolerance分區容錯性:

分區容錯性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。 分區容錯性和擴展性緊密相關。在分布式應用中，可能因為一些分布式的原因導致系統無法正常運轉。好的分區容錯性要求能夠使應用雖然是一個分布式系統，而看上去卻好像是在一個可以運轉正常的整體。比如現在的分布式系統中有某一個或者幾個機器宕掉了，其他剩下的機器還能夠正常運轉滿足系統需求，或者是機器之間有網絡異常，將分布式系統分隔未獨立的幾個部分，各個部分還能維持分布式系統的運作，這樣就具有好的分區容錯性。

CAP權衡

通過CAP理論，我們知道無法同時滿足一致性、可用性和分區容錯性這三個特性，那要舍棄哪個呢？

CA without P：如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但其實分區不是你想不想的問題，而是始終會存在，因此CA的系統更多的是允許分區后各子系統依然保持CA。

CP without A：如果不要求A（可用），相當于每個請求都需要在Server之間強一致，而P（分區）會導致同步時間無限延長，如此CP也是可以保證的。很多傳統的數據庫分布式事務都屬于這種模式。

AP wihtout C：要高可用并允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯系，為了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。現在眾多的NoSQL都屬于此類。

對于多數大型互聯網應用的場景，主機眾多、部署分散，而且現在的集群規模越來越大，所以節點故障、網絡故障是常態，而且要保證服務可用性達到N個9，即保證P和A，舍棄C（退而求其次保證最終一致性）。雖然某些地方會影響客戶體驗，但沒達到造成用戶流失的嚴重程度。

對于涉及到錢財這樣不能有一絲讓步的場景，C必須保證。網絡發生故障寧可停止服務，這是保證CA，舍棄P。貌似這幾年國內銀行業發生了不下10起事故，但影響面不大，報到也不多，廣大群眾知道的少。還有一種是保證CP，舍棄A。例如網絡故障事只讀不寫。

Zookeeper 定義

ZooKeeper是一個分布式的，開放源碼的分布式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟件，提供的功能包括：配置維護、名字服務、分布式同步、組服務等。它使用Java語言編寫，通過ZAB協議來保證節點的一致性。ZooKeeper的目標就是封裝好復雜易出錯的關鍵服務，將簡單易用的接口和性能高效、功能穩定的系統提供給用戶。

Zookeeper 基礎環境搭建

1. 使用VMware（用戶根據自己需要選擇Virtualbox/docker等工具）安裝centos系統

2. 配置centos系統的網絡連接方式為橋接模式，使虛擬機可以上網

a) 點擊“編輯”按鈕，選擇“虛擬網絡編輯器”

b) 修改上網方式為橋接模式

c) 查看主機是否獲取了IP地址

d) 通過dhclient命令獲取IP地址

3. 創建hadoop賬戶并配置密碼

4. 切換到hadoop賬戶下

cd直接回車，切換到hadoop的主目錄下

5. 安裝Java

命令安裝比較簡單：yum install java-1.8.0-openjdk-devel

下面主要介紹下載安裝

a) 下載JAVA安裝包

wget http://download.oracle.com/otn-pub/java/jdk/8u66-b17/jdk-8u66-linux-x64.tar.gz

b) 創建java目錄，并將安裝包移到java目錄下

c) 進入java目錄，并解壓該安裝包

d) 配置環境變量

編輯主目錄下的.bashrc文件，添加java路徑

e) 退出hadoop賬戶再重新進入，測試java能否執行

6. 安裝Zookeeper

a) 下載zookeeper安裝包

wget http://mirrors.cnnic.cn/apache/zookeeper/zookeeper-3.4.6/zookeeper-3.4.6.tar.gz

b) 創建zookeeper目錄，并將zookeeper安裝包移到zookeeper目錄下

c) 進入zookeeper目錄，并解壓zookeeper壓縮包

d) 配置環境變量

編輯主目錄下的.bashrc文件，添加zookeeper路徑

e) 退出hadoop賬戶再重新進入,查看環境變量是否導出

f) Zookeeper配置文件修改

創建/var/data/zookeeper文件夾，用于保存zookeeper數據

切到zookeeper配置文件下，修改配置

g) 修改/etc/hostname文件

這樣，我們以后就可以通過nimbus、slave1、slave2找到相應的機器，而不用記住IP地址

h) 添加Host-only網卡，組成內部網絡 關閉虛擬機，點擊“編輯虛擬機配置”選項

點擊“添加”選項

點擊“網絡適配器”，繼續

選擇“僅主機模式”完成

i) 根據該虛擬機clone出slave1、slave2兩個虛擬機 這樣我們就可以共享對第一臺機器的修改了。

點擊“克隆

點擊“下一步”

點擊“下一步”

此時兩個虛擬機的環境和第一臺是一樣，均已安裝好java、zookeeper等軟件。

j) 啟動三臺虛擬機，并分別修改主機名稱

在root賬戶下，分別執行如下命令:

hostnamectl –static set-hostname nimbus

hostnamectl –static set-hostname slave1

hostnamectl –static set-hostname slave2

退出后重新登陸，可以看到hostname名稱已經生效

k) 修改host-only網卡靜態IP配置，保證每次重啟后，該網卡的IP不會改變

nimbus機器的修改如下:

將slave1的 IPADDR0設置為172.xx.1.2

將slave2的 IPADDR0設置為172.xx.1.3

注意：這些IP地址和“g）修改/etc/hostname文件”的IP地址是對應的。

l) 重啟機器，確保上步修改的IP地址生效

nimbus擁有IP 172.xx.1.1

slave1擁有IP 172.xx.1.2

slave2擁有IP 172.xx.1.3

在nimbus上分別ping nimbus、salve1和slave2，查看ip地址是否正確以及網絡是否正常：

m) 分別修改nimbus、slave1、slave2的zookeeper id

nimbus機器

參考“ f）Zookeeper配置文件修改”

slave1機器

slave2機器

n) 以hadoop賬號分別啟動zookeeper進程

nimbus：

slave1:

slave2:

o) 查看zookeeper狀態

分別在nimbus、slave2、slave3節點查看狀態：

各個節點的狀態正常，zookeeper集群搭建成功

可以通過zkCli.sh連到zookeeper集群看看集群內部結構

分布式 網絡 TCP/IP ZooKeeper

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。