kafka設計要點簡介

  最近在學習kafka，參考官網上的文檔，概括kafka的主要設計點，希望能幫助大家對kafka的設計有一個大概的了解，沒說清楚的地方，或者不對的地方希望大家指出，相互幫助學習，

4.        kafka設計簡介

1     

2     

3     

4     

4.1    動機

• 高吞吐量以支持大數據量的事件流，例如實時日志集結

• 能很好處理大數據積壓以支持線下階段性數據加載

• 低延遲的消息傳送，以支持傳統的消息系統應用

• 支持分區，分布式，實時處理

• 高可用，故障容錯

因此，kafka被設計成一個有獨特的元素，類似于數據庫日志的傳統的消息系統

4.2    持久化

• Kafka直接依賴系統的文件系統存儲和緩存，（java NIO）

• 常量時長足夠了

消息系統大多數使用Btree作為持久化數據結構，存儲系統一般混合了高速緩存和真正的磁盤讀取，所以讀取性能是不錯的。但是隨著數據量的成倍的增長，性能也會成倍的下降

所以kafaka 使用的是持久化隊列，這樣設計明顯的優勢是與數據量大小無關，并且讀不會阻塞寫，服務器可以利用便宜的硬盤獲得可觀的性能

4.3    效率

支持批量存取，批量會有的影響，大的網絡數據包，大的連續的磁盤操作，連續內存塊請求等等，所有這些都可以使kafka將突發性的大的數據流量轉變為線性寫

支持數據壓縮，并使用直接內存（javaNio）避免不必要的程序級別的復制，支持批量數據壓縮（這樣比單獨壓縮一個消息更有效），只有在消費信息的時候才會解壓

4.4    Producer(生產者)

負載均衡

生產直接可以將消息發送到broker而不需要任何中間路由，因為kafka每個節點都提供關于其主題每個分區的leader在那個節點的相關元數據查詢

異步發送

批量操作是效率提升的一個重要驅動，producer可以在指定的邊界緩存操作以批量操作

4.5    Consumer(消費者)

• Push vs poll

Kafka遵從大多數消息系統的設計，由producer將數據push到broker,由consumer 從

Broker pull數據。而Scribe and Apache Flume 遵從了一個不同的設計（push based），但這樣有個坑，假如consumer的處理效率沒有broker轉發效率高，就有可能壓垮消費者

4.6    消息傳播

4.7    復制

• 法定人數和狀態機

大部分日志復制都采用state-machinestyle,即只要領導者可以用，領導者選擇那些命令用來復制，跟隨者只要有序的復制這些值就可以了

大部分系統使用多數人投票策略（This majority vote approach）來決定leader和消息提交確認，這樣的好處就可以選擇其中最快的機器作為新的leader.但是這種策略的壞處是，系統不能容忍多的故障。比如你要能容忍f個錯，你就必須有2f+1的復制才足夠，這樣對于大規模數據來說是不可行的，因為這樣你損失了太多吞吐量了，比如（paxos算法）

而kafak利用zookeeper動態地維護了一套in-syncreplica(ISR)，只有ISR集里面的才可以被選為leader，所以容忍f個故障，只要有f+1個復制就可以了。雖然要容忍f個故障，

Majority vote 和 ISR都需要等同樣多的復制完成。

kafka另一個特性是允許有不完整數據的節點恢復

• 耐用和高可用保證

Producer配置request.required.acks=-1，0,1

0

1表示只要in-sync里的replica都接受了，就認為提交成功

-1 表示要in-sync里的復制都完成寫了，才認為提交成功

• 復制管理

以上復制講的是一個主題的一個分區，而kafka管理者上千個這樣的分區。所以kafka平衡分區以避免集中一個大的topic的所有分區在幾個節點（broker）上，因此kafka將領導職權平衡到所有節點上，每個節點都是它所保存的分區的一部分的leader

當一個節點失敗，只會對受影響的分區進行選舉，我們選擇一個broker作為controller,controller負責偵測broker級別的錯誤，并負責受影響分區重新選擇leader