Kafka介紹教學講解課件

Kafka介紹研發(fā)二部Kafka介紹1內容kafka是什么kafka體系結構kafka設計理念簡介kafka安裝部署kafkaproducer和consumer開發(fā)內容kafka是什么2Kafka關鍵詞分布式發(fā)布-訂閱消息系統(tǒng)LinkedIn公司開發(fā)Scala語言分布式的，可劃分的，多訂閱者冗余備份持久性重復消費Kafka關鍵詞分布式發(fā)布-訂閱消息系統(tǒng)3Kafka關鍵特性同時為發(fā)布和訂閱提供高吞吐量。據了解，Kafka每秒可以生產約25萬消息（50MB），每秒處理55萬消息（110MB）?？蛇M行持久化操作。將消息持久化到磁盤，因此可用于批量消費，例如ETL，以及實時應用程序。通過將數據持久化到硬盤以及replication防止數據丟失。分布式系統(tǒng)，易于向外擴展。所有的producer、broker和consumer都會有多個，均為分布式的。無需停機即可擴展機器。消息被處理的狀態(tài)是在consumer端維護，而不是由server端維護。當失敗時能自動平衡。支持online和offline的場景。Kafka關鍵特性同時為發(fā)布和訂閱提供高吞吐量。據了解，Ka4Kafka的兩大法寶數據文件的分段：Kafka解決查詢效率的手段之一是將數據文件分段；為數據文件建索引：為了進一步提高查找的效率，Kafka為每個分段后的數據文件建立了索引文件，文件名與數據文件的名字是一樣的，只是文件擴展名為.index。索引文件中包含若干個索引條目，每個條目表示數據文件中一條Message的索引。索引包含兩個部分（均為4個字節(jié)的數字），分別為相對offset和position。索引優(yōu)化：稀疏存儲，每隔一定字節(jié)的數據建立一條索引。Kafka的兩大法寶數據文件的分段：為了進一步提高查找的效率5消息隊列分類點對點:消息生產者生產消息發(fā)送到queue中，然后消息消費者從queue中取出并且消費消息。注意：消息被消費以后，queue中不再有存儲，所以消息消費者不可能消費到已經被消費的消息。Queue支持存在多個消費者，但是對一個消息而言，只會有一個消費者可以消費。發(fā)布/訂閱:消息生產者（發(fā)布）將消息發(fā)布到topic中，同時有多個消息消費者（訂閱）消費該消息。和點對點方式不同，發(fā)布到topic的消息會被所有訂閱者消費。消息隊列分類點對點:6消息隊列MQ對比RabbitMQ：支持的協(xié)議多，非常重量級消息隊列，對路由(Routing)，負載均衡(Loadbalance)或者數據持久化都有很好的支持。ZeroMQ：號稱最快的消息隊列系統(tǒng)，尤其針對大吞吐量的需求場景，擅長的高級/復雜的隊列，但是技術也復雜，并且只提供非持久性的隊列。ActiveMQ：Apache下的一個子項，類似ZeroMQ，能夠以代理人和點對點的技術實現(xiàn)隊列。Redis：是一個key-Value的NOSql數據庫，但也支持MQ功能，數據量較小，性能優(yōu)于RabbitMQ，數據超過10K就慢的無法忍受Jafka，基于Kafka孵化，非Apache官方孵化，活躍度也不是很高消息隊列MQ對比RabbitMQ：支持的協(xié)議多，非常重量級消7Kafka架構Kafka架構8Kafka的基本概念Producers：消息和數據生產者，向Kafka的一個topic發(fā)布消息的過程叫做producers。Consumers：消息和數據消費者，訂閱topics并處理其發(fā)布的消息的過程叫做consumers。Broker：緩存代理，Kafka集群中的一臺或多臺服務器統(tǒng)稱為broker。Topic：特指Kafka處理的消息源（feedsofmessages）的不同分類。Partition：Topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的隊列。partition中的每條消息都會被分配一個有序的id（offset）。Message：消息，是通信的基本單位，每個producer可以向一個topic（主題）發(fā)布一些消息。Kafka的基本概念Producers：消息和數據生產者，向9Kafka的ProducersProducer將消息發(fā)布到指定的Topic中,同時Producer也能決定將此消息歸屬于哪個partition;比如基于"round-robin"方式或者通過其他的一些算法等.消息和數據生產者，向Kafka的一個topic發(fā)布消息的過程叫做producers。異步發(fā)送批量發(fā)送可以很有效的提高發(fā)送效率。Kafkaproducer的異步發(fā)送模式允許進行批量發(fā)送，先將消息緩存在內存中，然后一次請求批量發(fā)送出去。Kafka的ProducersProducer將消息發(fā)布到指10Kafka的broker1.Broker沒有副本機制，一旦broker宕機，該broker的消息將都不可用。2.Broker：緩存代理，Kafka集群中的一臺或多臺服務器統(tǒng)稱為broker。broker會將消息暫時buffer起來,當消息的個數(或尺寸)達到一定閥值時,再flush到磁盤3.Broker不保存訂閱者的狀態(tài)，由訂閱者自己保存。4.無狀態(tài)導致消息的刪除成為難題（可能刪除的消息正在被訂閱），kafka采用基于時間的SLA(服務水平保證)，消息保存一定時間（通常為7天）后會被刪除。5.消息訂閱者可以rewindback到任意位置重新進行消費，當訂閱者故障時，可以選擇最小的offset(id)進行重新讀取消費消息。Kafka的broker1.Broker沒有副本機制，一11Kafka的Consumers消息和數據消費者，訂閱topics并處理其發(fā)布的消息的過程叫做consumers。本質上kafka只支持Topic.每個consumer屬于一個consumergroup;反過來說,每個group中可以有多個consumer.發(fā)送到Topic的消息,只會被訂閱此Topic的每個group中的一個consumer消費.可以認為一個group是一個"訂閱"者,一個Topic中的每個partions,只會被一個"訂閱者"中的一個consumer消費,不過一個consumer可以消費多個partitions中的消息.kafka只能保證一個partition中的消息被某個consumer消費時,消息是順序的.事實上,從Topic角度來說,消息仍不是有序的.注：kafka的設計原理決定,對于一個topic,同一個group中不能有多于partitions個數的consumer同時消費,否則將意味著某些consumer將無法得到消息.一個partition中的消息只會被group中的一個consumer消費;每個group中consumer消息消費互相獨立;Kafka的Consumers消息和數據消費者，訂閱top12Kafka的Topics/Log一個Topic可以認為是一類消息，每個topic將被分成多partition(區(qū)),每個partition在存儲層面是appendlog文件。任何發(fā)布到此partition的消息都會被直接追加到log文件的尾部，每條消息在文件中的位置稱為offset（偏移量）,partition是以文件的形式存儲在文件系統(tǒng)中。Logs文件根據broker中的配置要求,保留一定時間后刪除來釋放磁盤空間。Partition：

Topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的隊列。

partition中的每條消息都會被分配一個有序的id（offset）。Kafka的Topics/Log一個Topic可以認為是一類13Kafka的partitions設計目的：kafka基于文件存儲.通過分區(qū),可以將日志內容分散到多個server上,來避免文件尺寸達到單機磁盤的上限,每個partiton都會被當前server(kafka實例)保存;可以將一個topic切分多任意多個partitions,來消息保存/消費的效率.越多的partitions意味著可以容納更多的consumer,有效提升并發(fā)消費的能力.Kafka的partitions設計目的：14Kafka的MessageMessage消息：是通信的基本單位，每個producer可以向一個topic（主題）發(fā)布一些消息。Kafka中的Message是以topic為基本單位組織的，不同的topic之間是相互獨立的。每個topic又可以分成幾個不同的partition(每個topic有幾個partition是在創(chuàng)建topic時指定的)，每個partition存儲一部分Message。partition中的每條Message包含了以下三個屬性：offset 對應類型：longMessageSize 對應類型：int32data 是message的具體內容Kafka的MessageMessage消息：是通信的基本單15Kafka的MessageKafka的Message16Kafka的offset每條消息在文件中的位置稱為offset（偏移量）。offset為一個long型數字，它是唯一標記一條消息。它唯一的標記一條消息。kafka并沒有提供其他額外的索引機制來存儲offset，因為在kafka中幾

乎不允許對消息進行“隨機讀寫”。Partition中的每條Message由offset來表示它在這個partition中的偏移量，這個offset不是該Message在partition數據文件中的實際存儲位置，而是邏輯上一個值，它唯一確定了partition中的一條Message。因此，可以認為offset是partition中Message的id。怎樣記錄每個consumer處理的信息的狀態(tài)？在Kafka中僅保存了每個consumer已經處理數據的offset。這樣有兩個好處：1）保

存的數據量少

2）當consumer出錯時，重新啟動consumer處理數據時，只需從最近的offset開始處理數據即可。Kafka的offset每條消息在文件中的位置稱為offs17Kafka的消息處理機制1.發(fā)送到partitions中的消息將會按照它接收的順序追加到日志中2.對于消費者而言,它們消費消息的順序和日志中消息順序一致.3.如果Topic的"replicationfactor"為N,那么允許N-1個kafka實例失效.4.kafka對消息的重復、丟失、錯誤以及順序型沒有嚴格的要求。5.kafka提供at-least-oncedelivery,即當consumer宕機后，有些消息可能會被重復delivery。6.因每個partition只會被consumergroup內的一個consumer消費，故kafka保證每個partition內的消息會被順序的訂閱。7.Kafka為每條消息為每條消息計算CRC校驗，用于錯誤檢測，crc校驗不通過的消息會直接被丟棄掉。ack校驗，當消費者消費成功，返回ack信息！Kafka的消息處理機制1.發(fā)送到partitions18數據傳輸的事務定義atmostonce:最多一次,這個和JMS中"非持久化"消息類似.發(fā)送一次,無論成敗,將不會重發(fā).atleastonce:消息至少發(fā)送一次,如果消息未能接受成功,可能會重發(fā),直到接收成功.exactlyonce:消息只會發(fā)送一次.atmostonce:消費者fetch消息,然后保存offset,然后處理消息;當client保存offset之后,但是在消息處理過程中出現(xiàn)了異常,導致部分消息未能繼續(xù)處理.那么此后"未處理"的消息將不能被fetch到,這就是"atmostonce".atleastonce:消費者fetch消息,然后處理消息,然后保存offset.如果消息處理成功之后,但是在保存offset階段zookeeper異常導致保存操作未能執(zhí)行成功,這就導致接下來再次fetch時可能獲得上次已經處理過的消息,這就是"atleastonce"，原因offset沒有及時的提交給zookeeper，zookeeper恢復正常還是之前offset狀態(tài).exactlyonce:kafka中并沒有嚴格的去實現(xiàn)(基于2階段提交,事務),我們認為這種策略在kafka中是沒有必要的.注：通常情況下"at-least-once"是我們首選.(相比atmostonce而言,重復接收數據總比丟失數據要好).數據傳輸的事務定義atmostonce:最多一次,這個19Kafka的儲存策略1.kafka以topic來進行消息管理，每個topic包含多個part（ition），每個part對應一個邏輯log，有多個segment組成。2.每個segment中存儲多條消息（見下圖），消息id由其邏輯位置決定，即從消息id可直接定位到消息的存儲位置，避免id到位置的額外映射。3.broker收到發(fā)布消息往對應partition的最后一個segment上添加該消息Kafka的儲存策略1.kafka以topic來進行消息20Kafka的儲存策略 4.每個part在內存中對應一個index，記錄每個segment中的第一條消息偏移。5.發(fā)布者發(fā)到某個topic的消息會被均勻的分布到多個part上（隨機或根據用戶指定的回調函數進行分布），broker收到發(fā)布消息往對應part的最后一個segment上添加該消息，當某個segment上的消息條數達到配置值或消息發(fā)布時間超過閾值時，segment上的消息會被flush到磁盤，只有flush到磁盤上的消息訂閱者才能訂閱到，segment達到一定的大小后將不會再往該segment寫數據，broker會創(chuàng)建新的segment。Kafka的儲存策略 4.每個part在內存中對應一個i21Kafka的消息發(fā)送的流程由于kafkabroker會持久化數據，broker沒有內存壓力，因此，consumer非常適合采取pull的方式消費數據Producer向Kafka（push）推數據consumer從kafka拉（pull）數據。Kafka的消息發(fā)送的流程由于kafkabroker會22Kafka設計原理實現(xiàn)kafka以topic來進行消息管理，發(fā)布者發(fā)到某個topic的消息會被均勻的分布到多個partition上每個topic包含多個partition，每個part對應一個邏輯log，有多個segment組成。每個segment中存儲多條消息，消息id由其邏輯位置決定，即從消息id可直接定位到消息的存儲位置，避免id到位置的額外映射。每個part在內存中對應一個index，記錄每個segment中的第一條消息偏移。當某個segment上的消息條數達到配置值或消息發(fā)布時間超過閾值時，segment上的消息會被flush到磁盤，只有flush到磁盤上的消息訂閱者才能訂閱到，segment達到一定的大小后將不會再往該segment寫數據，broker會創(chuàng)建新的segment。顯式分布式，即所有的producer、broker和consumer都會有多個，均為分布式的。Producer和broker之間沒有負載均衡機制。broker和consumer之間利用zookeeper進行負載均衡。所有broker和consumer都會在zookeeper中進行注冊，且zookeeper會保存他們的一些元數據信息。如果某個broker和consumer發(fā)生了變化，所有其他的broker和consumer都會得到通知。Kafka設計原理實現(xiàn)kafka以topic來進行消息23Kafka的分布式實現(xiàn)一個Topic的多個partitions,被分布在kafka集群中的多個server上;每個server(kafka實例)負責partitions中消息的讀寫操作;此外kafka還可以配置partitions需要備份的個數(replicas),每個partition將會被備份到多臺機器上,以提高可用性;基于replicated方案,那么就意味著需要對多個備份進行調度;每個partition都有一個server為"leader";leader負責所有的讀寫操作,如果leader失效,那么將會有其他follower來接管(成為新的leader);follower只是單調的和leader跟進,同步消息即可..由此可見作為leader的server承載了全部的請求壓力,因此從集群的整體考慮,有多少個partitions就意味著有多少個"leader";kafka會將"leader"均衡的分散在每個實例上,來確保整體的性能穩(wěn)定.Kafka的分布式實現(xiàn)一個Topic的多個part24Kafka數據持久化數據持久化：發(fā)現(xiàn)線性的訪問磁盤，很多時候比隨機的內存訪問快得多傳統(tǒng)的使用內存做為磁盤的緩存Kafka直接將數據寫入到日志文件中日志數據持久化特性：寫操作：通過將數據追加到文件中實現(xiàn)讀操作：讀的時候從文件中讀就好了對比JVM特性：Java對象占用空間是非常大的，差不多是要存儲的數據的兩倍甚至更高隨著堆中數據量的增加，垃圾回收回變的越來越困難優(yōu)勢：讀操作不會阻塞寫操作和其他操作，數據大小不對性能產生影響； 沒有容量限制（相對于內存來說）的硬盤空間建立消息系統(tǒng)； 線性訪問磁盤，速度快，可以保存任意一段時間！Kafka數據持久化數據持久化：25Kafka安裝下載解壓tar-xzfkafka_2.11-.tgz啟動服務首先啟動zookeeper服務bin/zookeeper-server-start.shconfig/perties啟動Kafkabin/kafka-server-start.shconfig/perties創(chuàng)建topic創(chuàng)建一個"test"的topic，一個分區(qū)一個副本bin/kafka-topics.sh--create--zookeeperlocalhost:2181--replication-factor1--partitions1--topictest查看主題bin/kafka-topics.sh--list--zookeeperlocalhost:2181查看主題詳情bin/kafka-topics.sh--describe--zookeeperlocalhost:2181--topictest刪除主題bin/kafka-topics.sh--zookeeperlocalhost:2181--delete--topictestKafka安裝下載26Kafka客戶端操作創(chuàng)建生產者producerbin/kafka-console-producer.sh--broker-listlocalhost:9092--topictest創(chuàng)建消費者consumerbin/kafka-console-consumer.sh--zookeeperlocalhost:2181--topictest--from-beginning參數使用幫組信息查看：生產者參數查看：bin/kafka-console-producer.sh消費者參數查看：bin/kafka-console-consumer.shKafka客戶端操作創(chuàng)建生產者producer27Kafka多broker部署修改config/pertiesbroker.id=0port=9020log.dirs=/tmp/kafka0-logs復制perties生成pertiesbroker.id=1 #id不能一樣port=9040 #port不能一樣log.dirs=/tmp/kafka1-logs啟動多個brokerbin/kafka-server-start.shconfig/perties&bin/kafka-server-start.shconfig/perties&創(chuàng)建主題bin/kafka-topics.sh--create--zookeeperlocalhost:2181--replication-factor3--partitions1--topictestKafka多broker部署修改config/service28kafka集群安裝安裝zk集群修改配置文件broker.id：唯一，填數字：唯一，填服務器zookeeper.connect=34:2181,32:2181,33:2181kafka集群安裝安裝zk集群29Kafka的核心配置perties配置詳情見注釋 broker.id=0work.threads=2num.io.threads=8socket.send.buffer.bytes=1048576socket.receive.buffer.bytes=1048576socket.request.max.bytes=104857600log.dirs=/tmp/kafka-logsnum.partitions=2log.retention.hours=168log.segment.bytes=536870912erval.ms=60000log.cleaner.enable=falsezookeeper.connect=localhost:2181zookeeper.connection.timeout.ms=1000000Kafka的核心配置perties30Kafka的一致性MQ要實現(xiàn)從producer到consumer之間的可靠的消息傳送和分發(fā)。傳統(tǒng)的MQ系統(tǒng)通常都是通過broker和consumer間的確認（ack）機制實現(xiàn)的，并在broker保存消息分發(fā)的狀態(tài)。即使這樣一致性也是很難保證的（當然kafka也支持ack）。kafka保證一致性的做法是由consumer自己保存狀態(tài)，也不要任何確認。這樣雖然consumer負擔更重，但其實更靈活了。因為不管consumer上任何原因導致需要重新處理消息，都可以再次從broker獲得。

Kafka的一致性MQ要實現(xiàn)從producer到consum31Kafka的高可用性Kafaka可以將log文件復制到其他topic的分隔點(可以看成是server)。當一個server在集群中fails，可以允許自動的failover到其他的復制的server，所以消息可以繼續(xù)存在在這種情況下。Kafka的高可用性Kafaka可以將log文件復制到其他t32Kafka的負載均衡Producer和broker之間沒有負載均衡機制。

負載均衡可以分為兩個部分：producer發(fā)消息的負載均衡和consumer讀消息的負載均衡。producer有一個到當前所有broker的連接池，當一個消息需要發(fā)送時，需要決定發(fā)到哪個broker（即partition）。consumer讀取消息時，除了考慮當前的broker情況外，還要考慮其他consumer的情況，才能決定從哪個partition讀取消息。多個partition需要選取出leadpartition，leadpartition負責讀寫，broker和consumer之間利用zookeeper進行負載均衡。所有broker和consumer都會在zookeeper中進行注冊，且zookeeper會保存他們的一些元數據信息。如果某個broker和consumer發(fā)生了變化，所有其他的broker和consumer都會得到

通知。Kafka的負載均衡Producer和broker之間沒有負33Kafka可擴展性當需要增加broker結點時，新增的broker會向zookeeper注冊，而producer及consumer會根據注冊在zookeeper上的watcher感知這些變化，并及時作出調整，這樣就保證了添加或去除broker時，各broker間仍能自動實現(xiàn)負載均衡。Kafka可擴展性當需要增加broker結點時，新增的34Kafka的Zookeeper協(xié)調控制1.管理broker與consumer的動態(tài)加入與離開。2.觸發(fā)負載均衡，當broker或consumer加入或離開時會觸發(fā)負載均衡算法，使得一個consumergroup內的多個consumer的訂閱負載平衡。3.維護消費關系及每個partion的消費信息。Zookeeper上的細節(jié)：1.每個broker啟動后會在zookeeper上注冊一個臨時的brokerregistry，包含broker的ip地址和端口號，所存儲的topics和partitions信息。2.每個consumer啟動后會在zookeeper上注冊一個臨時的consumerregistry：包含consumer所屬的consumergroup以及訂閱的topics。3.每個consumergroup關

聯(lián)一個臨時的ownerregistry和一個持久的offsetregistry。對于被訂閱的每個partition包含一個ownerregistry，內容為訂閱這個partition的consumerid；同時包含一個offsetregistry，內容為上一次訂閱的offset。Kafka的Zookeeper協(xié)調控制1.管理broker35寫在最后成功的基礎在于好的學習習慣Thefoundationofsuccessliesingoodhabits36寫在最后成功的基礎在于好的學習習慣36謝謝聆聽·學習就是為了達到一定目的而努力去干,是為一個目標去戰(zhàn)勝各種困難的過程,這個過程會充滿壓力、痛苦和挫折LearningIsToAchieveACertainGoalAndWorkHard,IsAProcessToOvercomeVariousDifficultiesForAGoal謝謝聆聽LearningIsToAchieveAC37Kafka介紹研發(fā)二部Kafka介紹38內容kafka是什么kafka體系結構kafka設計理念簡介kafka安裝部署kafkaproducer和consumer開發(fā)內容kafka是什么39Kafka關鍵詞分布式發(fā)布-訂閱消息系統(tǒng)LinkedIn公司開發(fā)Scala語言分布式的，可劃分的，多訂閱者冗余備份持久性重復消費Kafka關鍵詞分布式發(fā)布-訂閱消息系統(tǒng)40Kafka關鍵特性同時為發(fā)布和訂閱提供高吞吐量。據了解，Kafka每秒可以生產約25萬消息（50MB），每秒處理55萬消息（110MB）?？蛇M行持久化操作。將消息持久化到磁盤，因此可用于批量消費，例如ETL，以及實時應用程序。通過將數據持久化到硬盤以及replication防止數據丟失。分布式系統(tǒng)，易于向外擴展。所有的producer、broker和consumer都會有多個，均為分布式的。無需停機即可擴展機器。消息被處理的狀態(tài)是在consumer端維護，而不是由server端維護。當失敗時能自動平衡。支持online和offline的場景。Kafka關鍵特性同時為發(fā)布和訂閱提供高吞吐量。據了解，Ka41Kafka的兩大法寶數據文件的分段：Kafka解決查詢效率的手段之一是將數據文件分段；為數據文件建索引：為了進一步提高查找的效率，Kafka為每個分段后的數據文件建立了索引文件，文件名與數據文件的名字是一樣的，只是文件擴展名為.index。索引文件中包含若干個索引條目，每個條目表示數據文件中一條Message的索引。索引包含兩個部分（均為4個字節(jié)的數字），分別為相對offset和position。索引優(yōu)化：稀疏存儲，每隔一定字節(jié)的數據建立一條索引。Kafka的兩大法寶數據文件的分段：為了進一步提高查找的效率42消息隊列分類點對點:消息生產者生產消息發(fā)送到queue中，然后消息消費者從queue中取出并且消費消息。注意：消息被消費以后，queue中不再有存儲，所以消息消費者不可能消費到已經被消費的消息。Queue支持存在多個消費者，但是對一個消息而言，只會有一個消費者可以消費。發(fā)布/訂閱:消息生產者（發(fā)布）將消息發(fā)布到topic中，同時有多個消息消費者（訂閱）消費該消息。和點對點方式不同，發(fā)布到topic的消息會被所有訂閱者消費。消息隊列分類點對點:43消息隊列MQ對比RabbitMQ：支持的協(xié)議多，非常重量級消息隊列，對路由(Routing)，負載均衡(Loadbalance)或者數據持久化都有很好的支持。ZeroMQ：號稱最快的消息隊列系統(tǒng)，尤其針對大吞吐量的需求場景，擅長的高級/復雜的隊列，但是技術也復雜，并且只提供非持久性的隊列。ActiveMQ：Apache下的一個子項，類似ZeroMQ，能夠以代理人和點對點的技術實現(xiàn)隊列。Redis：是一個key-Value的NOSql數據庫，但也支持MQ功能，數據量較小，性能優(yōu)于RabbitMQ，數據超過10K就慢的無法忍受Jafka，基于Kafka孵化，非Apache官方孵化，活躍度也不是很高消息隊列MQ對比RabbitMQ：支持的協(xié)議多，非常重量級消44Kafka架構Kafka架構45Kafka的基本概念Producers：消息和數據生產者，向Kafka的一個topic發(fā)布消息的過程叫做producers。Consumers：消息和數據消費者，訂閱topics并處理其發(fā)布的消息的過程叫做consumers。Broker：緩存代理，Kafka集群中的一臺或多臺服務器統(tǒng)稱為broker。Topic：特指Kafka處理的消息源（feedsofmessages）的不同分類。Partition：Topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的隊列。partition中的每條消息都會被分配一個有序的id（offset）。Message：消息，是通信的基本單位，每個producer可以向一個topic（主題）發(fā)布一些消息。Kafka的基本概念Producers：消息和數據生產者，向46Kafka的ProducersProducer將消息發(fā)布到指定的Topic中,同時Producer也能決定將此消息歸屬于哪個partition;比如基于"round-robin"方式或者通過其他的一些算法等.消息和數據生產者，向Kafka的一個topic發(fā)布消息的過程叫做producers。異步發(fā)送批量發(fā)送可以很有效的提高發(fā)送效率。Kafkaproducer的異步發(fā)送模式允許進行批量發(fā)送，先將消息緩存在內存中，然后一次請求批量發(fā)送出去。Kafka的ProducersProducer將消息發(fā)布到指47Kafka的broker1.Broker沒有副本機制，一旦broker宕機，該broker的消息將都不可用。2.Broker：緩存代理，Kafka集群中的一臺或多臺服務器統(tǒng)稱為broker。broker會將消息暫時buffer起來,當消息的個數(或尺寸)達到一定閥值時,再flush到磁盤3.Broker不保存訂閱者的狀態(tài)，由訂閱者自己保存。4.無狀態(tài)導致消息的刪除成為難題（可能刪除的消息正在被訂閱），kafka采用基于時間的SLA(服務水平保證)，消息保存一定時間（通常為7天）后會被刪除。5.消息訂閱者可以rewindback到任意位置重新進行消費，當訂閱者故障時，可以選擇最小的offset(id)進行重新讀取消費消息。Kafka的broker1.Broker沒有副本機制，一48Kafka的Consumers消息和數據消費者，訂閱topics并處理其發(fā)布的消息的過程叫做consumers。本質上kafka只支持Topic.每個consumer屬于一個consumergroup;反過來說,每個group中可以有多個consumer.發(fā)送到Topic的消息,只會被訂閱此Topic的每個group中的一個consumer消費.可以認為一個group是一個"訂閱"者,一個Topic中的每個partions,只會被一個"訂閱者"中的一個consumer消費,不過一個consumer可以消費多個partitions中的消息.kafka只能保證一個partition中的消息被某個consumer消費時,消息是順序的.事實上,從Topic角度來說,消息仍不是有序的.注：kafka的設計原理決定,對于一個topic,同一個group中不能有多于partitions個數的consumer同時消費,否則將意味著某些consumer將無法得到消息.一個partition中的消息只會被group中的一個consumer消費;每個group中consumer消息消費互相獨立;Kafka的Consumers消息和數據消費者，訂閱top49Kafka的Topics/Log一個Topic可以認為是一類消息，每個topic將被分成多partition(區(qū)),每個partition在存儲層面是appendlog文件。任何發(fā)布到此partition的消息都會被直接追加到log文件的尾部，每條消息在文件中的位置稱為offset（偏移量）,partition是以文件的形式存儲在文件系統(tǒng)中。Logs文件根據broker中的配置要求,保留一定時間后刪除來釋放磁盤空間。Partition：

Topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的隊列。

partition中的每條消息都會被分配一個有序的id（offset）。Kafka的Topics/Log一個Topic可以認為是一類50Kafka的partitions設計目的：kafka基于文件存儲.通過分區(qū),可以將日志內容分散到多個server上,來避免文件尺寸達到單機磁盤的上限,每個partiton都會被當前server(kafka實例)保存;可以將一個topic切分多任意多個partitions,來消息保存/消費的效率.越多的partitions意味著可以容納更多的consumer,有效提升并發(fā)消費的能力.Kafka的partitions設計目的：51Kafka的MessageMessage消息：是通信的基本單位，每個producer可以向一個topic（主題）發(fā)布一些消息。Kafka中的Message是以topic為基本單位組織的，不同的topic之間是相互獨立的。每個topic又可以分成幾個不同的partition(每個topic有幾個partition是在創(chuàng)建topic時指定的)，每個partition存儲一部分Message。partition中的每條Message包含了以下三個屬性：offset 對應類型：longMessageSize 對應類型：int32data 是message的具體內容Kafka的MessageMessage消息：是通信的基本單52Kafka的MessageKafka的Message53Kafka的offset每條消息在文件中的位置稱為offset（偏移量）。offset為一個long型數字，它是唯一標記一條消息。它唯一的標記一條消息。kafka并沒有提供其他額外的索引機制來存儲offset，因為在kafka中幾

乎不允許對消息進行“隨機讀寫”。Partition中的每條Message由offset來表示它在這個partition中的偏移量，這個offset不是該Message在partition數據文件中的實際存儲位置，而是邏輯上一個值，它唯一確定了partition中的一條Message。因此，可以認為offset是partition中Message的id。怎樣記錄每個consumer處理的信息的狀態(tài)？在Kafka中僅保存了每個consumer已經處理數據的offset。這樣有兩個好處：1）保

存的數據量少

2）當consumer出錯時，重新啟動consumer處理數據時，只需從最近的offset開始處理數據即可。Kafka的offset每條消息在文件中的位置稱為offs54Kafka的消息處理機制1.發(fā)送到partitions中的消息將會按照它接收的順序追加到日志中2.對于消費者而言,它們消費消息的順序和日志中消息順序一致.3.如果Topic的"replicationfactor"為N,那么允許N-1個kafka實例失效.4.kafka對消息的重復、丟失、錯誤以及順序型沒有嚴格的要求。5.kafka提供at-least-oncedelivery,即當consumer宕機后，有些消息可能會被重復delivery。6.因每個partition只會被consumergroup內的一個consumer消費，故kafka保證每個partition內的消息會被順序的訂閱。7.Kafka為每條消息為每條消息計算CRC校驗，用于錯誤檢測，crc校驗不通過的消息會直接被丟棄掉。ack校驗，當消費者消費成功，返回ack信息！Kafka的消息處理機制1.發(fā)送到partitions55數據傳輸的事務定義atmostonce:最多一次,這個和JMS中"非持久化"消息類似.發(fā)送一次,無論成敗,將不會重發(fā).atleastonce:消息至少發(fā)送一次,如果消息未能接受成功,可能會重發(fā),直到接收成功.exactlyonce:消息只會發(fā)送一次.atmostonce:消費者fetch消息,然后保存offset,然后處理消息;當client保存offset之后,但是在消息處理過程中出現(xiàn)了異常,導致部分消息未能繼續(xù)處理.那么此后"未處理"的消息將不能被fetch到,這就是"atmostonce".atleastonce:消費者fetch消息,然后處理消息,然后保存offset.如果消息處理成功之后,但是在保存offset階段zookeeper異常導致保存操作未能執(zhí)行成功,這就導致接下來再次fetch時可能獲得上次已經處理過的消息,這就是"atleastonce"，原因offset沒有及時的提交給zookeeper，zookeeper恢復正常還是之前offset狀態(tài).exactlyonce:kafka中并沒有嚴格的去實現(xiàn)(基于2階段提交,事務),我們認為這種策略在kafka中是沒有必要的.注：通常情況下"at-least-once"是我們首選.(相比atmostonce而言,重復接收數據總比丟失數據要好).數據傳輸的事務定義atmostonce:最多一次,這個56Kafka的儲存策略1.kafka以topic來進行消息管理，每個topic包含多個part（ition），每個part對應一個邏輯log，有多個segment組成。2.每個segment中存儲多條消息（見下圖），消息id由其邏輯位置決定，即從消息id可直接定位到消息的存儲位置，避免id到位置的額外映射。3.broker收到發(fā)布消息往對應partition的最后一個segment上添加該消息Kafka的儲存策略1.kafka以topic來進行消息57Kafka的儲存策略 4.每個part在內存中對應一個index，記錄每個segment中的第一條消息偏移。5.發(fā)布者發(fā)到某個topic的消息會被均勻的分布到多個part上（隨機或根據用戶指定的回調函數進行分布），broker收到發(fā)布消息往對應part的最后一個segment上添加該消息，當某個segment上的消息條數達到配置值或消息發(fā)布時間超過閾值時，segment上的消息會被flush到磁盤，只有flush到磁盤上的消息訂閱者才能訂閱到，segment達到一定的大小后將不會再往該segment寫數據，broker會創(chuàng)建新的segment。Kafka的儲存策略 4.每個part在內存中對應一個i58Kafka的消息發(fā)送的流程由于kafkabroker會持久化數據，broker沒有內存壓力，因此，consumer非常適合采取pull的方式消費數據Producer向Kafka（push）推數據consumer從kafka拉（pull）數據。Kafka的消息發(fā)送的流程由于kafkabroker會59Kafka設計原理實現(xiàn)kafka以topic來進行消息管理，發(fā)布者發(fā)到某個topic的消息會被均勻的分布到多個partition上每個topic包含多個partition，每個part對應一個邏輯log，有多個segment組成。每個segment中存儲多條消息，消息id由其邏輯位置決定，即從消息id可直接定位到消息的存儲位置，避免id到位置的額外映射。每個part在內存中對應一個index，記錄每個segment中的第一條消息偏移。當某個segment上的消息條數達到配置值或消息發(fā)布時間超過閾值時，segment上的消息會被flush到磁盤，只有flush到磁盤上的消息訂閱者才能訂閱到，segment達到一定的大小后將不會再往該segment寫數據，broker會創(chuàng)建新的segment。顯式分布式，即所有的producer、broker和consumer都會有多個，均為分布式的。Producer和broker之間沒有負載均衡機制。broker和consumer之間利用zookeeper進行負載均衡。所有broker和consumer都會在zookeeper中進行注冊，且zookeeper會保存他們的一些元數據信息。如果某個broker和consumer發(fā)生了變化，所有其他的broker和consumer都會得到通知。Kafka設計原理實現(xiàn)kafka以topic來進行消息60Kafka的分布式實現(xiàn)一個Topic的多個partitions,被分布在kafka集群中的多個server上;每個server(kafka實例)負責partitions中消息的讀寫操作;此外kafka還可以配置partitions需要備份的個數(replicas),每個partition將會被備份到多臺機器上,以提高可用性;基于replicated方案,那么就意味著需要對多個備份進行調度;每個partition都有一個server為"leader";leader負責所有的讀寫操作,如果leader失效,那么將會有其他follower來接管(成為新的leader);follower只是單調的和leader跟進,同步消息即可..由此可見作為leader的server承載了全部的請求壓力,因此從集群的整體考慮,有多少個partitions就意味著有多少個"leader";kafka會將"leader"均衡的分散在每個實例上,來確保整體的性能穩(wěn)定.Kafka的分布式實現(xiàn)一個Topic的多個part61Kafka數據持久化數據持久化：發(fā)現(xiàn)線性的訪問磁盤，很多時候比隨機的內存訪問快得多傳統(tǒng)的使用內存做為磁盤的緩存Kafka直接將數據寫入到日志文件中日志數據持久化特性：寫操作：通過將數據追加到文件中實現(xiàn)讀操作：讀的時候從文件中讀就好了對比JVM特性：Java對象占用空間是非常大的，差不多是要存儲的數據的兩倍甚至更高隨著堆中數據量的增加，垃圾回收回變的越來越困難優(yōu)勢：讀操作不會阻塞寫操作和其他操作，數據大小不對性能產生影響； 沒有容量限制（相對于內存來說）的硬盤空間建立消息系統(tǒng)； 線性訪問磁盤，速度快，可以保存任意一段時間！Kafka數據持久化數據持久化：62Kafka安裝下載解壓tar-xzfkafka_2.11-.tgz啟動服務首先啟動zookeeper服務bin/zookeeper-server-start.shconfig/perties啟動Kafkabin/kafka-server-start.shconfig/perties創(chuàng)建topic創(chuàng)建一個"test"的topic，一個分區(qū)一個副本bin/kafka-topics.sh--create--zookeeperlocalhost:2181--replication-factor1--partitions1--topictest查看主題bin/kafka-topics.sh--list--zookeeperlocalhost:2181查看主題詳情bin/kafka-topics.sh--describe--zookeeperlocalhost:2181--topictest刪除主題bin/kafka-topics.sh--zookeeperlocalhost:2181--delete--topictestKafka安裝下載63Kafka客戶端操作創(chuàng)建生產者producerbin/kafka-console-producer.sh--broker-listlocalhost:9092--topictest創(chuàng)建消費者consumerbin/kafka-console-consumer.sh--zookeeperlocalhost:2181--topictest--from-beginning參數使用幫組信息查看：生產者參數查看：bin/kafka-console-producer.sh消費者參數查看：bin/kafka-console-consumer.shKafka客戶端操作創(chuàng)建生產者producer64Kafka多broker部署修改config/pertiesbroker.id=0port=9020log.dirs=/tmp/kafka0-logs復制perties生成pertiesbroker.id=1 #id不能一樣port=9040 #port不能一樣log.dirs=/tmp/kafka1-logs啟動多個brokerbin/kafka-server-start.shconfig/perties&bin/kafka-server-start.shconfig/perties&創(chuàng)建主題bin/kafka-topics.sh--create--zookeeperlocalhost:2181--replication-factor3--partitions1--topictestKafka多broker部署修改config/service65kafka集群安裝安裝zk集群修改配置文件broker.id：唯一，填數字：唯一，填服務器zookeeper.connect=34:2181,32:2181,33:2181kafka集群安裝安裝zk集群66Kafka的核心配置perties配置詳情見注釋 broker.id=0work.threads=2num.io.threads=8socket.send.buffer.bytes=1048576socket.receive.bu