【筆記】Apache kafka實戰 【快速入門】

1、參考

---

Apache Kafka實戰

2、快速入門

---

2.1 安裝啓動

tar -xzvf kafka_2.11-2.1.0.tgz
cd kafka_2.11-2.1.0
./bin/zookeeper-server-start.sh config/zookeeper.properties
./bin/kafka-server-start.sh config/server.properties

2.2 建立topic

./bin/kafka-topics.sh --create --zookeeper localhost:2181 --topic test --partitions 1 --replication-factor 1
bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test

2.3 發送消息

指定topic後，發送、接收消息

3、消息引擎系統

---

設計一個消息引擎系統須要考慮兩個重要因素：
（1）消息設計
（2）傳輸協議設計

3.1 消息設計

爲了可以更好的表達語義，最大限度提升重用性，一般採用結構化的方式進行設計
例如：SOAP協議中消息採用XML格式，Web Service支持JSON格式消息
kafka消息用二進制方式保存的，但依然是結構化的消息

3.2 傳輸協議設計

狹義角度，指定了消息在不一樣系統之間傳輸的方式，主流的協議包含AMQP，Web Service + SOAP, MSMQ（微軟）等
廣義角度，可能包括任何可以在不一樣系統之間傳輸消息或者執行語義操做的協議或者框架，例如，RPC和序列化框架，
包含Protocol Buffers(簡寫Google PB, Google）、Dubbo(阿里）等
Kafka設計了一套二進制的消息傳輸協議，沒有采用Google PB等框架

3.3 消息引擎範型

傳輸協議做爲一個基礎構建快，服務於消息引擎系統實現的消息引擎範型
一個消息引擎範型是一個基於網絡的架構範型，描述了消息引擎系統的兩個不一樣子系統如何互連、交互
最多見的消息引擎範型是（1）消息隊列模型（2）發佈/訂閱模型

發佈訂閱模型，有主題（topic）概念，一個topic能夠表示消息的容器，發佈者將消息生產出來發送到指定的topic中，全部訂閱了該topic的訂閱者均可以接收到該topic下的全部消息，生活中的報紙訂閱能夠當作是發佈/訂閱模型的典型

kafka同時支持這兩種引擎模型

3.4 JAVA消息服務

JAVA消息服務（JMS），是一套API規範，提供了接口用於實現分佈式系統間的消息傳遞，同時支持3.3中的兩種消息引擎模型

4、概要設計

kafka設計之初衷是爲了解決互聯網公司的超大量數據的實時傳輸，考慮如下4個方面：
（1）吞吐量/延時
（2）消息持久化
（3）負載均衡和故障轉移
（4）伸縮性

4.1 吞吐量和延遲

批處理(batching),能夠顯著提高吞吐量
kafka寫入操做很是快，得益於它對磁盤的使用方法的不一樣，雖然kafka會持久化全部數據到磁盤，可是本質上，每次寫入操做都只是把數據寫入到操做系統的頁緩存（page cache)中，而後由操做系統自行決定什麼時候將頁緩存中的數據寫回到磁盤上，這樣有3個優勢：
（1）操做系統頁緩存是在內存中分配的，消息寫入速度很是快；
（2）Kafka沒必要直接和底層的文件系統打交道，全部瑣碎的IO操做交給操做系統來處理
（3）kafka寫入操做採用追加寫入(append)方式，避免了磁盤隨機寫操做

普通的物理磁盤（非固態硬盤），隨機讀寫的吞吐量很慢，可是磁盤的順序讀寫操做其實很是快，能夠匹敵內存的隨機IO速度

kafka在設計時候採用了追加寫入消息的方式，只能在日誌文件的末尾追加寫入新的消息，不容許修改已經寫入的消息，它屬於典型的磁盤順序訪問型操做，顯著提升kafka的吞吐量，實際使用過程當中，能夠輕鬆實現每秒幾萬或者幾十萬條消息

kafka在讀消息時候，首先嚐試從操做系統的頁緩存中讀取，若是命中將消息經頁緩存直接發送到網絡Socket上，這個過程使用Linux的sendfile系統調用，便是零拷貝（zero copy) 技術

4.2 消息持久化

消息持久化的好處是：
（1）解耦消息發送和消息消費，本質上，kafka核心功能是提供了生產者/消費者模式的完整解決方案，經過將消息持久化使得生產者再也不須要直接和消費者方耦合，只是簡單的把消息生產出來交由kafka服務器保存，提高了總體的吞吐量

（2）實現靈活的消息處理，消息持久化能夠方便實現消息重演（message replay,對於已經處理過的消息可能在將來的某個時間點從新處理一次）

普通的系統在實現持久化時候，可能會先儘可能使用內存，當內存資源耗盡時候，在一次性將數據刷盤，kafka則是，全部數據都會當即寫入文件系統的持久化日誌中，以後kafka服務器纔會返回結果給客戶端通知消息成功寫入
這樣，既實時保存了數據，又減小了kafka程序對於內存的消耗，將節省的內存留給頁緩存使用，提升總體性能

4.3 負載均衡和故障轉移

kafka實現負載均衡經過智能化分區領導者選舉實現（partition leader election)
kafka服務器支持故障轉移的方式是使用了會話機制
每一個kafka服務器啓動以後，將以會話的形式把本身註冊到Zookeeper服務器上，一旦該服務器出現故障，與Zookeeper之間的會話由於超時失效，kafka集羣將選舉出另一個服務器徹底代替故障服務器

4.4 伸縮性

伸縮性（scalability),表示向分佈式系統中添加額外的計算資源時吞吐量提高的能力

每一個kafka服務器上的狀態統一交由Zookeeper保管，擴展kafka集羣只須要，啓動新的kafka服務器
kafka服務器並非全部的狀態都不保存，只是保存了很輕量級的內部狀態，所以整個集羣間的維護狀態一致性代價很低

5、基本概念和術語

5.1 消息

消息由消息頭部、key、value組成，消息頭部包含消息的CRC碼，消息版本號，屬性，時間戳，鍵長度，消息體長度等信息，

key，消息鍵，對消息作partition時候使用，即決定消息被保存在某個topic下的哪一個partition
value，消息體，保存實際的消息數據
timestamp，消息發送的時間戳，用於流式處理以及其餘依賴事件的處理語義，若是不指定取當前時間

消息的屬性字段，分配了1個字節，目前使用了最低3位保存消息的壓縮類型，其餘5位沒有使用，目前支持的壓縮類型
0（無壓縮），1（GZIP），2（Snappy），3（LZ4）

kafka在消息設計時候，特地避開了繁重的JAVA堆上內存分配，直接使用緊湊二進制字節數組ByteBuffer而不是獨立的對象，至少可以訪問多一倍的可用內存，kafka官網，一臺32GB內存的機器，kafka幾乎能夠用到28~30GB的物理內存

大量使用頁緩存而非堆內存還有一個好處，當出現kafka broker進程崩潰時候，堆內存上的數據一併消失，可是頁緩存的數據依然存在，下次kafka broker重啓後能夠繼續提供服務，不須要單獨熱緩存

5.2 主題和分區

從概念上，topic只是一個邏輯概念，表明了一類消息，能夠認爲是消息被髮送到的地方，使用topic來區分實際業務
topic一般被多個消費者訂閱，出於性能考慮，kafka不是topic message兩層結構，而是使用topic partition message 三層結構分散負載，

topic由多個partition組成，partition是不可修改的有序消息序列，每一個partition有專屬的partition號，一般由0開始，用戶對partition惟一能作的操做是在消息序列的尾部追加寫入消息，partition上的每一條消息被分配一個惟一的序列號，該序列號稱爲位移（offset），從0開始順序遞增的整數，位移信息能夠惟必定位到某個partition下的一條消息

5.3 offset

topic partition下的每一個消息都被分配了一個位移值，
kafka消費者端也有位移的概念，每條消息的某個partition的位移是固定的，但消費該partition的消費者的位移會隨着消費進度不斷前移（不超過partition中的最新一個消息的位移）
kafka中的一條消息其實就是一個<topic, partition, offset>三元組（tuple）

5.4 leader和follower

kafka的副本（replica)分紅兩個角色：領導者和追隨者
這種角色設定幾乎徹底取代了過去的主備提法（master-slave)，與傳統的主備系統（MySQL）不一樣的是，
在這類系統中，一般只有leader對外提供服務，follower存在的惟一價值是充當leader的候補，一旦leader掛掉當即有一個follower被選舉成新的leader

5.5 ISR