消息隊列這個類型的組件一直是很是重要的組件,當通過兩家企業後我就很堅信這個結論了。隊列這種東西,最普遍的做用仍是在於解耦,寬泛一點的說,它能夠將不一樣部門的工做內容進行有效的整合,基於一個約定好的格式,就能夠兩頭互相不干擾的進行開發。能夠說這個生產消費的思想不單單適用於程序也適用於很是多的地方。
目前對於我看到的來講,kafka更多的仍是作爲一個數據源,數據橋樑的做用,不一樣業務之間的溝通。好比須要實時接入A部門的業務數據的話,就會有這樣的手段:算法
落地到HDFS的數據會用來進行一些算法上的離線處理,而kafka端則是給須要實時性的消費方。其實數據的消費方式無非也就實時和離線兩種方式。服務器
相比過去常常使用的activemq,kafka確實很是的不一樣,作一個對比來深化印象session
對比 | Activemq | Kafka |
---|---|---|
接口協議 | 遵照JMS規範,各語言支持較好 | 沒有遵循標準MQ接口協議,使用較爲複雜 |
吞吐量 | 較低,磁盤隨機讀寫 | 較高,磁盤順序讀寫 |
遊標位置 | AMQ來管理,沒法讀取歷史數據 | 客戶端本身管理,不樂意甚至從新讀一遍也行 |
HA機制 | 主從複製,競爭鎖的方式來選舉新的主節點 | 和hadoop系列產品同樣,由zk管理全部節點 |
說到底,主要仍是作爲kafka的消費方,能感覺到最大的不一樣仍是在於幾個:oop
1.Broker:消息中間件處理結點,一個Kafka節點就是一個broker,多個broker能夠組成一個Kafka集羣。
2.Topic:一類消息,例如page view日誌、click日誌等均可以以topic的形式存在,Kafka集羣可以同時負責多個topic的分發。
3.Partition:topic物理上的分組,一個topic能夠分爲多個partition,每一個partition是一個有序的隊列。
4.Segment:partition物理上由多個segment組成。
5.offset:每一個partition都由一系列有序的、不可變的消息組成,這些消息被連續的追加到partition中。partition中的每一個消息都有一個連續的序列號叫作offset,用於partition惟一標識一條消息.日誌
Properties props = new Properties(); //zk服務器的地址 xxxx:2181 props.put("zookeeper.connect", zookeeper); //組的名稱,區別於其餘group不然會接收不到數據 props.put("group.id", groupId); props.put("zookeeper.session.timeout.ms", "8000"); props.put("zookeeper.connection.timeout.ms", "20000"); props.put("zookeeper.sync.time.ms", "2000"); props.put("auto.commit.interval.ms", "5000"); props.put("rebalance.max.retries", "5"); props.put("rebalance.backoff.ms", "60000"); props.put("auto.commit.enable", "true"); //重點參數,是否每次都從offset最前面開始讀起 props.put("auto.offset.reset", "smallest");
查看全部的topiccode
bin/kafka-topics.sh --zookeeper zk1.test-inf-zk.data.m.com:2181/octopus,zk2.test-inf-zk.data.m.com:2181/octopus,zk3.test-inf-zk.data.m.com:2181/octopus --list
查看topic的偏移量orm
bin/kafka-run-class.sh kafka.tools.GetOffsetShell --topic xiuxiu_sync_search_big_data --time -1 --broker-list 192.168.199.11:9092 --partitions 0
查看topic的狀態中間件
bin/kafka-topics.sh --zookeeper 192.168.199.11:2181 --topic xiuxiu_sync_search_big_data --descr