Kafka源碼系列，kafka 0.8.2.2為例給大家講解。目標是大家讀完kafka源碼系列能徹底了解kafka，***能設(shè)計處自己的消息隊列或者存儲系統(tǒng)。

一，分布式系統(tǒng)的CAP理論

1，理論首先把分布式系統(tǒng)中的三個特性進行了如下歸納：

一致性（C）：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時刻是否同樣的值。（等同于所有節(jié)點訪問同一份***的數(shù)據(jù)副本）

可用性（A）：在集群中一部分節(jié)點故障后，集群整體是否還能響應(yīng)客戶端的讀寫請求。（對數(shù)據(jù)更新具備高可用性）

分區(qū)容錯性（P）：多副本進行容錯。以實際效果而言，分區(qū)相當于對通信的時限要求。系統(tǒng)如果不能在時限內(nèi)達成數(shù)據(jù)一致性，就意味著發(fā)生了分區(qū)的情況，必須就當前操作在C和A之間做出選擇。

[[218250]]

2，CAP理論實踐中的妥協(xié)

由于CAP理論在分布式存儲系統(tǒng)中，做多只能實現(xiàn)上面兩點。而現(xiàn)實環(huán)境是很復(fù)雜的，比如網(wǎng)絡(luò)抖動及故障，硬件故障等問題，分區(qū)容錯是我們必須要實現(xiàn)的。所以我們只能在一致性和可用性之間權(quán)衡。

A),CP系統(tǒng)-一致性優(yōu)先原則

要實現(xiàn)強一致性的原則有很多方式，最簡單的方式就是一個master節(jié)點和任意數(shù)目的包含冗余備份的附屬節(jié)點。數(shù)據(jù)永遠從master寫入和讀取。但是這個是存在單點故障的，由于master的故障會導致系統(tǒng)不可用，就此而言是放棄了可用性。但是一般情況下我們都有容錯機制，讓從屬節(jié)點變?yōu)閙aster，錯誤處理完成系統(tǒng)即可用了。

B),AP系統(tǒng)可用性優(yōu)先原則

選擇支持可用性和分區(qū)容錯性，并犧牲一致性的系統(tǒng)被稱為具有”最終一致性”。特點是，我們可以從任意的一個節(jié)點寫入，該節(jié)點負責將數(shù)據(jù)同步到其它節(jié)點。讀取的時候只需訪問數(shù)據(jù)存在的一個節(jié)點就夠了，但是可用會存在從某個節(jié)點讀取的數(shù)據(jù)不是***的，也即系統(tǒng)不具備一致性。

C),靈活的一致性程度

三個特性之間權(quán)衡并不是非黑即白，其實可以平緩過度，達到***系統(tǒng)性能要求。

比如，在AP系統(tǒng)中，假如數(shù)據(jù)有三個冗余副本，我們可以通過調(diào)節(jié)請求數(shù)據(jù)的節(jié)點數(shù)目來達到高的一致性，比如我們同時向三個副本請求數(shù)據(jù)，那么我們就滿足了強一致性，但是代價是喪失了容錯性。通常，我們可以要求特定數(shù)目的節(jié)點或者大多數(shù)節(jié)點可用并且能返回一致性結(jié)果，是在一致性和容錯性中進行權(quán)衡的一個不錯的方法。

同樣的在CP系統(tǒng)中，我們可以運行從附屬節(jié)點中讀取數(shù)據(jù)，犧牲一部分一致性來達到高的可用性。如果保持仍然只能想master寫數(shù)據(jù)，那么我們還是高的一致性的寫入操作，但是允許讀取操作最終一致性。

我們可以根據(jù)具體的用例，調(diào)整CAP各種特性的強度，使之最適合用例的需要。甚至可以對同一個應(yīng)用程序、同一個數(shù)據(jù)庫中的不同類型的數(shù)據(jù)混合使用這些策略。

二，設(shè)計自己的分布式存儲系統(tǒng)

設(shè)計一個分布式存儲系統(tǒng)，并不難，難在如何保證系統(tǒng)的健壯性或者叫魯棒性。至于原因，在這里浪尖只想說一句話那就是網(wǎng)絡(luò)是不可靠的。

目前典型的分布式存儲系統(tǒng)的結(jié)構(gòu)為:

元數(shù)據(jù)服務(wù)器，數(shù)據(jù)存儲節(jié)點，客戶端。

數(shù)據(jù)的存取過程:

客戶端會先獲取元數(shù)據(jù)信息，然后根據(jù)元數(shù)據(jù)信息去特定的節(jié)點讀寫數(shù)據(jù)。元數(shù)據(jù)維護了數(shù)據(jù)在所有節(jié)點的存儲情況，副本情況等等。數(shù)據(jù)存儲節(jié)點會完成副本數(shù)據(jù)同步的過程。

與此同時，我們會要求分布式數(shù)據(jù)存儲系統(tǒng)包含以下三個特性:

1，數(shù)據(jù)備份機制，順利的處理某個節(jié)點無法訪問的情況。

2，提供備份一致性的機制-----當用戶請求數(shù)據(jù)的時候能獲得最近更新的數(shù)據(jù)(一致性)。

3，線性擴展機制-----20個節(jié)點的吞吐量是10個節(jié)點的兩倍。

三，剖析kafka存儲系統(tǒng)

不要抬杠說kafka是消息隊列不是存儲系統(tǒng)。

1，Kafka的系統(tǒng)整個體系的角色:

1),zookeeper

記錄的有kafka的Broker，kafka 的Broker controller選舉，topic發(fā)布，配置更新，分區(qū)新增等都是客戶端通過zookeeper發(fā)布到Crontroller的。

2),producer

負責發(fā)送數(shù)據(jù)到kafka

3),consumer

負責從kafka取數(shù)據(jù)

4),broker

負責數(shù)據(jù)接收、存儲、管理等

5),topic 和 partition

Topic是代表一個種類的數(shù)據(jù)。Partition是對topic進行細分，保證吞吐量和處理并發(fā)度的關(guān)鍵，并且是集群數(shù)據(jù)備份的單元。

2，從常見的分布式存儲系統(tǒng)的角色來看：

客戶端：producer，consumer，zookeeper(topic，partition，Broker等相關(guān)的變更都是通過zookeeper通知到集群的controller的,要是覺得牽強可以將其歸屬到元數(shù)據(jù)集群)。

存儲系統(tǒng)：Broker集群

元數(shù)據(jù)集群:zookeeper集群。其實每個Broker都會存儲一份元數(shù)據(jù)(client-->zookeeper-->

Controller-->普通Broker)。

3，kafka的分布式存儲特性

1),數(shù)據(jù)備份，故障恢復(fù)

分兩個部分：

A),Broker故障恢復(fù).Broker注冊到zookeeper，臨時zknode,/brokers/ids/[0...N]，臨時節(jié)點保存的是advertisedHost:advertisedPort，并會初始化SessionExpireListener該listener會監(jiān)聽Broker自己的臨時節(jié)點(會話超時重新注冊)。Crontroller就可以監(jiān)聽這個目錄下的臨時節(jié)點，會得知Brokers是否已經(jīng)宕機，或者是否有新的Broker加入到節(jié)點.

Brokers集群通過向zookeeper注冊臨時節(jié)點/controller，來選舉Crontroller，并且每個Broker都會監(jiān)聽該臨時節(jié)點，通過臨時節(jié)點的變動來決定是否進行Crontroller的選舉。Crontroller宕機，觸發(fā)其它Broker進行Crontroller重新選舉。來進行容錯。

B),topic表示一類消息，topic劃分為若干partition，對每個partition進行數(shù)據(jù)的讀寫操作。Partition會有若干副本，副本會選舉一個leader，然后數(shù)據(jù)的寫入和讀取都是通過leader來實現(xiàn)，這就實現(xiàn)了強一致性CP。與此同時引入了一個單點故障的問題，故障恢復(fù)機制是從isr列表里重新選舉出leader。假如數(shù)據(jù)在flower從leader同步數(shù)據(jù)存在滯后的話，會導致數(shù)據(jù)丟失，那么此時，我們可以通過下面的配置，我們可以保證故障轉(zhuǎn)移之后會不會有數(shù)據(jù)丟失。

屬性的詳細介紹:

Request.required.acks：有三個取值分別的含義是：

0-不等待Broker應(yīng)答，立即返回。

1-等待leader數(shù)據(jù)提交成功的應(yīng)答。

-1-等待min.insync.replicas數(shù)目個副本都接收到數(shù)據(jù)才會視為寫入成功。

該參數(shù)要結(jié)合min.insync.replicas來使用，當request.required.acks設(shè)置為-1時，isr列表里min.insync.replicas數(shù)目個副本數(shù)據(jù)寫入完畢，才算消息生產(chǎn)成功。

min.insync.replicas數(shù)值不能超過副本數(shù)總數(shù)，假如相等的話，有一個副本不可用即會導致集群癱瘓。一般是replication.factor = min.insync.replicas +1即可。

2),數(shù)據(jù)備份一致性的機制

副本會選舉出leader，其余follower。數(shù)據(jù)的寫入和讀取都是經(jīng)過leader，以此來實現(xiàn)數(shù)據(jù)備份的一致性。所以，數(shù)據(jù)備份的一致性是CP，強一致性。Leader存在故障恢復(fù)機制:leader宕機，從isr列表里選舉出新的leader。

3),線性擴展機制

該機制對于kafka來說也是分兩個部分：

A),Broker的線性擴展

新的Broker加入集群，Crontroller會感知到變化。但是已有的分區(qū)或者數(shù)據(jù)不會重新分布到新的Broker上去，假如沒有新增topic或者不進行人工遷移等操作的話新的Broker不會有數(shù)據(jù)。增加集群假如是非異構(gòu)機器的話集群性能應(yīng)該是線性增加的。

B),給某個topic擴大分區(qū)數(shù)，也會增加topic的并發(fā)度，前提是磁盤數(shù)目要合適。該增加也是會增加topic吞吐量。

4，client與kafka集群之間通訊的機制

這篇文章之后講大致過程，后面會陸續(xù)出文章講細節(jié)部分。

A),Command---->zookeeper---->broker Controller---->Brokers

這個相當于基于zookeeper做了一個訂閱發(fā)布系統(tǒng)。Topic創(chuàng)建配置更新等都是通過這種方式傳達給所有Brokers Controller，然后由Broker Crontroller傳遞給所有的Brokers。

B),producer/SampleConsumer---->Brokers partitions leader----->follower

這個在<Kafka源碼系列之通過源碼分析Producer性能瓶頸>那講已經(jīng)說過，請求分兩步:

1),***步隨機選一個Broker，然后獲取topic相關(guān)的元數(shù)據(jù)，如leader的位置等。

2),構(gòu)建鏈接到所有l(wèi)eader所在Broker的連接池，進行數(shù)據(jù)的讀寫。

假如是生產(chǎn)消息的話follower會主動從leader上獲取滯后的消息。

C),high consumer--->zookeeper---->brokers leader----->brokers follower

這個獲取數(shù)據(jù)的方式比上個步驟多了個環(huán)節(jié)，就是從zookeeper上獲取Broker的ip和port，而上個方式是直接在配置里寫明了Broker的ip和port。

在上個基礎(chǔ)上又基于zookeeper做了一些優(yōu)化，增加了三個重要的zookeeper的listener:

1),ZKRebalancerListener

該listener監(jiān)聽的是/consumers/group/ids目錄，當該目錄下的有子節(jié)點增刪的時候會觸發(fā)，rebalance。假如嘗試4次數(shù)后不能成功就會拋出一下異常

throw new ConsumerRebalanceFailedException(consumerIdString + " can't rebalance after " + config.rebalanceMaxRetries +" retries") 

2),ZKSessionExpireListener

監(jiān)聽的是每個consumer自己臨時節(jié)點(/consumers/group/ids/consumerID)的刪除與注冊(無動作)，臨時節(jié)點刪除時handleNewSession在處理函數(shù)里需要重新想zookeeper注冊該節(jié)點。也會觸發(fā)rebalance。

3),ZKTopicPartitionChangeListener

該listener，監(jiān)控的是/brokers/topics/topicName節(jié)點的數(shù)據(jù)變動，也即是分區(qū)的變動，假如有新的分區(qū)增加也會觸發(fā)rebalance。

四，總結(jié)

本文主要是想幫助大家理解設(shè)計一套分布式存儲系統(tǒng)，首先介紹了CAP理論，接著講了分布式存儲系統(tǒng)的幾個要素，***以kafka為例，講解了kafka這個分布式消息隊列或者分布式存儲系統(tǒng)的結(jié)構(gòu)。希望能幫助到大家。***，提筆做個埋點，關(guān)于zookeeper的理論及使用我們后面會跟大家娓娓道來。