Kafka消息隊列學習進階(三)--原理概念介紹篇

Kafka原理

這篇主要是爲了Kafka調優而進行講解的，我所認爲的只有瞭解了部分原理，才知道怎麼去調優。我將從下面幾個點進行講解：

1. CAP理論。

2. Replica概念及Data Replication要解決的問題。

3. Kafka如何使用Zookeeper及Kafka Leader Election。

4. Kafka Consumer及 Producer。

CAP理論將再也不詳細介紹，以前的Zookeeper已經介紹了；後面的三點將詳細的介紹。

1、CAP理論

CAP理論，包含三個點，一致性；可用性；分區容忍性，下面分別這三個點的介紹：

Consistency(一致性)

     經過某個節點的寫操做結果對後面經過其它節點的讀操做可見。

     若是更新數據後，併發訪問狀況下可當即感知該更新，稱爲強一致性。

     若是容許以後部分或者所有感知不到該更新，稱爲弱一致性。

     若在以後的一段時間（一般該時間不固定）後，必定能夠感知該更新，稱爲最終一致性。

Availability(可用性)

     任何一個沒有發生故障的節點必須在有限的時間內返回合理的結果。

Partition tolerance(分區容忍性)

     部分節點宕機或者沒法與其它節點通訊時，各分區間還可保持分佈式系統的功能。

對於上面的三個又能夠分別進行組合，CA/CP/AP。其中考慮到分佈式系統的相關知識點，咱們將會放棄CA，只考慮CP和AP兩種狀況。

2、Replica

Kafka的replica指的是消息的備份，爲了保證Kafka的高可用（當leader節點掛了以後，Kafka依然能提供服務）kafka提供了備份的功能。這個備份是針對partition的。能夠經過 default.replication.factor 對replica的數目進行配置，默認值爲1，表示不對topic進行備份。若是配置爲2，表示除了leader節點，對於topic裏的每個partition，都會有一個額外的備份。特色以下：

 1.當某個Topic的replication-factor爲N且N大於1時，每一個Partition都會有N個副本（Replica）.

 2.Replica的個數小於等於Broker數，即對每一個Partition而言每一個Broker上只會有一個Replica，所以可用Broker ID表示Replica.

 3.全部Partition的全部Replica默認狀況會均勻分佈到全部Broker上.

replica分配算法所解決的問題：kafka經過replica分配的算法保證了當某臺機器掛掉，甚至某個機房掛掉，依然有備份可用。

3、Data Replication要解決的問題

所須要解決問題，以下四點：

1. 如何Propagate消息。

2. 什麼時候Commit。

3. 如何處理Replica恢復。

4. 如何處理Replica所有宕機。

我將詳細的介紹第三點，另外三點將提供一個地址提供讀者進行詳細研究和了解，地址以下：http://www.infoq.com/cn/articles/kafka-analysis-part-2/。

第三點，什麼時候提交，分爲ISR和Commit策略：

1.ISR

  a.Leader會維護一個與其基本保持同步的Replica列表，該列表稱爲ISR（in-sync Replica）。

  b.若是一個Follower比Leader落後太多，或者超過必定時間未發起數據複製請求，則Leader將其從ISR中移除。

  c.當ISR中全部Replica都向Leader發送ACK時，Leader即Commit。

2.Commit策略

  a.Server配置

replica.lag.time.max.ms=10000

replica.lag.max.messages=4000

  b.Topic配置

min.insync.replicas=1

  c.Producer配置

request.required.acks=0

Kafka如何使用Zookeeper

Kafka如何使用Zookeeper，主要有下面三點：

1. 配置管理。

2. Leader Election。

3. 服務發現。

代碼實現咱們將再也不進行講解，由於我也沒有研究這塊的源碼，講這個主要是爲了優化。從優化的角度來講，咱們能夠本身手動搭建ZK集羣，同時提升Kafka鏈接ZK的時長等方面入手。

4、Kafka Consumer及 Producer

首先咱們將分別介紹生成者和消費者的概念，而後再介紹一個重點概念消費分組(Consumer Group)。

Producer：Producer經過主動Push的方式將消息發佈到Broker。

Consumer：Consumer經過Pull從Broker消費數據：

 1.Push

     優點：延時低。

     劣勢：可能形成Consumer來不及處理消息；網絡擁塞。

 2.Pull

     優點：Consumer按實際處理能力獲取相應量的數據；Broker實現簡單。

     劣勢：若是處理很差，實時性相對不足（Kafka使用long polling）。

消費分組(Consumer Group)，特色以下：

1. High Level Consumer將從某個Partition讀取的最後一條消息的offset存於Zookeeper中（從0.8.2開始同時支持將offset存於Zookeeper中和專用的Kafka Topic中）。

2. 這個offset基於客戶程序提供給Kafka的名字來保存，這個名字被稱爲Consumer Group。

3. Consumer Group是整個Kafka集羣全局惟一的，而非針對某個Topic的。

4. 每一個High Level Consumer實例都屬於一個ConsumerGroup，若不指定則屬於默認的Group。

須要注意的地方：

1. 消息被消費後，並不會被刪除，只是相應的offset加一。

2. 對於每條消息，在同一個Consumer Group裏只會被一個Consumer消費。

3. 不一樣Consumer Group可消費同一條消息，解釋了爲啥咱們會在代碼中加個主題。

 歡迎關注公衆號，掃碼可關注，或者搜索：繁榮Aaron。第一篇講的是環境搭建（傳統和docker兩種方式），第二篇講的是與SpringBoot結合。後續將會提出怎麼優化kafka？結合我所在公司實際運行的項目。