kafka入門:簡介、使用場景、設計原理、主要配置及叢集搭建
一、入門 1、簡介 Kafka is a distributed,partitioned,replicated commit logservice。它提供了類似於JMS的特性,但是在設計實現上完全不同,此外它並不是JMS規範的實現。kafka對訊息儲存時根據Topic進行歸類,傳送訊息者成為Producer,訊息接受者成為Consumer,此外kafka叢集有多個kafka例項組成,每個例項(
2、效能 需要考慮的影響效能點很多,除磁碟IO之外,我們還需要考慮網路IO,這直接關係到kafka的吞吐量問題.kafka並沒有提供太多高超的技巧;對於producer端,可以將訊息buffer起來,當訊息的條數達到一定閥值時,批量傳送給broker;對於consumer端也是一樣,批量fetch多條訊息.不過訊息量的大小可以通過配置檔案來指定.對於kafka broker端,似乎有個sendfile系統呼叫可以潛在的提升網路IO的效能:將檔案的資料對映到系統記憶體中,socket直接讀取相應的記憶體區域即可,而無需程序再次copy和交換. 其實對於producer/consumer/broker三者而言,CPU的開支應該都不大,因此啟用訊息壓縮機制是一個良好的策略;壓縮需要消耗少量的CPU資源,不過對於kafka而言,網路IO更應該需要考慮.可以將任何在網路上傳輸的訊息都經過壓縮.kafka支援gzip/snappy等多種壓縮方式. 3、生產者 負載均衡: producer將會和Topic下所有partition leader保持socket連線;訊息由producer直接通過socket傳送到broker,中間不會經過任何"路由層".事實上,訊息被路由到哪個partition上,有producer客戶端決定.比如可以採用"random""key-hash""輪詢"等,如果一個topic中有多個partitions,那麼在producer端實現"訊息均衡分發"是必要的. 其中partition leader的位置(host:port)註冊在zookeeper中,producer作為zookeeper client,已經註冊了watch用來監聽partition leader的變更事件. 非同步傳送:將多條訊息暫且在客戶端buffer起來,並將他們批量的傳送到broker,小資料IO太多,會拖慢整體的網路延遲,批量延遲傳送事實上提升了網路效率。不過這也有一定的隱患,比如說當producer失效時,那些尚未傳送的訊息將會丟失。 4、消費者 consumer端向broker傳送"fetch"請求,並告知其獲取訊息的offset;此後consumer將會獲得一定條數的訊息;consumer端也可以重置offset來重新消費訊息. 在JMS實現中,Topic模型基於push方式,即broker將訊息推送給consumer端.不過在kafka中,採用了pull方式,即consumer在和broker建立連線之後,主動去pull(或者說fetch)訊息;這中模式有些優點,首先consumer端可以根據自己的消費能力適時的去fetch訊息並處理,且可以控制訊息消費的進度(offset);此外,消費者可以良好的控制訊息消費的數量,batch fetch. 其他JMS實現,訊息消費的位置是有prodiver保留,以便避免重複傳送訊息或者將沒有消費成功的訊息重發等,同時還要控制訊息的狀態.這就要求JMS broker需要太多額外的工作.在kafka中,partition中的訊息只有一個consumer在消費,且不存在訊息狀態的控制,也沒有複雜的訊息確認機制,可見kafka broker端是相當輕量級的.當訊息被consumer接收之後,consumer可以在本地儲存最後訊息的offset,並間歇性的向zookeeper註冊offset.由此可見,consumer客戶端也很輕量級. <ignore_js_op> 5、訊息傳送機制 對於JMS實現,訊息傳輸擔保非常直接:有且只有一次(exactly once).在kafka中稍有不同: 1) at most once: 最多一次,這個和JMS中"非持久化"訊息類似.傳送一次,無論成敗,將不會重發. 2) at least once: 訊息至少傳送一次,如果訊息未能接受成功,可能會重發,直到接收成功. 3) exactly once: 訊息只會傳送一次. at most once: 消費者fetch訊息,然後儲存offset,然後處理訊息;當client儲存offset之後,但是在訊息處理過程中出現了異常,導致部分訊息未能繼續處理.那麼此後"未處理"的訊息將不能被fetch到,這就是"at most once". at least once: 消費者fetch訊息,然後處理訊息,然後儲存offset.如果訊息處理成功之後,但是在儲存offset階段zookeeper異常導致儲存操作未能執行成功,這就導致接下來再次fetch時可能獲得上次已經處理過的訊息,這就是"at least once",原因offset沒有及時的提交給zookeeper,zookeeper恢復正常還是之前offset狀態. exactly once: kafka中並沒有嚴格的去實現(基於2階段提交,事務),我們認為這種策略在kafka中是沒有必要的. 通常情況下"at-least-once"是我們搜選.(相比at most once而言,重複接收資料總比丟失資料要好). 6、複製備份 kafka將每個partition資料複製到多個server上,任何一個partition有一個leader和多個follower(可以沒有);備份的個數可以通過broker配置檔案來設定.leader處理所有的read-write請求,follower需要和leader保持同步.Follower和consumer一樣,消費訊息並儲存在本地日誌中;leader負責跟蹤所有的follower狀態,如果follower"落後"太多或者失效,leader將會把它從replicas同步列表中刪除.當所有的follower都將一條訊息儲存成功,此訊息才被認為是"committed",那麼此時consumer才能消費它.即使只有一個replicas例項存活,仍然可以保證訊息的正常傳送和接收,只要zookeeper叢集存活即可.(不同於其他分散式儲存,比如hbase需要"多數派"存活才行) 當leader失效時,需在followers中選取出新的leader,可能此時follower落後於leader,因此需要選擇一個"up-to-date"的follower.選擇follower時需要兼顧一個問題,就是新leaderserver上所已經承載的partition leader的個數,如果一個server上有過多的partition leader,意味著此server將承受著更多的IO壓力.在選舉新leader,需要考慮到"負載均衡". 7.日誌 如果一個topic的名稱為"my_topic",它有2個partitions,那麼日誌將會儲存在my_topic_0和my_topic_1兩個目錄中;日誌檔案中儲存了一序列"log entries"(日誌條目),每個log entry格式為"4個位元組的數字N表示訊息的長度" + "N個位元組的訊息內容";每個日誌都有一個offset來唯一的標記一條訊息,offset的值為8個位元組的數字,表示此訊息在此partition中所處的起始位置..每個partition在物理儲存層面,有多個log file組成(稱為segment).segmentfile的命名為"最小offset".kafka.例如"00000000000.kafka";其中"最小offset"表示此segment中起始訊息的offset. <ignore_js_op> 其中每個partiton中所持有的segments列表資訊會儲存在zookeeper中. 當segment檔案尺寸達到一定閥值時(可以通過配置檔案設定,預設1G),將會建立一個新的檔案;當buffer中訊息的條數達到閥值時將會觸發日誌資訊flush到日誌檔案中,同時如果"距離最近一次flush的時間差"達到閥值時,也會觸發flush到日誌檔案.如果broker失效,極有可能會丟失那些尚未flush到檔案的訊息.因為server意外實現,仍然會導致log檔案格式的破壞(檔案尾部),那麼就要求當server啟東是需要檢測最後一個segment的檔案結構是否合法並進行必要的修復. 獲取訊息時,需要指定offset和最大chunk尺寸,offset用來表示訊息的起始位置,chunk size用來表示最大獲取訊息的總長度(間接的表示訊息的條數).根據offset,可以找到此訊息所在segment檔案,然後根據segment的最小offset取差值,得到它在file中的相對位置,直接讀取輸出即可. 日誌檔案的刪除策略非常簡單:啟動一個後臺執行緒定期掃描log file列表,把儲存時間超過閥值的檔案直接刪除(根據檔案的建立時間).為了避免刪除檔案時仍然有read操作(consumer消費),採取copy-on-write方式. 8、分配 kafka使用zookeeper來儲存一些meta資訊,並使用了zookeeper watch機制來發現meta資訊的變更並作出相應的動作(比如consumer失效,觸發負載均衡等) 1) Broker node registry: 當一個kafkabroker啟動後,首先會向zookeeper註冊自己的節點資訊(臨時znode),同時當broker和zookeeper斷開連線時,此znode也會被刪除. 格式: /broker/ids/[0...N] -->host:port;其中[0..N]表示broker id,每個broker的配置檔案中都需要指定一個數字型別的id(全域性不可重複),znode的值為此broker的host:port資訊. 2) Broker Topic Registry: 當一個broker啟動時,會向zookeeper註冊自己持有的topic和partitions資訊,仍然是一個臨時znode. 格式: /broker/topics/[topic]/[0...N] 其中[0..N]表示partition索引號. 3) Consumer and Consumer group: 每個consumer客戶端被建立時,會向zookeeper註冊自己的資訊;此作用主要是為了"負載均衡". 一個group中的多個consumer可以交錯的消費一個topic的所有partitions;簡而言之,保證此topic的所有partitions都能被此group所消費,且消費時為了效能考慮,讓partition相對均衡的分散到每個consumer上. 4) Consumer id Registry: 每個consumer都有一個唯一的ID(host:uuid,可以通過配置檔案指定,也可以由系統生成),此id用來標記消費者資訊. 格式:/consumers/[group_id]/ids/[consumer_id] 仍然是一個臨時的znode,此節點的值為{"topic_name":#streams...},即表示此consumer目前所消費的topic + partitions列表. 5) Consumer offset Tracking: 用來跟蹤每個consumer目前所消費的partition中最大的offset. 格式:/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]-->offset_value 此znode為持久節點,可以看出offset跟group_id有關,以表明當group中一個消費者失效,其他consumer可以繼續消費. 6) Partition Owner registry: 用來標記partition被哪個consumer消費.臨時znode 格式:/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]-->consumer_node_id當consumer啟動時,所觸發的操作: A) 首先進行"Consumer id Registry"; B) 然後在"Consumer id Registry"節點下注冊一個watch用來監聽當前group中其他consumer的"leave"和"join";只要此znode path下節點列表變更,都會觸發此group下consumer的負載均衡.(比如一個consumer失效,那麼其他consumer接管partitions). C) 在"Broker id registry"節點下,註冊一個watch用來監聽broker的存活情況;如果broker列表變更,將會觸發所有的groups下的consumer重新balance. <ignore_js_op> 1) Producer端使用zookeeper用來"發現"broker列表,以及和Topic下每個partition leader建立socket連線併發送訊息. 2) Broker端使用zookeeper用來註冊broker資訊,已經監測partitionleader存活性. 3) Consumer端使用zookeeper用來註冊consumer資訊,其中包括consumer消費的partition列表等,同時也用來發現broker列表,並和partition leader建立socket連線,並獲取訊息. 四、主要配置 1、Broker配置 <ignore_js_op> 2.Consumer主要配置 <ignore_js_op> 3.Producer主要配置 <ignore_js_op> 以上是關於kafka一些基礎說明,在其中我們知道如果要kafka正常執行,必須配置zookeeper,否則無論是kafka叢集還是客戶端的生存者和消費者都無法正常的工作的,以下是對zookeeper進行一些簡單的介紹: 五、zookeeper叢集 zookeeper是一個為分散式應用提供一致性服務的軟體,它是開源的Hadoop專案的一個子專案,並根據google發表的一篇論文來實現的。zookeeper為分散式系統提供了高笑且易於使用的協同服務,它可以為分散式應用提供相當多的服務,諸如統一命名服務,配置管理,狀態同步和組服務等。zookeeper介面簡單,我們不必過多地糾結在分散式系統程式設計難於處理的同步和一致性問題上,你可以使用zookeeper提供的現成(off-the-shelf)服務來實現來實現分散式系統額配置管理,組管理,Leader選舉等功能。 zookeeper叢集的安裝,準備三臺伺服器server1:192.168.0.1,server2:192.168.0.2, server3:192.168.0.3. 1)下載zookeeper 到http://zookeeper.apache.org/releases.html去下載最新版本Zookeeper-3.4.5的安裝包zookeeper-3.4.5.tar.gz.將檔案儲存server1的~目錄下 2)安裝zookeeper 先在伺服器server分別執行a-c步驟 a)解壓 tar -zxvf zookeeper-3.4.5.tar.gz 解壓完成後在目錄~下會發現多出一個目錄zookeeper-3.4.5,重新命令為zookeeper b)配置 將conf/zoo_sample.cfg拷貝一份命名為zoo.cfg,也放在conf目錄下。然後按照如下值修改其中的配置: # The number of milliseconds of each tick tickTime=2000 # The number of ticks that the initial # synchronization phase can take initLimit=10 # The number of ticks that can pass between # sending a request and getting an acknowledgement syncLimit=5 # the directory where the snapshot is stored. # do not use /tmp for storage, /tmp here is just # example sakes. dataDir=/home/wwb/zookeeper /data dataLogDir=/home/wwb/zookeeper/logs # the port at which the clients will connect clientPort=2181 # # Be sure to read the maintenance section of the # administrator guide before turning on autopurge. # # The number of snapshots to retain in dataDir #autopurge.snapRetainCount=3 # Purge task interval in hours # Set to "0" to disable auto purge feature #autopurge.purgeInterval=1 server.1=192.168.0.1:3888:4888 server.2=192.168.0.2:3888:4888 server.3=192.168.0.3:3888:4888 tickTime:這個時間是作為 Zookeeper 伺服器之間或客戶端與伺服器之間維持心跳的時間間隔,也就是每個 tickTime 時間就會發送一個心跳。 dataDir:顧名思義就是 Zookeeper 儲存資料的目錄,預設情況下,Zookeeper 將寫資料的日誌檔案也儲存在這個目錄裡。 clientPort:這個埠就是客戶端連線 Zookeeper 伺服器的埠,Zookeeper 會監聽這個埠,接受客戶端的訪問請求。 initLimit:這個配置項是用來配置 Zookeeper 接受客戶端(這裡所說的客戶端不是使用者連線 Zookeeper 伺服器的客戶端,而是 Zookeeper 伺服器叢集中連線到 Leader 的 Follower 伺服器)初始化連線時最長能忍受多少個心跳時間間隔數。當已經超過 5個心跳的時間(也就是 tickTime)長度後 Zookeeper 伺服器還沒有收到客戶端的返回資訊,那麼表明這個客戶端連線失敗。總的時間長度就是 5*2000=10 秒 syncLimit:這個配置項標識 Leader 與Follower 之間傳送訊息,請求和應答時間長度,最長不能超過多少個 tickTime 的時間長度,總的時間長度就是2*2000=4 秒 server.A=B:C:D:其中 A 是一個數字,表示這個是第幾號伺服器;B 是這個伺服器的 ip 地址;C 表示的是這個伺服器與叢集中的 Leader 伺服器交換資訊的埠;D 表示的是萬一叢集中的 Leader 伺服器掛了,需要一個埠來重新進行選舉,選出一個新的 Leader,而這個埠就是用來執行選舉時伺服器相互通訊的埠。如果是偽叢集的配置方式,由於 B 都是一樣,所以不同的 Zookeeper 例項通訊埠號不能一樣,所以要給它們分配不同的埠號 注意:dataDir,dataLogDir中的wwb是當前登入使用者名稱,data,logs目錄開始是不存在,需要使用mkdir命令建立相應的目錄。並且在該目錄下建立檔案myid,serve1,server2,server3該檔案內容分別為1,2,3。 針對伺服器server2,server3可以將server1複製到相應的目錄,不過需要注意dataDir,dataLogDir目錄,並且檔案myid內容分別為2,3 3)依次啟動server1,server2,server3的zookeeper. /home/wwb/zookeeper/bin/zkServer.sh start,出現類似以下內容 JMX enabled by default Using config: /home/wwb/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED 4) 測試zookeeper是否正常工作,在server1上執行以下命令 /home/wwb/zookeeper/bin/zkCli.sh -server192.168.0.2:2181,出現類似以下內容 JLine support is enabled 2013-11-27 19:59:40,560 - INFO [main-SendThread(localhost.localdomain:2181):[email protected]]- Session establishmentcomplete on server localhost.localdomain/127.0.0.1:2181, sessionid = 0x1429cdb49220000, negotiatedtimeout = 30000 WATCHER:: WatchedEvent state:SyncConnected type:None path:null [zk: 127.0.0.1:2181(CONNECTED) 0] [[email protected]]# 即代表叢集構建成功了,如果出現錯誤那應該是第三部時沒有啟動好叢集,
相關推薦
kafka入門:簡介、使用場景、設計原理、主要配置及叢集搭建(轉)
問題導讀: 1.zookeeper在kafka的作用是什麼? 2.kafka中幾乎不允許對訊息進行“隨機讀寫”的原因是什麼? 3.kafka叢集consumer和producer狀態資訊是如何儲存的? 4.partitions設計的目的的根本原因是什麼? 一、入門 1、簡介
kafka入門:簡介、使用場景、設計原理、主要配置及叢集搭建
問題導讀: 1.zookeeper在kafka的作用是什麼? 2.kafka中幾乎不允許對訊息進行“隨機讀寫”的原因是什麼? 3.kafka叢集consumer和producer狀態資訊是如何儲存的? 4.partitions設計的目的的根本原因是什麼?
10034---kafka入門:簡介、使用場景、設計原理、主要配置及叢集搭建
一個Topic可以認為是一類訊息,每個topic將被分成多個partition(區),每個partition在儲存層面是append log檔案。任何釋出到此partition的訊息都會被直接追加到log檔案的尾部,每條訊息在檔案中的位置稱為offset(偏移量),offset為一個long型數字,它
kafka入門:簡介、使用場景、設計原理、主要配置及叢集搭建http://www.aboutyun.com/thread-9341-1-1.html
文章轉自:http://www.aboutyun.com/thread-9341-1-1.html 問題導讀: 1.zookeeper在kafka的作用是什麼? 2.kafka中幾乎不允許對訊息進行“隨機讀寫”的原因是什麼? 3.kafka叢集consumer和
推薦 kafka 簡介、使用場景、設計原理、主要配置及叢集搭建
需要考慮的影響效能點很多,除磁碟IO之外,我們還需要考慮網路IO,這直接關係到kafka的吞吐量問題.kafka並沒有提供太多高超的技巧;對於producer端,可以將訊息buffer起來,當訊息的條數達到一定閥值時,批量傳送給broker;對於consumer端也是一樣,批量fetch多條訊息.不
kafka入門:簡介、使用場景、設計原理、主要配置及集群搭建(轉)
request 上傳 結構 數據 send gist segments ring 希望 問題導讀: 1.zookeeper在kafka的作用是什麽? 2.kafka中幾乎不允許對消息進行“隨機讀寫”的原因是什麽? 3.kafka集群consumer和producer狀態信息
:Hadoop、NoSQL、分散式、lucene、solr、nutch kafka入門:簡介、使用場景、設計原理、主要配置及叢集搭
需要考慮的影響效能點很多,除磁碟IO之外,我們還需要考慮網路IO,這直接關係到kafka的吞吐量問題.kafka並沒有提供太多高超的技巧;對於producer端,可以將訊息buffer起來,當訊息的條數達到一定閥值時,批量傳送給broker;對於consumer端也是一樣,批量fetch多條訊息.不
kafka入門:簡介、使用場景、設計原理、配置及叢集搭建
問題導讀: 1.zookeeper在kafka的作用是什麼? 2.kafka中幾乎不允許對訊息進行“隨機讀寫”的原因是什麼? 3.kafka叢集consumer和producer狀態資訊是如何儲存的? 4.partitions設計的目的的根本原因是什麼? 一、入
ZooKeeper簡介、設計原理、主要配置及叢集
一、Zookeeper的一些概念和理解 1、資料模型 如上圖所示,ZooKeeper資料模型的結構與Unix檔案系統很類似,整體上可以看作是一棵樹,每個節點稱做一個ZNode。每個ZNode都可以通過其路徑唯一標識,比如上圖中第三層的第一個ZNode, 它的路徑是/app1/c1。在每個ZNode上可儲存
1.1.12、CPU的設計原理、資料匯流排和地址匯流排
CPU和匯流排示意圖 地址匯流排和資料匯流排 CPU通過地址匯流排定址,然後通過資料匯流排與外部裝置互換資訊 地址匯流排的位數決定CPU定址範圍 資料匯流排的位數決定CPU單次通訊能交換的資訊數
JAVAEE——SpringBoot入門:簡介、微服務、環境準備、helloworld與探究、快速構建專案
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <ver
Kafka入門,簡介,使用場景(轉載)
一、入門 1、簡介 Kafka is a distributed,partitioned,replicated commit logservice。它提供了類似於JMS的特性,但是在設計實現上完全不同,此外它並不是JMS規範的實現。kafka對訊息儲存
將課程作業01、02、03的設計思想、源程序代碼和結果截圖整理成一篇博文。。
top exception 漢諾塔 一個數 resource valueof val 作業 回文數 信1605-3 於丁一 20163578 使用組合數公式利用n!來計算 設計思想:首先要判斷一個數的階乘如何表達,然後調用方法用組合數公式,最後求出組合數。 packag
找人設計logo、代做設計海報、定制設計制作品牌商標標誌、設計卡通企業vi字體、平面設計
印刷 宣傳 困難 div border 有效 設計師 也不能 定制 1、設計師對LOGO制作技術了解不全面多數設計師能夠設計出好看的logo,但是對於現實的技術實現不太了解,在電腦上設計圖形時,沒有考慮logo的媒介使用,以及不同環境下logo的再現方式,很多情況下使用方式
Asp.net core 專案實戰 新聞網站+後臺 原始碼、設計原理 、視訊教程
首先說明,視訊教程、原始碼並非本人原創 本人將專案分割開,並寫了一些說明。 該視訊教程 地址 https://study.163.com/course/courseMain.htm?courseId=1005955006 原作者 筆者正在學 ASP.NET Core ,發現這
阿里P8架構師談:分散式資料庫資料一致性的原理、與技術實現方案!
背景 可用性(Availability)和一致性(Consistency)是分散式系統的基本問題,先有著名的CAP理論定義過分散式環境下二者不可兼得的關係,又有神祕的Paxos協議號稱是史上最簡單的分散式系統一致性演算法並獲得圖靈獎,再有開源產品ZooKeeper實現的Z
Django_xAdmin線上教育平臺(一)之專案結構、資料庫的設計以及xadmin的配置
django專案的目錄結構: dj_education資料夾: settings.py:django專案的全域性配置 url.py:url配置 templates資料夾:存放html檔案 manage.py:專案啟動的檔案
go語言快速入門:簡介(1)
go語言成為2016年TIOBE年度語言,距離上次TIOBE年度語言至今已經過去7年,在過去的7年裡,go語言也得到了廣泛的應用,尤其是在開源領域,從docker到kubernetes都使用了go作為開發語言。在這系列文章中,我們將一起來由淺入深學習一下go語言
【深度學習】5:CNN卷積神經網路原理、識別MNIST資料集
前言:先坦白的說,深度神經網路的學習在一開始對我造成的困擾還是很大的,我也是通過不斷地看相關的視訊資料、文獻講解嘗試去理解記憶。畢竟這些內容大多都是不可查的,我們看到的都只是輸入輸出的東西,裡面的內部運作以及工作原理,都需要沉心靜思。 這篇CNN卷積神經網路的
【深度學習】6:RNN遞迴神經網路原理、與MNIST資料集實現數字識別
前言:自己學習研究完CNN卷積神經網路後,很久的