1.集群概述
1.1什么是集群
1.1.1集群概念
集群是一種計算機系統， 它通過一組松散集成的計算機軟件和/或硬件連接起來高度緊密地協作完成計算工作。在某種意義上，他們可以被看作是一台計算機。集群系統中的單個計算機通常稱為節點，通常通過局域網連接，但也有其它的可能連接方式。集群計算機通常用來改進單個計算機的計算速度和/或可靠性。一般情況下集群計算機比單個計算機，比如工作站或超級計算機性能價格比要高得多。
1.1.2集群的特點
集群擁有以下兩個特點：
1. 可擴展性：集群的性能不限制於單一的服務實體，新的服務實體可以動態的添加到集群，從而增強集群的性能。
2. 高可用性：集群當其中一個節點發生故障時，這台節點上面所運行的應用程序將在另一台節點被自動接管，消除單點故障對於增強數據可用性、可達性和可靠性是非常重要的。
1.1.3集群的兩大能力
1. 負載均衡：負載均衡把任務比較均勻的分布到集群環境下的計算和網絡資源，以提高數據吞吐量。
2. 錯誤恢復：如果集群中的某一台服務器由於故障或者維護需要無法使用，資源和應用程序將轉移到可用的集群節點上。這種由於某個節點的資源不能工作，另一個可用節點中的資源能夠透明的接管並繼續完成任務的過程，叫做錯誤恢復。
負載均衡和錯誤恢復要求各服務實體中有執行同一任務的資源存在，而且對於同一任務的各個資源來說，執行任務所需的信息視圖必須是相同的。
補充：可能會有人問服務器集群是怎么實現負載均衡的？
當系統面臨大量用戶訪問，負載過高的時候，通常會使用增加服務器數量來進行橫向擴展，使用集群和負載均衡提高整個系統的處理能力。
而我們討論的負載均衡一般分為兩種，一種是基於DNS，另一種基於IP報文。
利用DNS實現負載均衡，就是在DNS服務器配置多個A記錄，不同的DNS請求會解析到不同的IP地址。大型網站一般使用DNS作為第一級負載均衡。
缺點是DNS生效時間略長，擴展性差。
基於IP的負載均衡，早期比較有代表性並且被大量使用的的就是LVS了。原理是LVS在Linux內核態獲取到IP報文后，根據特定的負載均衡算法將IP報文轉發到整個集群的某台服務器中去。
缺點是LVS的性能依賴Linux內核的網絡性能，但Linux內核的網絡路徑過長導致了大量開銷，使得LVS單機性能較低。
那么有沒有更好的負載均衡技術呢？當然有。詳情請參照知乎https://www.zhihu.com/question/22610352/answer/126894813
從Google Maglev說起，如何造一個牛逼的負載均衡？
1.2集群與分布式的區別
說到集群，可能大家會立刻聯想到另一個和它很相近的一個詞----“分布式”。那么集群和分布式是一回事嗎？有什么聯系和區別呢?
相同點：
分布式和集群都是需要有很多節點服務器通過網絡協同工作完成整體的任務目標。
不同點：
分布式是指將業務系統進行拆分，即分布式的每一個節點都是實現不同的功能。而集群每個節點做的是同一件事情。
2.Zookeeper集群
2.1 Zookeeper集群簡介
2.1.1為什么搭建Zookeeper集群
大部分分布式應用需要一個主控、協調器或者控制器來管理物理分布的子進程。目前，大多數都要開發私有的協調程序，缺乏一個通用機制，協調程序的反復編寫浪費，且難以形成通用、伸縮性好的協調器，zookeeper提供通用的分布式鎖服務，用以協調分布式應用。所以說zookeeper是分布式應用的協作服務。
zookeeper作為注冊中心，服務器和客戶端都要訪問，如果有大量的並發，肯定會有等待。所以可以通過zookeeper集群解決。
下面是zookeeper集群部署結構圖：
2.1.2了解Leader選舉
Zookeeper的啟動過程中leader選舉是非常重要而且最復雜的一個環節。那么什么是leader選舉呢？zookeeper為什么需要leader選舉呢？zookeeper的leader選舉的過程又是什么樣子的？
首先我們來看看什么是leader選舉。其實這個很好理解，leader選舉就像總統選舉一樣，每人一票，獲得多數票的人就當選為總統了。在zookeeper集群中也是一樣，每個節點都會投票，如果某個節點獲得超過半數以上的節點的投票，則該節點就是leader節點了。
以一個簡單的例子來說明整個選舉的過程.
假設有五台服務器組成的zookeeper集群,它們的id從1-5,同時它們都是最新啟動的,也就是沒有歷史數據,在存放數據量這一點上,都是一樣的.假設這些服務器依序啟動,來看看會發生什么 。
1) 服務器1啟動,此時只有它一台服務器啟動了,它發出去的報沒有任何響應,所以它的選舉狀態一直是LOOKING狀態
2) 服務器2啟動,它與最開始啟動的服務器1進行通信,互相交換自己的選舉結果,由於兩者都沒有歷史數據,所以id值較大的服務器2勝出,但是由於沒有達到超過半數以上的服務器都同意選舉它(這個例子中的半數以上是3),所以服務器1,2還是繼續保持LOOKING狀態.
3) 服務器3啟動,根據前面的理論分析,服務器3成為服務器1,2,3中的老大,而與上面不同的是,此時有三台服務器選舉了它,所以它成為了這次選舉的leader.
4) 服務器4啟動,根據前面的分析,理論上服務器4應該是服務器1,2,3,4中最大的,但是由於前面已經有半數以上的服務器選舉了服務器3,所以它只能接收當小弟的命了.
5) 服務器5啟動,同4一樣,當小弟
2.2搭建Zookeeper集群
2.2.1搭建要求
真實的集群是需要部署在不同的服務器上的，但是在我們測試時同時啟動十幾個虛擬機內存會吃不消，所以這里我們搭建偽集群，也就是把所有的服務都搭建在一台虛擬機上，用端口進行區分。
我們這里要求搭建一個三個節點的Zookeeper集群（偽集群）。
2.2.2准備工作
重新部署一台虛擬機作為我們搭建集群的測試服務器。(虛擬機的准備詳見我在CSDN寫的一篇文章：Zookeeper集群安裝之虛擬機准備)
（1）安裝JDK 【此步驟省略】。
（2）Zookeeper壓縮包上傳到服務器
（3）將Zookeeper解壓 ，創建data目錄 ，將 conf下zoo_sample.cfg 文件改名為 zoo.cfg【mv zoo_sample.cfg zoo.cfg】
（4）建立/usr/local/zookeeper-cluster目錄，將解壓后的Zookeeper復制到以下三個目錄
[root@mini1 ~]# cp -r zookeeper-3.4.5 /usr/local/zookeeper-cluster/zookeeper-1 [root@mini1 ~]# cp -r zookeeper-3.4.5 /usr/local/zookeeper-cluster/zookeeper-2 [root@mini1 ~]# cp -r zookeeper-3.4.5 /usr/local/zookeeper-cluster/zookeeper-3
（5） 配置每一個Zookeeper 的dataDir（zoo.cfg） clientPort 分別為2181 2182 2183
修改/usr/local/zookeeper-cluster/zookeeper-1/conf/zoo.cfg
修改/usr/local/zookeeper-cluster/zookeeper-2/conf/zoo.cfg
clientPort=2182 dataDir=/usr/local/zookeeper-cluster/zookeeper-2/data
修改/usr/local/zookeeper-cluster/zookeeper-3/conf/zoo.cfg
clientPort=2183 dataDir=/usr/local/zookeeper-cluster/zookeeper-3/data
2.2.3配置集群
（1）在每個zookeeper的 data 目錄下創建一個 myid 文件，內容分別是1、2、3 。這個文件就是記錄每個服務器的ID
（2）在每一個zookeeper 的 zoo.cfg配置客戶端訪問端口（clientPort）和集群服務器IP列表。
server.1=192.168.75.10:2881:3881 server.2=192.168.75.10:2882:3882 server.3=192.168.75.10:2883:3883
解釋：server.服務器ID=服務器IP地址：服務器之間通信端口：服務器之間投票選舉端口
2.2.4啟動集群
啟動集群就是分別啟動每個實例。
cd /usr/local/zookeeper-cluster/zookeeper-1/bin/ ./zkServer.sh start cd /usr/local/zookeeper-cluster/zookeeper-2/bin/ ./zkServer.sh start cd /usr/local/zookeeper-cluster/zookeeper-3/bin/ ./zkServer.sh start
啟動后我們查詢一下每個實例的運行狀態
先查詢第一個服務
Mode為follower表示是跟隨者（從）
再查詢第二個服務Mod 為leader表示是領導者（主）
查詢第三個為跟隨者（從）
之前在CSDN上寫了一篇SolrCloud 分布式集群安裝部署（solr+ zookeeper +tomcat）有興趣的朋友可以看一下！