Zookeeper與Kafka基礎(chǔ)概念和原理

1、zookeeper概念介紹

　　在介紹ZooKeeper之前，先來介紹一下分布式協(xié)調(diào)技術(shù)，所謂分布式協(xié)調(diào)技術(shù)主要是用來解決分布式環(huán)境當(dāng)中多個進程之間的同步控制，讓他們有序的去訪問某種共享資源，防止造成資源競爭（腦裂）的后果。

　　這里首先介紹下什么是分布式系統(tǒng)，所謂分布式系統(tǒng)就是在不同地域分布的多個服務(wù)器，共同組成的一個應(yīng)用系統(tǒng)來為用戶提供服務(wù)，在分布式系統(tǒng)中最重要的是進程的調(diào)度，這里假設(shè)有一個分布在三個地域的服務(wù)器組成的一個應(yīng)用系統(tǒng)，在第一臺機器上掛載了一個資源，然后這三個地域分布的應(yīng)用進程都要競爭這個資源，但我們又不希望多個進程同時進行訪問，這個時候就需要一個協(xié)調(diào)器，來讓它們有序的來訪問這個資源。這個協(xié)調(diào)器就是分布式系統(tǒng)中經(jīng)常提到的那個“鎖”，例如”進程1“在使用該資源的時候，會先去獲得這把鎖，”進程1“獲得鎖以后會對該資源保持獨占，此時其它進程就無法訪問該資源，“進程1”;在用完該資源以后會將該鎖釋放掉，以便讓其它進程來獲得鎖。由此可見，通過這個“鎖”機制，就可以保證分布式系統(tǒng)中多個進程能夠有序的訪問該共享資源。這里把這個分布式環(huán)境下的這個“鎖”叫作分布式鎖。這個分布式鎖就是分布式協(xié)調(diào)技術(shù)實現(xiàn)的核心內(nèi)容。

　　目前，在分布式協(xié)調(diào)技術(shù)方面做得比較好的有Google的Chubby，還有Apache的ZooKeeper，它們都是分布式鎖的實現(xiàn)者。ZooKeeper所提供鎖服務(wù)在分布式領(lǐng)域久經(jīng)考驗，它的可靠性、可用性都是經(jīng)過理論和實踐驗證的。

　　ZooKeeper是一種為分布式應(yīng)用所設(shè)計的高可用、高性能的開源協(xié)調(diào)服務(wù)，它提供了一項基本服務(wù)：分布式鎖服務(wù)，同時，也提供了數(shù)據(jù)的維護和管理機制，如：統(tǒng)一命名服務(wù)、狀態(tài)同步服務(wù)、集群管理、分布式消息隊列、分布式應(yīng)用配置項的管理等等。

2、zookeeper應(yīng)用舉例

1）什么是單點故障問題呢？

　　所謂單點故障，就是在一個主從的分布式系統(tǒng)中，主節(jié)點負責(zé)任務(wù)調(diào)度分發(fā)，從節(jié)點負責(zé)任務(wù)的處理，而當(dāng)主節(jié)點發(fā)生故障時，整個應(yīng)用系統(tǒng)也就癱瘓了，那么這種故障就稱為單點故障。那我們的解決方法就是通過對集群master角色的選取，來解決分布式系統(tǒng)單點故障的問題。

2）傳統(tǒng)的方式是怎么解決單點故障的？以及有哪些缺點呢？

　　傳統(tǒng)的方式是采用一個備用節(jié)點，這個備用節(jié)點定期向主節(jié)點發(fā)送ping包，主節(jié)點收到ping包以后向備用節(jié)點發(fā)送回復(fù)Ack信息，當(dāng)備用節(jié)點收到回復(fù)的時候就會認為當(dāng)前主節(jié)點運行正常，讓它繼續(xù)提供服務(wù)。而當(dāng)主節(jié)點故障時，備用節(jié)點就無法收到回復(fù)信息了，此時，備用節(jié)點就認為主節(jié)點宕機，然后接替它成為新的主節(jié)點繼續(xù)提供服務(wù)。

　　這種傳統(tǒng)解決單點故障的方法，雖然在一定程度上解決了問題，但是有一個隱患，就是網(wǎng)絡(luò)問題，可能會存在這樣一種情況：主節(jié)點并沒有出現(xiàn)故障，只是在回復(fù)ack響應(yīng)的時候網(wǎng)絡(luò)發(fā)生了故障，這樣備用節(jié)點就無法收到回復(fù)，那么它就會認為主節(jié)點出現(xiàn)了故障，接著，備用節(jié)點將接管主節(jié)點的服務(wù)，并成為新的主節(jié)點，此時，分布式系統(tǒng)中就出現(xiàn)了兩個主節(jié)點（雙Master節(jié)點）的情況，雙Master節(jié)點的出現(xiàn)，會導(dǎo)致分布式系統(tǒng)的服務(wù)發(fā)生混亂。這樣的話，整個分布式系統(tǒng)將變得不可用。為了防止出現(xiàn)這種情況，就需要引入ZooKeeper來解決這種問題。

3）zookeeper的工作原理是什么？

　　下面通過三種情形來講解：

　?。?）master啟動

　　在分布式系統(tǒng)中引入Zookeeper以后，就可以配置多個主節(jié)點，這里以配置兩個主節(jié)點為例，假定它們是 主節(jié)點A 和 主節(jié)點B，當(dāng)兩個主節(jié)點都啟動后，它們都會向ZooKeeper中注冊節(jié)點信息。我們假設(shè) 主節(jié)點A 鎖注冊的節(jié)點信息是 master00001 ， 主節(jié)點B 注冊的節(jié)點信息是 master00002 ，注冊完以后會進行選舉，選舉有多種算法，這里以編號最小作為選舉算法，那么編號最小的節(jié)點將在選舉中獲勝并獲得鎖成為主節(jié)點，也就是 主節(jié)點A 將會獲得鎖成為主節(jié)點，然后 主節(jié)點B 將被阻塞成為一個備用節(jié)點。這樣，通過這種方式Zookeeper就完成了對兩個Master進程的調(diào)度。完成了主、備節(jié)點的分配和協(xié)作。

　?。?）master故障

　　如果 ?主節(jié)點A 發(fā)生了故障，這時候它在ZooKeeper所注冊的節(jié)點信息會被自動刪除，而ZooKeeper會自動感知節(jié)點的變化，發(fā)現(xiàn) 主節(jié)點A ?故障后，會再次發(fā)出選舉，這時候 ?主節(jié)點B ?將在選舉中獲勝，替代 ?主節(jié)點A ?成為新的主節(jié)點，這樣就完成了主、被節(jié)點的重新選舉。

　?。?）master恢復(fù)

　　如果主節(jié)點恢復(fù)了，它會再次向ZooKeeper注冊自身的節(jié)點信息，只不過這時候它注冊的節(jié)點信息將會變成 master00003 ，而不是原來的信息。ZooKeeper會感知節(jié)點的變化再次發(fā)動選舉，這時候 主節(jié)點B 在選舉中會再次獲勝繼續(xù)擔(dān)任 ?主節(jié)點 ， 主節(jié)點A 會擔(dān)任備用節(jié)點。

　　zookeeper就是通過這樣的協(xié)調(diào)、調(diào)度機制如此反復(fù)的對集群進行管理和狀態(tài)同步的。

?4）zookeeper集群架構(gòu)

　　zookeeper一般是通過集群架構(gòu)來提供服務(wù)的，下圖是zookeeper的基本架構(gòu)圖。

　　zookeeper集群主要角色有server和client，其中server又分為leader、follower和observer三個三絕，每個角色的含義如下：

Leader：領(lǐng)導(dǎo)者角色，主要負責(zé)投票的發(fā)起和決議，以及更新系統(tǒng)狀態(tài)。
follower：跟隨著角色，用于接收客戶端的請求并返回結(jié)果給客戶端，在選舉過程中參與投票。
observer：觀察者角色，用戶接收客戶端的請求，并將寫請求轉(zhuǎn)發(fā)給leader，同時同步leader狀態(tài)，但是不參與投票。Observer目的是擴展系統(tǒng)，提高伸縮性。
client：客戶端角色，用于向zookeeper發(fā)起請求。

　　Zookeeper集群中每個Server在內(nèi)存中存儲了一份數(shù)據(jù)，在Zookeeper啟動時，將從實例中選舉一個Server作為leader，Leader負責(zé)處理數(shù)據(jù)更新等操作，當(dāng)且僅當(dāng)大多數(shù)Server在內(nèi)存中成功修改數(shù)據(jù)，才認為數(shù)據(jù)修改成功。

　　Zookeeper寫的流程為：客戶端Client首先和一個Server或者Observe通信，發(fā)起寫請求，然后Server將寫請求轉(zhuǎn)發(fā)給Leader，Leader再將寫請求轉(zhuǎn)發(fā)給其它Server，其它Server在接收到寫請求后寫入數(shù)據(jù)并響應(yīng)Leader，Leader在接收到大多數(shù)寫成功回應(yīng)后，認為數(shù)據(jù)寫成功，最后響應(yīng)Client，完成一次寫操作過程。

3、Kafka基礎(chǔ)與入門

1）kafka基本概念

　　Kafka是一種高吞吐量的分布式發(fā)布/訂閱消息系統(tǒng)，這是官方對kafka的定義，這樣說起來，可能不太好理解，這里簡單舉個例子：現(xiàn)在是個大數(shù)據(jù)時代，各種商業(yè)、社交、搜索、瀏覽都會產(chǎn)生大量的數(shù)據(jù)。那么如何快速收集這些數(shù)據(jù)，如何實時的分析這些數(shù)據(jù)，是一個必須要解決的問題，同時，這也形成了一個業(yè)務(wù)需求模型，即生產(chǎn)者生產(chǎn)（produce）各種數(shù)據(jù)，消費者（consume）消費（分析、處理）這些數(shù)據(jù)。那么面對這些需求，如何高效、穩(wěn)定的完成數(shù)據(jù)的生產(chǎn)和消費呢？這就需要在生產(chǎn)者與消費者之間，建立一個通信的橋梁，這個橋梁就是消息系統(tǒng)。從微觀層面來說，這種業(yè)務(wù)需求也可理解為不同的系統(tǒng)之間如何傳遞消息。

　　kafka是Apache組織下的一個開源系統(tǒng)，它的最大的特性就是可以實時的處理大量數(shù)據(jù)以滿足各種需求場景：比如基于hadoop平臺的數(shù)據(jù)分析、低時延的實時系統(tǒng)、storm/spark流式處理引擎等。kafka現(xiàn)在它已被多家大型公司作為多種類型的數(shù)據(jù)管道和消息系統(tǒng)使用。

2）kafka角色術(shù)語

　　kafka的一些核心概念和角色

Broker：Kafka集群包含一個或多個服務(wù)器，每個服務(wù)器被稱為broker。
Topic：每條發(fā)布到Kafka集群的消息都有一個分類，這個類別被稱為Topic（主題）。
Producer：指消息的生產(chǎn)者，負責(zé)發(fā)布消息到kafka?broker。
Consumer：指消息的消費者，從kafka?broker拉取數(shù)據(jù)，并消費這些已發(fā)布的消息。
Partition：Partition是物理上的概念，每個Topic包含一個或多個Partition，每個partition都是一個有序的隊列。partition中的每條消息都會被分配一個有序的id（offset）。
Consumer?Group：消費者組，可以給每個Consumer指定消費組，若不指定消費者組，則屬于默認的group。
Message：消息，通信的基本單位，每個producer可以向一個topic發(fā)布一些消息。

?3）kafka拓撲架構(gòu)

　　一個典型的Kafka集群包含若干Producer，若干broker、若干Consumer Group，以及一個Zookeeper集群。Kafka通過Zookeeper管理集群配置，選舉leader，以及在Consumer Group發(fā)生變化時進行rebalance。Producer使用push模式將消息發(fā)布到broker，Consumer使用pull模式從broker訂閱并消費消息。典型架構(gòu)如下圖所示：

?

　　從圖中可以看出，典型的消息系統(tǒng)有生產(chǎn)者（Producer），存儲系統(tǒng)（broker）和消費者（Consumer）組成，Kafka作為分布式的消息系統(tǒng)支持多個生產(chǎn)者和多個消費者，生產(chǎn)者可以將消息分布到集群中不同節(jié)點的不同Partition上，消費者也可以消費集群中多個節(jié)點上的多個Partition。在寫消息時允許多個生產(chǎn)者寫到同一個Partition中，但是讀消息時一個Partition只允許被一個消費組中的一個消費者所消費，而一個消費者可以消費多個Partition。也就是說同一個消費組下消費者對Partition是互斥的，而不同消費組之間是共享的

　　kafka支持消息持久化存儲，持久化數(shù)據(jù)保存在kafka的日志文件中，在生產(chǎn)者生產(chǎn)消息后，kafka不會直接把消息傳遞給消費者，而是先要在broker中進行存儲，為了減少磁盤寫入的次數(shù)，broker會將消息暫時緩存起來，當(dāng)消息的個數(shù)或尺寸、大小達到一定閥值時，再統(tǒng)一寫到磁盤上，這樣不但提高了kafka的執(zhí)行效率，也減少了磁盤IO調(diào)用次數(shù)。

　　kafka中每條消息寫到partition中，是順序?qū)懭氪疟P的，這個很重要，因為在機械盤中如果是隨機寫入的話，效率將是很低的，但是如果是順序?qū)懭?，那么效率卻是非常高，這種順序?qū)懭氪疟P機制是kafka高吞吐率的一個很重要的保證。

4）Topic和partition　　

　　Kafka中的topic是以partition的形式存放的，每一個topic都可以設(shè)置它的partition數(shù)量，Partition的數(shù)量決定了組成topic的log的數(shù)量。推薦partition的數(shù)量一定要大于同時運行的consumer的數(shù)量。另外，建議partition的數(shù)量要小于等于集群broker的數(shù)量，這樣消息數(shù)據(jù)就可以均勻的分布在各個broker中

　　那么，Topic為什么要設(shè)置多個Partition呢，這是因為kafka是基于文件存儲的，通過配置多個partition可以將消息內(nèi)容分散存儲到多個broker上,這樣可以避免文件尺寸達到單機磁盤的上限。同時，將一個topic切分成任意多個partitions，可以保證消息存儲、消息消費的效率，因為越多的partitions可以容納更多的consumer，可有效提升Kafka的吞吐率。因此，將Topic切分成多個partitions的好處是可以將大量的消息分成多批數(shù)據(jù)同時寫到不同節(jié)點上，將寫請求分擔(dān)負載到各個集群節(jié)點。

?　　在存儲結(jié)構(gòu)上，每個partition在物理上對應(yīng)一個文件夾，該文件夾下存儲這個partition的所有消息和索引文件。partiton命名規(guī)則為topic名稱+序號，第一個partiton序號從0開始，序號最大值為partitions數(shù)量減1。

　　在每個partition(文件夾)中有多個大小相等的segment(段)數(shù)據(jù)文件，每個segment的大小是相同的，但是每條消息的大小可能不相同，因此segment<br/>數(shù)據(jù)文件中消息數(shù)量不一定相等。segment數(shù)據(jù)文件有兩個部分組成，分別為index file和data file，此兩個文件是一一對應(yīng)，成對出現(xiàn)，后綴”.index“和“.log”分別表示為segment索引文件和數(shù)據(jù)文件。

5）Producer生產(chǎn)機制

　　Producer是消息和數(shù)據(jù)的生產(chǎn)者，它發(fā)送消息到broker時，會根據(jù)Paritition機制選擇將其存儲到哪一個Partition。如果Partition機制設(shè)置的合理，所有消息都可以均勻分布到不同的Partition里，這樣就實現(xiàn)了數(shù)據(jù)的負載均衡。如果一個Topic對應(yīng)一個文件，那這個文件所在的機器I/O將會成為這個Topic的性能瓶頸，而有了Partition后，不同的消息可以并行寫入不同broker的不同Partition里，極大的提高了吞吐率。

6）Consumer消費機制

　　Kafka發(fā)布消息通常有兩種模式：隊列模式（queuing）和發(fā)布/訂閱模式(publish-subscribe)。在隊列模式下，只有一個消費組，而這個消費組有多個消費者，一條消息只能被這個消費組中的一個消費者所消費；而在發(fā)布/訂閱模式下，可有多個消費組，每個消費組只有一個消費者，同一條消息可被多個消費組消費。　　

Kafka中的Producer和consumer采用的是push、pull的模式，即producer向?broker進行push消息，comsumer從bork進行pull消息，push和pull對于消息的生產(chǎn)和消費是異步進行的。pull模式的一個好處是consumer可自主控制消費消息的速率，同時consumer還可以自己控制消費消息的方式是批量的從broker拉取數(shù)據(jù)還是逐條消費數(shù)據(jù)。

?