kafka集群搭建

【環境】
三臺虛擬機

192.168.1.224  hadoop2004
192.168.1.225  hadoop2005
192.168.1.226  hadoop2006

確保每臺機器上均安裝了JDK
確保zookeeper集群(kafka集群的搭建是建立在jdk和zookeeper集群環境之上的)

【1 :zookeeper集群搭建】

【1.1】解壓tar包

在機器192.168.1.224  hadoop2004機器上
tar -xzvf zookeeper3.4.6.tar.gz /usr/local

【1.2】修改配置

cd /usr/local/zookeeper3.4.6/conf

mv zoo_sample.cfg zoo.cfg

Paste_Image.png

配置文件解釋

#tickTime:
這個時間是作為 Zookeeper 服務器之間或客戶端與服務器之間維持心跳的時間間隔,也就是每個 tickTime 時間就會發送一個心跳。
#initLimit:
這個配置項是用來配置 Zookeeper 接受客戶端(這里所說的客戶端不是用戶連接 Zookeeper 服務器的客戶端,而是 Zookeeper 服務器集群中連接到 Leader 的 Follower 服務器)初始化連接時最長能忍受多少個心跳時間間隔數。當已經超過 5個心跳的時間(也就是 tickTime)長度后 Zookeeper 服務器還沒有收到客戶端的返回信息,那么表明這個客戶端連接失敗。總的時間長度就是 5*2000=10 秒
#syncLimit:
這個配置項標識 Leader 與Follower 之間發送消息,請求和應答時間長度,最長不能超過多少個 tickTime 的時間長度,總的時間長度就是5*2000=10秒
#dataDir:
快照日志的存儲路徑
#dataLogDir:
事物日志的存儲路徑,如果不配置這個那么事物日志會默認存儲到dataDir制定的目錄,這樣會嚴重影響zk的性能,當zk吞吐量較大的時候,產生的事物日志、快照日志太多
#clientPort:
這個端口就是客戶端連接 Zookeeper 服務器的端口,Zookeeper 會監聽這個端口,接受客戶端的訪問請求。修改他的端口改大點

【1.3】添加所配置的數據存儲目錄data

mkdir /usr/local/zookeeper/data
cd data
//在data下創建一個myid文件
touch myid
//在myid文件中編寫此機器的編號(這個是server1,則編號就是1)
vim myid (添加1)
注意:這里的myid文件時區分集群中的機器的,所以各個機器上的myid不能重復

【1.4】復制zookeeper目錄到hadoop2005和hadoop2006機器上

利用免密碼登陸復制文件
scp -r zookeeper root@hadoop02:/usr/local
scp -r zookeeper root@hadoop03:/usr/local

【1.5】
分別修改server2和server3機器目錄下、/usr/local/zookeeper/data的myid文件,將文件內容分別該為server編號(2 , 3)
【1.6】

分別在三臺機器上啟動
./zkServer.sh start(開啟)

./zkServer.sh status(重啟) 重啟可以查看到它的角色狀態

【1.7】配置說明

1、myid文件和server.myid  在快照目錄下存放的標識本臺服務器的文件,他是整個zk集群用來發現彼此的一個重要標識。

2、zoo.cfg 文件是zookeeper配置文件 在conf目錄里。

3、log4j.properties文件是zk的日志輸出文件 在conf目錄里用java寫的程序基本上有個共同點日志都用log4j,來進行管理。

4、zkEnv.sh和zkServer.sh文件

zkServer.sh 主的管理程序文件
zkEnv.sh 是主要配置,zookeeper集群啟動時配置環境變量的文件

5、還有一個需要注意
zookeeper不會主動的清除舊的快照和日志文件,這個是操作者的責任。
      定時清理的方式有很多
      a : 自己寫腳本
      b : ZK自己已經寫好了腳本,在bin/zkCleanup.sh中,所以直接使用這個腳本也是可以執行清理工作的。
      c: zookeeper在zoo.cfg中提供了兩個參數用來做清理工作
          參數一:autopurge.purgeInterval  這個參數指定了清理頻率,單位是小時,需要填寫一個1或更大的整數,默認是0,表示不開啟自己清理功能。
          參數二:autopurge.snapRetainCount 這個參數和上面的參數搭配使用,這個參數指定了需要保留的文件數目。默認是保留3個。

-----------------------------------------------kafka---------------------------------------------------------

【2 : kafka集群搭建】
【2.1環境準備】
1、linux一臺或多臺,大于等于2
2、已經搭建好的zookeeper集群
3、軟件版本kafka_2.11-0.9.0.1.tgz

【2.2】解壓tar包

在192.168.1.224 hadoop2004機器上
tar -zxvf kafka_2.11-0.9.0.1.tgz /usr/local

【2.3】添加log目錄和修改配置

cd /usr/llocal/kafka_2.11-0.9.0.1
mkdir kafka_log

cd /usr/local/kafka_2.11-0.9.0.1/config
vim server.properties  

配置文件解釋

broker.id=1
    #當前機器在集群中的唯一標識,和zookeeper的myid性質一樣
port=19092 
    #當前kafka對外提供服務的端口默認是9092
host.name=192.168.1.224
    #這個參數默認是關閉的,在0.8.1有個bug,DNS解析問題,失敗率的問題。
num.network.threads=3 
    #這個是borker進行網絡處理的線程數
num.io.threads=8 
    #這個是borker進行I/O處理的線程數
log.dirs=/usr/local/kafka/kafka_2.11-0.9.0.1/kafka_log
    #消息存放的目錄,這個目錄可以配置為“,”逗號分割的表達式,上面的num.io.threads要大于這個目錄的個數這個目錄,如果配置多個目錄,新創建的topic他把消息持久化的地方是,當前以逗號分割的目錄中,那個分區數最少就放那一個
socket.send.buffer.bytes=102400 
    #發送緩沖區buffer大小,數據不是一下子就發送的,先回存儲到緩沖區了到達一定的大小后在發送,能提高性能
socket.receive.buffer.bytes=102400 
    #kafka接收緩沖區大小,當數據到達一定大小后在序列化到磁盤
socket.request.max.bytes=104857600 
    #這個參數是向kafka請求消息或者向kafka發送消息的請請求的最大數,這個值不能超過java的堆棧大小
num.partitions=1 
    #默認的分區數,一個topic默認1個分區數
log.retention.hours=168 
    #默認消息的最大持久化時間,168小時,7天
message.max.byte=5242880 
    #消息保存的最大值5M
default.replication.factor=2 
    #kafka保存消息的副本數,如果一個副本失效了,另一個還可以繼續提供服務
replica.fetch.max.bytes=5242880 
    #取消息的最大直接數
log.segment.bytes=1073741824 
    #這個參數是:因為kafka的消息是以追加的形式落地到文件,當超過這個值的時候,kafka會新起一個文件
log.retention.check.interval.ms=300000 
    #每隔300000毫秒去檢查上面配置的log失效時間(log.retention.hours=168 ),到目錄查看是否有過期的消息如果有,刪除
log.cleaner.enable=false 
    #是否啟用log壓縮,一般不用啟用,啟用的話可以提高性能
zookeeper.connect=192.168.1.224:2181,192.168.1.225:2181,192.168.1.226:1218 
    #設置zookeeper的連接端口

實際修改

#broker.id=1 每臺服務器的broker.id都不能相同

#hostname
host.name=192.168.1.224

#在log.retention.hours=168 下面新增下面三項
message.max.byte=5242880
default.replication.factor=2
replica.fetch.max.bytes=5242880

#設置zookeeper的連接端口
zookeeper.connect=192.168.1.224:2181,192.168.1.225:2181,192.168.1.226:1218 

【2.4啟動服務】

#從后臺啟動Kafka集群(3臺都需要啟動)
./kafka-server-start.sh -daemon ../config/server.properties
啟動kafka.png

【2.5檢查服務啟動】

#執行命令jps
20348 Jps
4233 QuorumPeerMain
18991 Kafka

【2.6創建一個主題】

#創建Topic(在機器192.168.1.224 hadoop2004機器上)
./kafka-topics.sh --create --zookeeper 192.168.1.224:2181 --replication-factor 2 --partitions 1 --topic lvfang

#解釋
--replication-factor 2 #復制兩份
--partitions 1 #創建1個分區
--topic #主題為shuaige
創建主題.png

【2.7創建一個發布者】

#創建一個broker,發布者(在機器192.168.1.225 hadoop2005機器上)
./kafka-console-producer.sh --broker-list 192.168.1.225:19092 --topic lvfang
創建一個發布者.png

【2.8創建一個訂閱者】(在機器192.168.1.226 hadoop2006機器上)

'''在一臺服務器上創建一個訂閱者'''
./kafka-console-consumer.sh --zookeeper 192.168.1.226:12181 --topic lvfang --from-beginning

創建好訂閱者之后就可以在發布者機器上發布消息,看看訂閱者能否接收到
創建一個接收者.png

【2.8其他命令】

#查看主題
./kafka-topics.sh --list --zookeeper localhost:12181

#查看topic狀態
/kafka-topics.sh --describe --zookeeper localhost:12181 --topic lvfang
#下面是顯示信息
Topic:ssports   PartitionCount:1   ReplicationFactor:2   Configs: 
          Topic: lvfang   Partition: 0   Leader: 1   Replicas: 0,1   Isr: 1
#分區為為1 復制因子為2 他的 shuaige的分區為0 
#Replicas: 0,1 復制的為0,1


查看主題列表.png
查看主題狀態.png

PartitionCount:1 分區數為1個
ReplicationFactor:2 分區備份2個
Topic: lvfang 主題是 lvfang
Partition: 0 在0分區上
Leader: 2 Leader是2號機器(即broker 2上)
Replicas: 2,3 備份在2號機和3號機上
Isr: 2,3 處于同步中(一般如果leader掛掉了,最好選擇處于同步的broker機作為新的leader,這樣數據誤差會最小 )

OK
kafka集群搭建完畢-------------------------------------------------------------

【3:其他說明】

【3.1 日志說明】
默認kafka的日志是保存在/opt/kafka/kafka_2.10-0.9.0.0/logs目錄下的,這里說幾個需要注意的日志

server.log 
    #kafka的運行日志

state-change.log 
    #kafka他是用zookeeper來保存狀態,所以他可能會進行切換,切換的日志就保存在這里

controller.log 
    #kafka選擇一個節點作為“controller”,當發現有節點down掉的時候它負責在游泳分區的所有節點中選擇新的leader,這使得Kafka可以批量的高效的管理所有分區節點的主從關系。如果controller down掉了,活著的節點中的一個會備切換為新的controller.

【3.2查看zookeeper上的內容】

./zkCli.sh

#查看目錄情況 執行“ls /”
[zk: localhost:2181(CONNECTED) 3] ls /

#顯示結果:
    [consumers, config, controller, isr_change_notification, admin, brokers, zookeeper, controller_epoch]
    上面的顯示結果中:只有zookeeper是,zookeeper原生的,其他都是Kafka創建的

#標注一個重要的
[zk: localhost:2181(CONNECTED) 3] get /brokers/ids/1
{"jmx_port":-1,"timestamp":"1456125963355","endpoints["PLAINTEXT://192.168.7.100:19092"],"host":"192.168.7.100","version":2,"port":19092}

#還有一個是查看partion
[zk: localhost:2181(CONNECTED) 4] get /brokers/topics/shuaige/partitions/0
2017-01-13_124134.png
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,983評論 6 537
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,772評論 3 422
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,947評論 0 381
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,201評論 1 315
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,960評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,350評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,406評論 3 444
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,549評論 0 289
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,104評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,914評論 3 356
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,089評論 1 371
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,647評論 5 362
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,340評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,753評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,007評論 1 289
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,834評論 3 395
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,106評論 2 375

推薦閱讀更多精彩內容