為什麼要搭建zookeeper叢集?
這個一般都沒啥好說的,就是因為可能一台zookeeper可能會出現當機的情況,為了提升系統的穩定性,就要多部署到幾台機器上,還有一點就是在量很大的情況下一台機器撐不住隻有多擴幾台機器去分擔壓力。但是就會存在一個問題:如果要多部署幾台,那麼不同的機器接到了不同的請求就會做不一樣的事,導緻每台伺服器都不一樣。
有人會說就不能像業務系統那樣嗎?比如把多台伺服器對應到同一個資料庫中,其中一台發生了改變其它自動更新?
請想一想如果資料庫連不上了呢?有人說那我可以把資料庫做成叢集啊。要是這樣做的話你想想你想寫一個叢集卻使用了資料庫的叢集技術,而且資料庫使用的分布式鎖效率都不高,zookeeper正是因為資料庫的效率的問題才産生的。而且當多台伺服器從資料庫讀的話,那一瞬間的壓力會不會很大,最終的壓力全都壓在了資料庫上了,不要扯使用redis緩存之類的。redis存在的問題用過的都知道。而且重點是zookeeper是為了解決分布式的一緻性問題,redis使用存在缺陷。
zookeeper叢集是怎麼做的?
首先回顧一下前面zookeeper單機的情景。它的啟動的确很簡單,無非就是把配置讀到類中,讀取一下快照和事務,然後做一個調用鍊就行了。
假設你來設計一個zookeeper叢集,因為你是為了解決上面資料庫和redis的分布式鎖的缺點而設計的,你會怎麼做?
首先肯定大體邏輯跟單機是一樣的。最重要的是要保證一緻性。
1、假設我們每次做了修改就通告給所有的zookeeper。
那麼如果有的zookeeper沒有啟動怎麼辦呢?作為叢集,不可能挂掉一台就不工作了吧,你說沒有啟動我就儲存到本地,直到那台啟動了在傳給它,那麼如果這台機器漏掉了或者出現了大故障導緻以前的資料也不在了怎麼辦呢?難道你會想資料庫一樣全量拷貝一份嗎?或者你想加一台機器進去是不是要手動同步?你現在同步應該以哪一台機器為準?因為是其中一台做了修改通告其它的對吧?是以如果資料儲存本地的話,這種方法問題太多了。
2、選擇一台作為主,其它的作為從(跟資料庫類似)。
一般都是這麼做的。所有有關寫的操作都由主來确定,其它從伺服器來從主這邊同步資料對吧,那麼選主應該怎麼選呢?資料應該怎麼同步呢?有關寫的操作連接配接到從了怎麼辦呢?怎麼保證zookeeper中多個資料的一緻性呢?這些就是zookeeper重要的實作方式,後面會一一的開始講。先放一張總體流程圖。

這個還隻是一個大概的,要是細寫流程圖的話恐怕會特别特别大。最重要的一點就是zookeeper使用的是多線程,多線程的調試遠比普通的調試要麻煩,不信的話可以自行去嘗試。這個現在肯定看起很懵。後面的文章來慢慢的講解。