背景
????????? Kafka是分布式發(fā)布-訂閱消息系統(tǒng)打瘪，它最初是由LinkedIn公司開發(fā)的友鼻，之后成為Apache項目的一部分，Kafka是一個分布式闺骚，可劃分的彩扔，冗余備份的持久性的日志服務(wù)，它主要用于處理活躍的流式數(shù)據(jù)
作用
?????? kafka的作用類似于緩存僻爽，即活躍的數(shù)據(jù)和離線處理系統(tǒng)之間的緩存
架構(gòu)
? 如圖所示:
?????
角色描述
??????? Topic:指kafka處理消息源的不同分類虫碉，或稱為一個主題，可以理解為MQ(消息隊列)的一個名字
??????? Broker:緩存代理胸梆，kafka集群中的一臺或多臺服務(wù)器統(tǒng)稱為broker,一個broker可以容納多個topic
??????? Producer:消息的生產(chǎn)者,就是向kafka broker發(fā)消息的客戶端(push)
?????? Consumer:消息消費者敦捧，就是向kafak broker取消息的客戶端(通過pull進行取)
???? ? Message:消息，是通信的基本單位乳绕，每個producer可以向topic(主題)發(fā)布一些消息
? ? ? Offset(起始偏移量):kafka的存儲文件都是按照offset.kafka來命名,用offset做名字的好處是方便查找绞惦。例如你想找位于2049的位置，只要找到2048.kafka的文件即可洋措。當(dāng)然the first offset就是00000000000.kafka
????? Partition:Topic物理上的分組济蝉，為了實現(xiàn)擴展性，一個非常大的topic可以分布到多個broker(服務(wù)器)上菠发，一個topic可以分為多個partition,每個partition是一個有序的隊列王滤。partition中的每條消息都會被分配一個有序的Id(offset).kafka只保證一個partition中的順序?qū)⑾l(fā)送給consumer，不保證一個topic的整體(多個partition間)的順序滓鸠，也就是說雁乡，一個topic在集群中可以有多個partition,那么分區(qū)的策略是什么？(消息發(fā)送到哪個分區(qū)上糜俗，有兩種策略踱稍，一是采用Key Hash算法曲饱，二是采用Round Robin算法)(兩種算法請自行Google)
消息發(fā)送流程
? 如圖所示：
???? 1.Producer根據(jù)指定的partition方法(round-robin,hash等)，將消息發(fā)布到指定的topic的partition里面
???? 2.Kafka集群接收到Producer發(fā)過來的消息后珠月，將其持久化到硬盤扩淀，并保留消息指定時長(可配置)，而不關(guān)注消息是否被消費
???? 3.Consumer從Kafka集群pull數(shù)據(jù)啤挎，并控制獲取消息的offset
消息系統(tǒng)
??? 消息系統(tǒng)分為兩種:
??????????????? 1.消息廣播
??????????????????????????? 廣播是把消息發(fā)送給所有的consumer
??????????????? 2.訂閱-發(fā)布(消息單播)
?????????????????????????? 訂閱發(fā)布是把消息發(fā)送給訂閱者
??????? kafka是通過Consumer Grouping(CG)來實現(xiàn)這兩種機制：
?????????????????????? 一個topic可以有多個CG,topic的消息會復(fù)制(只是概念上的復(fù)制)到所有的CG,但每個CG只是把消息發(fā)送給該CG中的一個consumer(這是實現(xiàn)一個Topic上多Consumer的關(guān)鍵點)：為一個topic定義一個CG驻谆，一個CG有多個consumer，用CG還可以將consumer進行自由的分組而不需要多次發(fā)送消息到不同的topic
??? 如果要實現(xiàn)廣播:只要每個consumer有一個獨立 的CG即可
?? 如果要實現(xiàn)單播:只要所有的consumer在同一個CG中
?? 典型的應(yīng)用情景:
?????? 多個consumer來讀取一個Topic(理想情況下是一個consumer讀取Topic的一個partition),那么可以讓這些Consumer屬于同一個CG即可實現(xiàn)消息的多Consumer并行處理庆聘，原理是kafka將一個消息發(fā)布出去胜臊，CG中的Consumers可以通過Round Robin的方式進行消費(consumers之間的負載均衡由zookeeper來實現(xiàn))
???????????????
負載均衡
? ? ?? Kafka將元數(shù)據(jù)存儲在zookeeper中，但Topic本身的數(shù)據(jù)是不會發(fā)送到zookeeper中的
?????? Kafka使用zookeeper來實現(xiàn)動態(tài)的集群擴展伙判，不需要更改客戶端(producer和consumer)的配置象对，broker會在zookeeper注冊并保持相關(guān)的元數(shù)據(jù)(topic,partition信息等)更新
?????? 客戶端會在zookeeper上注冊相關(guān)的watcher,一旦zookeeper發(fā)生變化，客戶端能及時感知并作出相應(yīng)的調(diào)整澳腹，這樣就保證了添加或去除Broker時织盼，各broker間仍能自動實現(xiàn)負載均衡，這里的客戶端指的是Kafka的消息生產(chǎn)端和消息消費端
?????? Broker端使用zookeeper來注冊broker信息酱塔，以及監(jiān)測partition leader的存活性
?????? Consumer端使用zookeeper用來注冊consumer信息，其中包括consumer消費的partition列表等危虱，同時也用來發(fā)現(xiàn)broker列表羊娃，并和partition leader建立socket連接，并獲取消息
?????? Zookeeper和Producer沒有建立關(guān)系埃跷，只和Brokers,Consumers建立關(guān)系以實現(xiàn)負載均衡蕊玷，即同一個Consumer Group中的Consumers可以實現(xiàn)負載均衡
???? 消費者分組的意義：
????????????? 組內(nèi)的消費者可以共同處理一個topic的所有消息，而且不會產(chǎn)生沖突弥雹，這種協(xié)調(diào)是通過借助zookeeper來實現(xiàn)的垃帅，而且這個協(xié)調(diào)邏輯已經(jīng)被封裝在kafka提供的api中
設(shè)計要點
? ? 1、直接使用linux 文件系統(tǒng)的cache剪勿，來高效緩存數(shù)據(jù)贸诚。
??? 2、采用linux Zero-Copy提高發(fā)送性能厕吉。傳統(tǒng)的數(shù)據(jù)發(fā)送需要發(fā)送4次上下文切換酱固，采用sendfile系統(tǒng)調(diào)用之后，數(shù)據(jù)直接在內(nèi)核態(tài)交換头朱，系統(tǒng)上下文切換減少為2次运悲。根據(jù)測試結(jié)果，可以提高60%的數(shù)據(jù)發(fā)送性能项钮。Zero-Copy詳細的技術(shù)細節(jié)可以參考：https://www.ibm.com/developerworks/linux/library/j-zerocopy/
??? 3班眯、數(shù)據(jù)在磁盤上存取代價為O(1)希停。kafka以topic來進行消息管理，每個topic包含多個part（ition）署隘，每個part對應(yīng)一個邏輯log脖苏，有多個segment組成。每個segment中存儲多條消息（見下圖）定踱，消息id由其邏輯位置決定棍潘，即從消息id可直接定位到消息的存儲位置，避免id到位置的額外映射崖媚。每個part在內(nèi)存中對應(yīng)一個index亦歉，記錄每個segment中的第一條消息偏移。發(fā)布者發(fā)到某個topic的消息會被均勻的分布到多個part上（隨機或根據(jù)用戶指定的回調(diào)函數(shù)進行分布）畅哑，broker收到發(fā)布消息往對應(yīng)part的最后一個segment上添加該消息肴楷，當(dāng)某個segment上的消息條數(shù)達到配置值或消息發(fā)布時間超過閾值時，segment上的消息會被flush到磁盤荠呐，只有flush到磁盤上的消息訂閱者才能訂閱到赛蔫，segment達到一定的大小后將不會再往該segment寫數(shù)據(jù)，broker會創(chuàng)建新的segment泥张。
??? 4呵恢、顯式分布式，即所有的producer媚创、broker和consumer都會有多個渗钉，均為分布式的。Producer和broker之間沒有負載均衡機制钞钙。broker和consumer之間利用zookeeper進行負載均衡鳄橘。所有broker和consumer都會在zookeeper中進行注冊，且zookeeper會保存他們的一些元數(shù)據(jù)信息芒炼。如果某個broker和consumer發(fā)生了變化瘫怜，所有其他的broker和consumer都會得到通知。
應(yīng)用場景
? ? 1.消息隊列
? ? ? ? ? ? 比起大多數(shù)的消息系統(tǒng)來說本刽，Kafka有更好的吞吐量鲸湃，內(nèi)置的分區(qū)，冗余及容錯性盅安，這讓Kafka成為了一個很好的大規(guī)模消息處理應(yīng)用的解決方案唤锉。消息系統(tǒng)一般吞吐量相對較低，但是需要更小的端到端延時别瞭，并嘗嘗依賴于Kafka提供的強大的持久性保障窿祥。在這個領(lǐng)域，Kafka足以媲美傳統(tǒng)消息系統(tǒng)蝙寨，如ActiveMR或RabbitMQ
??? 2.行為跟蹤
? ? ? ? ? ? ? Kafka的另一個應(yīng)用場景是跟蹤用戶瀏覽頁面晒衩、搜索及其他行為嗤瞎，以發(fā)布-訂閱的模式實時記錄到對應(yīng)的topic里。那么這些結(jié)果被訂閱者拿到后听系，就可以做進一步的實時處理贝奇，或?qū)崟r監(jiān)控，或放到hadoop/離線數(shù)據(jù)倉庫里處理靠胜。
??? 3.元信息監(jiān)控
? ? ? ? ? ? 作為操作記錄的監(jiān)控模塊來使用掉瞳，即匯集記錄一些操作信息，可以理解為運維性質(zhì)的數(shù)據(jù)監(jiān)控吧浪漠。
??? 4.日志收集
? ? ? ? ? ? 日志收集方面陕习，其實開源產(chǎn)品有很多，包括Scribe址愿、Apache Flume该镣。很多人使用Kafka代替日志聚合（log aggregation）。日志聚合一般來說是從服務(wù)器上收集日志文件响谓，然后放到一個集中的位置（文件服務(wù)器或HDFS）進行處理损合。然而Kafka忽略掉文件的細節(jié)，將其更清晰地抽象成一個個日志或事件的消息流娘纷。這就讓Kafka處理過程延遲更低嫁审，更容易支持多數(shù)據(jù)源和分布式數(shù)據(jù)處理。比起以日志為中心的系統(tǒng)比如Scribe或者Flume來說失驶，Kafka提供同樣高效的性能和因為復(fù)制導(dǎo)致的更高的耐用性保證土居，以及更低的端到端延遲。
??? 5.流處理
? ? ? ? ? 這個場景可能比較多嬉探，也很好理解。保存收集流數(shù)據(jù)棉圈，以提供之后對接的Storm或其他流式計算框架進行處理涩堤。很多用戶會將那些從原始topic來的數(shù)據(jù)進行階段性處理，匯總分瘾，擴充或者以其他的方式轉(zhuǎn)換到新的topic下再繼續(xù)后面的處理胎围。例如一個文章推薦的處理流程，可能是先從RSS數(shù)據(jù)源中抓取文章的內(nèi)容德召，然后將其丟入一個叫做“文章”的topic中白魂；后續(xù)操作可能是需要對這個內(nèi)容進行清理，比如回復(fù)正常數(shù)據(jù)或者刪除重復(fù)數(shù)據(jù)上岗，最后再將內(nèi)容匹配的結(jié)果返還給用戶福荸。這就在一個獨立的topic之外，產(chǎn)生了一系列的實時數(shù)據(jù)處理的流程肴掷。Strom和Samza是非常著名的實現(xiàn)這種類型數(shù)據(jù)轉(zhuǎn)換的框架敬锐。
??? 6.事件源
? ? ? ? ? 事件源是一種應(yīng)用程序設(shè)計的方式背传，該方式的狀態(tài)轉(zhuǎn)移被記錄為按時間順序排序的記錄序列。Kafka可以存儲大量的日志數(shù)據(jù)台夺，這使得它成為一個對這種方式的應(yīng)用來說絕佳的后臺径玖。比如動態(tài)匯總（News feed）。
??? 7.持久性日志（commit log）
? ? ? ? ? Kafka可以為一種外部的持久性日志的分布式系統(tǒng)提供服務(wù)颤介。這種日志可以在節(jié)點間備份數(shù)據(jù)梳星，并為故障節(jié)點數(shù)據(jù)回復(fù)提供一種重新同步的機制。Kafka中日志壓縮功能為這種用法提供了條件滚朵。在這種用法中冤灾，Kafka類似于Apache BookKeeper項目。
特點
? 1始绍、同時為發(fā)布和訂閱提供高吞吐量瞳购。據(jù)了解，Kafka每秒可以生產(chǎn)約25萬消息（50 MB）亏推，每秒處理55萬消息（110 MB）学赛。
2、可進行持久化操作吞杭。將消息持久化到磁盤盏浇，因此可用于批量消費，例如ETL芽狗，以及實時應(yīng)用程序绢掰。通過將數(shù)據(jù)持久化到硬盤以及replication防止數(shù)據(jù)丟失。
3童擎、分布式系統(tǒng)滴劲，易于向外擴展。所有的producer顾复、broker和consumer都會有多個班挖，均為分布式的。無需停機即可擴展機器芯砸。
4萧芙、消息被處理的狀態(tài)是在consumer端維護，而不是由server端維護假丧。當(dāng)失敗時能自動平衡双揪。
5、支持online和offline的場景
快速進入安裝部署以及API使用:Kafka介紹之安裝配置API?
