Zookeeper叢集和SolrCloud叢集和redis叢集.md
一. 叢集與分散式
什麼是叢集
- 多個節點幹相同的事情
- 生活小栗子: 賽龍舟中每個划槳的人都是一個節點, 每個節點做相同的事情, 這就是叢集.
什麼是分散式
- 多個節點協同完成一件事情, 每個節點做不同的事情
- 生活小栗子: 樂隊中有的人彈吉他, 有的人打鼓, 有的人吹號. 並且共同完成一次演出, 這就是分散式.
叢集與分散式
- 不管在生活中, 還是在我們的實際專案中, 叢集與分散式大多都是同時出現的.
- 生活小栗子: 賽龍舟中划槳的人, 與打鼓的, 人與掌舵的人分別做不同的事情, 卻共同完成賽龍舟這件事情, 這就是分散式. 同時划槳的多個人做著相同的事情, 這就是叢集. 可見分散式與叢集是同時出現的.
- 相同點與區別: 相信看完上面的簡述和小栗子, 大家已經對叢集和分散式的相同點和區別有了理解, 這裡就不多贅述了.
二. Zookeeper叢集
Zookeeper介紹
為什麼搭建Zookeeper叢集
- 高併發的情況下, 單機版效能不夠.
- 小栗子: 我的飯店一開始客人較少, 我招一個廚師炒菜即可. 後來我的飯店客人越來越多, 一個廚師不夠用了, 所以就需要再招幾個廚師.
- 單機版不具備高可用行.
- 小栗子: 依然是飯店的栗子, 如果我只有一個廚師, 那當我的廚師生病了, 那我的飯店就掛掉了, 顯然這樣是不具備高可用性的.
Zookeeper的leader選舉
-
為什麼需要leader選舉
- 其實可以類比想一下國家為什麼要選舉國家總統? 當然是為了更好的治理國家. 為什麼需要政府? 只有一個超然於所以團體之上的勢力, 才可以統一排程共有資源, 協調各團體關係, 為各團體制定規則, 以及集中力量辦大事… 咳, 扯遠了, 總之就是為了保證分散式資料的一致性的.
-
什麼時候會出現leader選舉
-
伺服器初始化啟動的時候.
小栗子: 回想你大一新生剛剛入學的時候, 是不是班級都會選舉一個班長出來?
-
伺服器執行期間無法和leader保持連線.
這個更簡單了, leader掛掉了, 自然需要重新選舉了.
-
-
選舉的規則, 也就是說憑什麼你當老大
-
伺服器ID
比如有三臺伺服器, 編號分別是1,2,3
那麼編號越大在選擇演算法中的權重越大. (很粗暴, 誰編號大誰就厲害)
-
資料ID
伺服器中存放的最大資料ID
值越大說明資料越新, 在選舉演算法中權重越大.
-
超過半數投票者為leader
這就是選舉的核心了, 只要有半數以上投票就是leader了, 後面的即便伺服器ID比我高, 那你也只能是following了.
-
-
選舉的狀態
- LOOKING，競選狀態。
- FOLLOWING，隨從狀態，同步leader狀態，參與投票。
- OBSERVING，觀察狀態,同步leader狀態，不參與投票。
- LEADING，領導者狀態。
-
以一個小栗子說明整個選舉的過程
假設有五臺伺服器組成的zookeeper叢集, 它們的id從1-5, 同時它們都是最新啟動的, 也就是沒有歷史資料 (所以我們就只需要考慮伺服器ID即可, 不用考慮資料了). 假設這些伺服器依序啟動, 來看看會發生什麼。
- 伺服器1啟動, 先投自己一票, 然後就是looking狀態.
- 伺服器2啟動, 先投自己一票, 然後與伺服器1進行通訊, 互換選舉結果, 由於兩者都沒有歷史資料, 所以id值較大的伺服器2勝出, 但是由於沒有達到超過半數以上的伺服器都同意選舉它(這個例子中的半數以上是3), 所以伺服器1,2還是繼續保持LOOKING狀態.
- 伺服器3啟動, 先投自己一票, 然後進行通訊所以理所當然伺服器3票數最多, 但這次不一樣了, 因為這次已經有3臺伺服器投給了它, 所以它的票數已經超過了半數, 所以自動當選為leader.
- 伺服器4啟動, 根據前面的分析, 理論上伺服器4應該是伺服器1,2,3,4中最大的, 但是由於前面已經有半數以上的伺服器選舉了伺服器3, 所以它只能接收當小弟的命了.
- 伺服器5啟動, 同4一樣,當小弟.
搭建Zookeeper叢集
準備工作
接下來我們來搭建一個三個節點的Zookeeper叢集（偽叢集）。什麼是偽叢集? 就是在一臺伺服器上不同埠的三個Zookeeper組成. 注意要不同埠.
- 虛擬機器 (下面栗子中使用VMware)
- linux系統 (下面栗子中使用CentOS 6)
- 遠端連線linux (下面栗子中使用X Shell)
- 安裝好linux後, 在系統中安裝好jdk (下面按照了jdk8)
上面幾步就不在筆記中寫了, 相信有一定linux基礎的人都沒有問題.
第一步: 上傳Zookeeper安裝包, 並解壓縮
第二步: 將解壓好的Zookeeper資料夾複製3份出來
修改配置
第三步: 修改配置檔案zoo.cfg 中埠和dataDir的目錄
三個Zookeeper都修改一遍, dataDir分別對應自己的data目錄, 埠分別為2181, 2182, 2183.
首先修改配置檔案的名字為zoo.cfg
-------------------------------------------------
[[email protected] zookeeper-1]# mkdir data
[[email protected] zookeeper-1]# cd conf
[[email protected] conf]# mv zoo_sample.cfg zoo.cfg
然後修改配置檔案zoo.cfg 中埠和dataDir的目錄
-------------------------------------------------
[[email protected] conf]# vim zoo.cfg
第四步: 給每個Zookeeper一個自己的編號, 放在data目錄下的myid檔案中
[[email protected] zookeeper-cluster]# echo 1 > /usr/local/zookeeper-cluster/zookeeper-1/data/myid
[[email protected] zookeeper-cluster]# echo 2 > /usr/local/zookeeper-cluster/zookeeper-2/data/myid
[[email protected] zookeeper-cluster]# echo 3 > /usr/local/zookeeper-cluster/zookeeper-3/data/myid
第五步: 在每個節點上配置整個叢集的所有伺服器IP列表
讓所有節點都知道我這個伺服器上有多少個節點.
在每個Zookeeper的conf/zoo.cfg配置檔案末尾加
server.{編號}={伺服器IP}.{Zookeeper之間相互通訊的埠}.{Zookeeper投票選舉的埠}
---------------------------------------------
server.1=192.168.179.133:2881:3881
server.2=192.168.179.133:2882:3882
server.3=192.168.179.133:2883:3883
第六步: 到這裡我們就配置完成了, 接下來就可以測試了
進入Zookeeper的bin目錄下, 啟動即可
./zkServer.sh start
-------------------------------
可以檢視狀態
./zkServer.sh status
可以看到, 我們在啟動2號Zookeeper的時候, 2號的狀態已經是leader了.
安裝Zookeeper叢集還是挺簡單的吧? 我們稍稍總結下我們都做了什麼事情.
- 上傳解壓Zookeeper資料夾, 並複製三份出來
- 修改每個Zookeeper的配置資料夾
- dataDir目錄
- 埠號
- 整個叢集所有節點的IP列表
- 給每個Zookeeper一個編號
- 我們是在data目錄下的myid檔案中分別給了1,2,3的編號
測試高可用性
我們選擇直接將leader給Stop掉, 模擬leader宕機的現象, 我們來看看是否還能正常工作呢?
進入編號為2的Zookeeper的bin目錄中, 執行下面語句
./zkServer.sh stop
按照我們的思考, 當leader掛掉的時候會自動開始選舉, 那麼編號最大的3號Zookeeper應該成為leader, 那麼我們就看下是否如此呢?
進入編號為3的Zookeeper中, 檢視狀態
./zkServer.sh status
我們看到了下面的結果:
很顯然, 我們的3號Zookeeper成為了leader. 叢集依然正常執行.
那麼, 就有個問題了
問題一: 如果我再把3號Zookeeper停掉呢? 叢集還能正常工作嗎?
問題二: 在叢集中, 有2n+1個節點, 最多允許多少個節點掛掉呢 ?