Apache Kafka 入門
1.kafka簡介和產生的背景
什么是 Kafka
Kafka 是一款分布式消息發布和訂閱系統，具有高性能、高吞吐量、系統快速, 可擴展并且可持久化. 它的分區特性, 可復制和可容錯都是其不錯的特性而被廣泛應用與大數據傳輸場景。它是由 LinkedIn 公司開發，使用 Scala 語言編寫，之后成為 Apache 基金會的一個頂級項目。 kafka 提供了類似 JMS 的特性，但是在設計和實現上是完全不同的，而且他也不是 JMS 規范的實現。
kafka 產生的背景
kafka 作為一個消息系統，早起設計的目的是用作 LinkedIn 的活動流（ActivityStream）和運營數據處理管道（Pipeline）。活動流數據是所有的網站對用戶的使用情況做分析的時候要用到的最常規的部分,活動數據包括頁面的訪問量（PV）、被查看內容方面的信息以及搜索內容。這種數據通常的處理方式是先
把各種活動以日志的形式寫入某種文件，然后周期性的對這些文件進行統計分析。運營數據指的是服務器的性能數據（CPU、 IO 使用率、請求時間、服務日志等） 。
Kafka 的應用場景
由于 kafka 具有更好的吞吐量、內置分區、冗余及容錯性的優點(kafka 每秒可以處理幾十萬消息)，讓 kafka 成為了一個很好的大規模消息處理應用的解決方案。所以在企業級應用長，主要會應用于如下幾個方面
行為跟蹤： kafka 可以用于跟蹤用戶瀏覽頁面、搜索及其他行為。通過發布-訂閱模式實時記錄到對應的 topic 中，通過后端大數據平臺接入處理分析，并做更進一步的實時處理和監控
日志收集：日志收集方面，有很多比較優秀的產品，比如 Apache Flume，很多公司使用kafka 代理日志聚合。日志聚合表示從服務器上收集日志文件，然后放到一個集中的平臺（文件服務器）進行處理。在實際應用開發中，我們應用程序的 log 都會輸出到本地的磁盤上，排查問題的話通過 linux 命令來搞定，如果應用程序組成了負載均衡集群，并且集群的機器有幾十臺以上，那么想通過日志快速定位到問題，就是很麻煩的事情了。所以一般都會做一個日志統一收集平臺管理 log 日志用來快速查詢重要應用的問題。所以很多公司的套路都是把應用日志幾種到 kafka 上，然后分別導入到 es 和 hdfs 上，用來做實時檢索分析和離線統計數據備份等。而另一方面， kafka 本身又提供了很好的 api 來集成日志并且做日志收集
2.kafka的本身架構
一個典型的 kafka 集群包含若干 Producer（可以是應用節點產生的消息，也可以是通過Flume 收集日志產生的事件），若干個 Broker（kafka 支持水平擴展）、若干個 ConsumerGroup，以及一個 zookeeper 集群。 kafka 通過 zookeeper 管理集群配置及服務協同。Producer 使用 push 模式將消息發布到 broker， consumer 通過監聽使用 pull 模式從broker 訂閱并消費消息。多個 broker 協同工作， producer 和 consumer 部署在各個業務邏輯中。三者通過zookeeper 管理協調請求和轉發。這樣就組成了一個高性能的分布式消息發布和訂閱系統。圖上有一個細節是和其他 mq 中間件不同的點， producer 發送消息到 broker
的過程是 push，而 consumer 從 broker 消費消息的過程是 pull，主動去拉數
據。而不是 broker 把數據主動發送給 consumer
2.1kafka術語介紹
（1）Topics（主題）
屬于特定類別的消息流稱為主題。 數據存儲在主題中。Topic相當于Queue。
主題被拆分成分區。 每個這樣的分區包含不可變有序序列的消息。 分區被實現為具有相等大小的一組分段文件。
（2）Partition（分區）
- 一個Topic可以分成多個Partition，這是為了平行化處理。
- 每個Partition內部消息有序，其中每個消息都有一個offset序號。
- 一個Partition只對應一個Broker，一個Broker可以管理多個Partition。
（3）Partition offset（分區偏移）
每個分區消息具有稱為 offset 的唯一序列標識。
（4）Replicas of partition（分區備份）
副本只是一個分區的備份。 副本從不讀取或寫入數據。 它們用于防止數據丟失。
（5）Brokers（經紀人）
- 代理是負責維護發布數據的簡單系統。 每個代理可以每個主題具有零個或多個分區。 假設，如果在一個主題和N個代理中有N個分區，每個代理將有一個分區。
- 假設在一個主題中有N個分區并且多于N個代理(n + m)，則第一個N代理將具有一個分區，并且下一個M代理將不具有用于該特定主題的任何分區。
- 假設在一個主題中有N個分區并且小于N個代理(n-m)，每個代理將在它們之間具有一個或多個分區共享。 由于代理之間的負載分布不相等，不推薦使用此方案。
（6）Kafka Cluster（Kafka集群）
Kafka有多個代理被稱為Kafka集群。 可以擴展Kafka集群，無需停機。 這些集群用于管理消息數據的持久性和復制。
（7）Producers（生產者）
生產者是發送給一個或多個Kafka主題的消息的發布者。 生產者向Kafka經紀人發送數據。 每當生產者將消息發布給代理時，代理只需將消息附加到最后一個段文件。實際上，該消息將被附加到分區。 生產者還可以向他們選擇的分區發送消息。
（8）Consumers（消費者）
Consumers從經紀人處讀取數據。 消費者訂閱一個或多個主題，并通過從代理中提取數據來使用已發布的消息。
- Consumer自己維護消費到哪個offet
- 每個Consumer都有對應的group
- group內是queue消費模型：各個Consumer消費不同的partition，因此一個消息在group內只消費一次
- group間是publish-subscribe消費模型：各個group各自獨立消費，互不影響，因此一個消息被每個group消費一次。
2.2 kafka架構圖
3.kafka安裝部署和基本操作
3.1 搭建
3.1.1 hosts 映射(可選, 建議)
echo "192.168.1.10 kfk1" >> /etc/hosts
echo "192.168.1.11 kfk2" >> /etc/hosts
echo "192.168.1.12 kfk3" >> /etc/hosts
3.1.2 搭建 Zookeeper (單機 or 集群)
- 需要先啟動 zookeeper，如果沒有搭建 zookeeper 環境，可以直接運行
kafka 內嵌的 zookeeper
啟動命令： bin/zookeeper-server-start.sh config/zookeeper.properties &
Broker, Producer, Consumer 的運行都需要 ZooKeeper
自己搭建見 [3.2.2.1 單機模式](#3.2.2.1 單機模式) or 見 [3.2.2.3 集群模式
3.1.3 Broker 的配置
tar xzf kafka_2.11-0.9.0.1.tgz -C /usr/local/
cd /usr/local/kafka_2.11-0.9.0.1
config 文件夾下是各個組件的配置文件, server.properties 是 Broker 的配置文件, 需要修改的有
######################### Server Basics #########################
broker.id=0 # 本 Broker 的 id, 只要非負數且各 Broker 的 id 不同即可, 一般依次加 1
##################### Socket Server Settings #####################
listeners=PLAINTEXT://:9092 # Broker 監聽的端口, Producer, Consumer 會連接這個端口
port=9092 # 同上
host.name=kfk1 # 本 Broker 的 hostname
########################## Topic Basics ##########################
delete.topic.enable=true # 配置為可以使用 delete topic 命令
########################### Log Basics ###########################
log.dirs=/var/lib/kafka-logs # log 目錄, 此目錄要存在且有足夠權限
###################### Log Retention Policy ######################
log.roll.hours=2 # 開始一個新的 log 文件片段的最大時間
log.retention.hours=24 # 控制一個 log 文件保留多長個小時
log.retention.bytes=1073741824 # 所有 log 文件的最大大小
log.segment.bytes=104857600 # 單一的 log 文件最大大小
log.cleanup.policy=delete # log 清除策略
log.retention.check.interval.ms=60000
############################ Zookeeper ############################
zookeeper.connect=zoo1:2181,zoo2:2181,zoo3:2181 # Zookeeper 的連接信息
注意: broker.id 和 host.name 在每臺機器上是不一樣的, 要按實際填寫
即在 kfk2, kfk3 上
broker.id=1
host.name=kfk2
broker.id=2
host.name=kfk3
PS: 在 kafka 安裝目錄下的 ./site-docs 目錄下有 kafka_config.html, producer_config.html, consumer_config.html 三個文件, 分別講解 broker, producer, consumer 配置參數含義. 附錄 A 是其翻譯.
3.1.4 開放端口
把 Kafka 用到的端口開放出來
firewall-cmd --zone=public --add-port=9100/tcp --permanent # 永久開啟 9100 端口(kafka manager)
firewall-cmd --zone=public --add-port=9092/tcp --permanent # 永久開啟 9092 端口(brokers)
firewall-cmd --zone=public --add-port=9999/tcp --permanent # 永久開啟 9999 端口(JMX)
firewall-cmd --reload # 重新加載防火墻規則
3.1.5 Broker 運行與終止
Broker 運行與終止命令如下.
# 運行: 如下有兩種方式
# 以守護進程的方式啟動(推薦)
bin/kafka-server-start.sh -daemon config/server.properties
# 將 Broker 放到后臺執行, 且不受終端關閉的影響, 標準輸出和錯誤輸出定向到 `./logs/kafka-server-boot.log`, 有問題時可以去看這個文件
nohup bin/kafka-server-start.sh config/server.properties > logs/kafka-server-boot.log 2>&1 &
# 終止
bin/kafka-server-stop.sh config/server.properties
3.1.6 測試
我們使用 Kafka 自帶的基于 終端 的 Producer 和 Consumer 腳本做測試.
先只啟動一臺機器上的 Broker. 在 kfk1 上運行
nohup bin/kafka-server-start.sh config/server.properties > logs/kafka-server-boot.log 2>&1 &
1. 創建 Topic
創建一個 名為"TestCase"的 單分區 單副本 的 Topic.
bin/kafka-topics.sh --create --zookeeper localhost:2181 --topic TestCase --replication-factor 1 --partitions 1
查看有哪些 Topic:
$ bin/kafka-topics.sh --list --zookeeper localhost:2181
TestCase
運行describe topics命令, 可以知道 Topic 的具體分配:
$ bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic test
Topic:test PartitionCount:1 ReplicationFactor:1 Configs:
Topic: test Partition: 0 Leader: 0 Replicas: 0 Isr: 0
解釋一下輸出的內容. 第一行給出了所有 partition 的一個摘要, 每行給出一個 partition 的信息. 因為我們這個 topic 只有一個 partition 所以只有一行信息.
- "leader" 負責所有 partition 的讀和寫請求的響應. "leader" 是隨機選定的.
- "replicas" 是備份節點列表, 包含所有復制了此 partition log 的節點, 不管這個節點是否為 leader 也不管這個節點當前是否存活, 只是顯示.
- "isr" 是當前處于同步狀態的備份節點列表. 即 "replicas" 列表中處于存活狀態并且與 leader 一致的節點.
可以發現這個 Topic 沒有副本而且它在 [我們創建它時集群僅有的一個節點] Broker 0 上.
另外, 除去手工創建 Topic 以外, 你也可以將你的 Brokers 配置成當消息發布到一個不存在的 Topic 時自動創建此 Topic.
2. 啟動 生產者
Kafka 附帶一個 終端生產者 可以從文件或者標準輸入中讀取輸入然后發送這個消息到 Kafka 集群. 默認情況下每行信息被當做一個消息發送.
運行生產者腳本然后在終端中輸入一些消息, 即可發送到 Broker.
$ bin/kafka-console-producer.sh --broker-list localhost:9092 --topic TestCase
This is a message
This is another message
PS: 通過鍵入 Ctrl-C 來終止終端生產者.
3. 啟動 消費者
Kafka 也附帶了一個 終端生產者 可以導出這些消息到標準輸出.
$ bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic TestCase --from-beginning
This is a message
This is another message
--from-beginning 參數使得可以接收到 topic 的所有消息, 包括 consumer 啟動前的. 去掉后則為僅接收 consumer 啟動后 kafka 收到的消息.
如果你在不同的終端運行生產者和消費者這兩個命令, 那么現在你就應該能再生產者的終端中鍵入消息同時在消費者的終端中看到.
所有的命令行工具都有很多可選的參數; 不添加參數直接執行這些命令將會顯示它們的使用方法, 更多內容可以參考他們的手冊.
PS: 通過鍵入 Ctrl-C 來終止終端消費者.
4. 配置一個多節點集群
我們已經成功的以單 Broker 的模式運行起來了, 但這并沒有意思. 對于 Kafka 來說, 一個單獨的 Broker 就是一個大小為 1 的集群, 所以集群模式就是多啟動幾個 Broker 實例.
我們將我們的集群擴展到3個節點. 在另外兩臺機器 kfk2, kfk3 上運行
nohup bin/kafka-server-start.sh config/server.properties > logs/kafka-server-boot.log 2>&1 &
現在我們可以創建一個新的 Topic 并制定副本數量為 3:
bin/kafka-topics.sh --create --zookeeper localhost:2181 --topic my-replicated-topic --replication-factor 3 --partitions 1
運行describe topics命令, 可以知道每個 Broker 具體的工作:
$ bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic
Topic:my-replicated-topic PartitionCount:1 ReplicationFactor:3 Configs:
Topic: my-replicated-topic Partition: 0 Leader: 1 Replicas: 1,2,0 Isr: 1,2,0
注意本例中 Broker 1 是這個有一個 partition 的 topic 的 leader.
現在我們發布幾個消息到我們的新 topic 上:
$ bin/kafka-console-producer.sh --broker-list localhost:9092 --topic my-replicated-topic
my test message 1
my test message 2
現在讓我們消費這幾個消息:
$ bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic my-replicated-topic --from-beginning
my test message 1
my test message 2
現在讓我們測試一下集群容錯. Broker 1 正在作為 leader, 所以我們殺掉它:
$ ps | grep server.properties
...
7564 ttys002 0:15.91 /System/Library/Frameworks/JavaVM.framework/Versions/1.8/Home/bin/java...
...
$ kill -9 7564
或在 kfk1 機器上運行
bin/kafka-server-stop.sh config/server.properties
此時, 集群領導已經切換到一個從服務器上, Broker 1 節點也不在出現在同步副本列表中了:
$ bin/kafka-topics.sh --describe --zookeeper localhost:2181 --topic my-replicated-topic
Topic:my-replicated-topic PartitionCount:1 ReplicationFactor:3 Configs:
Topic: my-replicated-topic Partition: 0 Leader: 2 Replicas: 1,2,0 Isr: 2,0
而且現在消息的消費仍然能正常進行, 即使原來負責寫的節點已經失效了.
$ bin/kafka-console-consumer.sh --zookeeper localhost:2181 --from-beginning --topic my-replicated-topic
...
my test message 1
my test message 2
5. 使用 Kafka Connect 進行數據導入導出
從終端寫入數據, 數據也寫回終端是默認的. 但是你可能希望從一些其它的數據源或者導出 Kafka 的數據到其它的系統. 相比其它系統需要自己編寫集成代碼, 你可以直接使用Kafka的 Connect 直接導入或者導出數據. Kafka Connect 是 Kafka 自帶的用于數據導入和導出的工具. 它是一個擴展的可運行連接器(runsconnectors)工具, 可實現自定義的邏輯來實現與外部系統的集成交互. 在這個快速入門中我們將介紹如何通過一個簡單的從文本導入數據, 導出數據到文本的連接器來調用 Kafka Connect. 首先我們從創建一些測試的基礎數據開始:
echo -e "foo\nbar" > test.txt
接下來我們采用standalone模式啟動兩個 connectors, 也就是讓它們都運行在獨立的, 本地的, 不同的進程中. 我們提供三個參數化的配置文件, 第一個提供共有的配置用于 Kafka Connect 處理, 包含共有的配置比如連接哪個 Kafka broker 和數據的序列化格式. 剩下的配置文件制定每個 connector 創建的特定信息. 這些文件包括唯一的 connector 的名字, connector 要實例化的類和其它的一些 connector 必備的配置.
bin/connect-standalone.sh config/connect-standalone.properties config/connect-file-source.properties config/connect-file-sink.properties
上述簡單的配置文件已經被包含在 Kafka 的發行包中, 它們將使用默認的之前我們啟動的本地集群配置創建兩個 connector: 第一個作為源 connector 從一個文件中讀取每行數據然后將他們發送 Kafka 的 topic, 第二個是一個輸出(sink)connector 從 Kafka 的 topic 讀取消息, 然后將它們輸出成輸出文件的一行行的數據. 在啟動的過程你講看到一些日志消息, 包括一些提示 connector 正在被實例化的信息. 一旦 Kafka Connect 進程啟動以后, 源 connector 應該開始從 test.txt 中讀取數據行, 并將他們發送到 topic connect-test 上, 然后輸出 connector 將會開始從 topic 讀取消息然后把它們寫入到 test.sink.txt 中.
我們可以查看輸出文件來驗證通過整個管線投遞的數據:
$ cat test.sink.txt
foo
bar
注意這些數據已經被保存到了 Kafka 的 connect-test topic 中, 所以我們還可以運行一個終端消費者來看到這些數據(或者使用自定義的消費者代碼來處理數據):
$ bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic connect-test --from-beginning
{"schema":{"type":"string","optional":false},"payload":"foo"}
{"schema":{"type":"string","optional":false},"payload":"bar"}
...
connector 在持續的處理著數據, 所以我們可以向文件中添加數據然后觀察到它在這個管線中的傳遞:
echo "Another line" >> test.txt
你應該可以觀察到新的數據行出現在終端消費者中和輸出文件中.
3.2 Zookeeper
3.2.1 簡介
Apache Zookeeper 是 Hadoop 的一個子項目, 是一個致力于開發和管理開源服務器, 并且能實現高可靠性的分布式協調框架. 它包含一個簡單的原語集, 分布式應用程序可以基于它實現同步服務, 配置維護和命名服務等.
Zookeeper 保證 2n + 1 臺機器的集群最大允許 n 臺機器掛掉而事務不中斷.
3.2.2 搭建
3.2.2.1 單機模式
此模式主要用于開發人員本地環境下測試代碼
1. 解壓 Zookeeper 并進入其根目錄
tar xzf zookeeper-3.4.9.tar.gz -C /usr/local/
cd /usr/local/zookeeper-3.4.9
2. 創建配置文件 conf/zoo.cfg
cp conf/zoo_sample.cfg conf/zoo.cfg
3. 修改內容如下:
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/var/lib/zookeeper/data
dataLogDir=/var/lib/zookeeper/logs
clientPort=2181
- tickTime: 是 zookeeper 的最小時間單元的長度(以毫秒為單位), 它被用來設置心跳檢測和會話最小超時時間(tickTime 的兩倍)
- initLimit: 初始化連接時能容忍的最長 tickTime 個數
- syncLimit: follower 用于同步的最長 tickTime 個數
- dataDir: 服務器存儲 數據快照 的目錄
- dataLogDir: 服務器存儲 事務日志 的目錄
- clientPort: 用于 client 連接的 server 的端口
其中需要注意的是dataDir和dataLogDir, 分別是 zookeeper 運行時的數據目錄和日志目錄, 要保證 這兩個目錄已創建 且 運行 zookeeper 的用戶擁有這兩個目錄的所有權
4.測試
- 啟動/關閉 Zookeeper:
bin/zkServer.sh start
bin/zkServer.sh stop
- 查看 Zookeeper 狀態:
bin/zkServer.sh status
顯示 mode: standalone, 單機模式.
- 使用 java 客戶端連接 ZooKeeper
./bin/zkCli.sh -server 127.0.0.1:2181
然后就可以使用各種命令了, 跟文件操作命令很類似, 輸入 help 可以看到所有命令.
3.2.2.2 集群模式
此模式是 生產環境中實際使用的模式
因為 zookeeper 保證 2n + 1 臺機器最大允許 n 臺機器掛掉, 所以配置集群模式最好是奇數臺機器: 3, 5, 7...
最少 3 臺構成集群
1 hosts 映射(可選)
echo "192.168.1.1 zoo1" >> /etc/hosts
echo "192.168.1.2 zoo2" >> /etc/hosts
echo "192.168.1.3 zoo3" >> /etc/hosts
2 修改 zookeeper-3.4.9/conf/zoo.cfg 文件
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/var/lib/zookeeper/data
dataLogDir=/var/lib/zookeeper/log
clientPort=2181
server.1=192.168.1.1:2888:3888
server.2=192.168.1.2:2888:3888
server.3=192.168.1.3:2888:3888
與單機模式的不同就是最后三條: server.X=host:portA:portB
server.1=192.168.1.1:2888:3888
server.2=192.168.1.2:2888:3888
server.3=192.168.1.3:2888:3888
或
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888
X 為標識為 X 的機器, host 為其 hostname 或 IP, portA 用于這臺機器與集群中的 Leader 機器通信, portB 用于 server 選舉 leader.
PS: 要配單機偽分布式的話, 可以修改這里為
server.1=localhost:2888:3888
server.2=localhost:2889:3889
server.3=localhost:2890:3890
然后每個 zookeeper 實例的 dataDir 和 dataLogDir 配置為不同的即可
3 myid 文件
在標示為 X 的機器上, 將 X 寫入 ${dataDir}/myid 文件, 如: 在 192.168.1.2 機器上的 /var/lib/zookeeper/data 目錄下建立文件 myid, 寫入 2
echo "2" > /var/lib/zookeeper/data/myid
4 開放端口
CentOS 7 使用 firewalld 代替了原來的 iptables, 基本使用如下
systemctl start firewalld # 啟動防火墻
firewall-cmd --state # 檢查防火墻狀態
firewall-cmd --zone=public --add-port=2888/tcp --permanent # 永久開啟 2888 端口
firewall-cmd --reload # 重新加載防火墻規則
firewall-cmd --list-all # 列出所有防火墻規則
把 Zookeeper 用到的端口開放出來
firewall-cmd --zone=public --add-port=2181/tcp --permanent # 永久開啟 2181 端口
firewall-cmd --zone=public --add-port=2888/tcp --permanent # 永久開啟 2888 端口
firewall-cmd --zone=public --add-port=3888/tcp --permanent # 永久開啟 3888 端口
firewall-cmd --reload # 重新加載防火墻規則
5 測試
- 在 集群中所有機器上 啟動 zookeeper(盡量同時):
bin/zkServer.sh start
- 查看狀態, 應該有一臺機器顯示
mode: leader, 其余為mode: follower
bin/zkServer.sh status
- 使用 java 客戶端連接 ZooKeeper
./bin/zkCli.sh -server 192.168.1.1:2181
然后就可以使用各種命令了, 跟文件操作命令很類似, 輸入help可以看到所有命令.
- 關閉 zookeeper:
./bin/zkServer.sh stop
3.2.3 Zookeeper 常見問題
查看狀態時, 應該有一臺機器顯示mode: leader, 其余為mode: follower
bin/zkServer.sh status
當顯示Error contacting service. It is probably not running.時, 可以查看日志
cat zookeeper.out
查看 zookeeper.out 日志可以看到是那些機器連不上, 可能是 網絡, ip, 端口, 配置文件, myid 文件 的問題.
正常應該是: 先是一些 java 異常, 這是因為 ZooKeeper 集群啟動的時候, 每個結點都試圖去連接集群中的其它結點, 先啟動的肯定連不上后面還沒啟動的, 所以上面日志前面部分的異常是可以忽略的, 當集群所有的機器的 zookeeper 都啟動起來, 就沒有異常了, 并選舉出來了 leader.
PS: 因為 zkServer.sh 腳本中是用 nohup 命令啟動 zookeeper 的, 所以 zookeeper.out 文件是在調用 zkServer.sh 時的路徑下, 如:用 bin/zkServer.sh start 啟動則 zookeeper.out 文件在 zookeeper-3.4.9/ 下; 用 zkServer.sh start 啟動則 zookeeper.out 文件在 zookeeper-3.4.9/bin/ 下.
4.kafka的應用
未完待續！！
