1.1? Kafka的特性:

- 高吞吐量垛叨、低延遲：kafka每秒可以處理幾十萬條消息伦糯，它的延遲最低只有幾毫秒，每個(gè)topic可以分多個(gè)partition, consumer group 對(duì)partition進(jìn)行consume操作嗽元。

- 可擴(kuò)展性：kafka集群支持熱擴(kuò)展

- 持久性敛纲、可靠性：消息被持久化到本地磁盤，并且支持?jǐn)?shù)據(jù)備份防止數(shù)據(jù)丟失

- 容錯(cuò)性：允許集群中節(jié)點(diǎn)失敿涟（若副本數(shù)量為n,則允許n-1個(gè)節(jié)點(diǎn)失斢傧琛）

- 高并發(fā)：支持?jǐn)?shù)千個(gè)客戶端同時(shí)讀寫

1.2? Kafka的使用場景：

- 日志收集：一個(gè)公司可以用Kafka可以收集各種服務(wù)的log，通過kafka以統(tǒng)一接口服務(wù)的方式開放給各種consumer佩谷，例如hadoop旁壮、Hbase、Solr等谐檀。

- 消息系統(tǒng)：解耦和生產(chǎn)者和消費(fèi)者抡谐、緩存消息等。

- 用戶活動(dòng)跟蹤：Kafka經(jīng)常被用來記錄web用戶或者app用戶的各種活動(dòng)桐猬，如瀏覽網(wǎng)頁麦撵、搜索、點(diǎn)擊等活動(dòng)溃肪，這些活動(dòng)信息被各個(gè)服務(wù)器發(fā)布到kafka的topic中免胃，然后訂閱者通過訂閱這些topic來做實(shí)時(shí)的監(jiān)控分析，或者裝載到hadoop乍惊、數(shù)據(jù)倉庫中做離線分析和挖掘杜秸。

- 運(yùn)營指標(biāo)：Kafka也經(jīng)常用來記錄運(yùn)營監(jiān)控?cái)?shù)據(jù)。包括收集各種分布式應(yīng)用的數(shù)據(jù)润绎，生產(chǎn)各種操作的集中反饋，比如報(bào)警和報(bào)告诞挨。

- 流式處理：比如spark streaming和storm

- 事件源

1.3? Kakfa的設(shè)計(jì)思想

- Kakfa Broker Leader的選舉：Kakfa Broker集群受Zookeeper管理莉撇。所有的Kafka Broker節(jié)點(diǎn)一起去Zookeeper上注冊一個(gè)臨時(shí)節(jié)點(diǎn)，因?yàn)橹挥幸粋€(gè)Kafka Broker會(huì)注冊成功惶傻，其他的都會(huì)失敗棍郎，所以這個(gè)成功在Zookeeper上注冊臨時(shí)節(jié)點(diǎn)的這個(gè)Kafka Broker會(huì)成為Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower银室。（這個(gè)過程叫Controller在ZooKeeper注冊Watch）涂佃。這個(gè)Controller會(huì)監(jiān)聽其他的Kafka Broker的所有信息励翼，如果這個(gè)kafka broker controller宕機(jī)了，在zookeeper上面的那個(gè)臨時(shí)節(jié)點(diǎn)就會(huì)消失辜荠，此時(shí)所有的kafka broker又會(huì)一起去Zookeeper上注冊一個(gè)臨時(shí)節(jié)點(diǎn)汽抚，因?yàn)橹挥幸粋€(gè)Kafka Broker會(huì)注冊成功，其他的都會(huì)失敗伯病，所以這個(gè)成功在Zookeeper上注冊臨時(shí)節(jié)點(diǎn)的這個(gè)Kafka Broker會(huì)成為Kafka Broker Controller造烁，其他的Kafka broker叫Kafka Broker follower。例如：一旦有一個(gè)broker宕機(jī)了午笛，這個(gè)kafka broker controller會(huì)讀取該宕機(jī)broker上所有的partition在zookeeper上的狀態(tài)惭蟋，并選取ISR列表中的一個(gè)replica作為partition leader（如果ISR列表中的replica全掛，選一個(gè)幸存的replica作為leader; 如果該partition的所有的replica都宕機(jī)了药磺，則將新的leader設(shè)置為-1告组，等待恢復(fù)，等待ISR中的任一個(gè)Replica“活”過來癌佩，并且選它作為Leader木缝；或選擇第一個(gè)“活”過來的Replica（不一定是ISR中的）作為Leader），這個(gè)broker宕機(jī)的事情驼卖，kafka controller也會(huì)通知zookeeper氨肌，zookeeper就會(huì)通知其他的kafka broker。

這里曾經(jīng)發(fā)生過一個(gè)bug酌畜，TalkingData使用Kafka0.8.1的時(shí)候怎囚，kafka controller在Zookeeper上注冊成功后，它和Zookeeper通信的timeout時(shí)間是6s桥胞，也就是如果kafka controller如果有6s中沒有和Zookeeper做心跳恳守，那么Zookeeper就認(rèn)為這個(gè)kafka controller已經(jīng)死了，就會(huì)在Zookeeper上把這個(gè)臨時(shí)節(jié)點(diǎn)刪掉贩虾，那么其他Kafka就會(huì)認(rèn)為controller已經(jīng)沒了催烘，就會(huì)再次搶著注冊臨時(shí)節(jié)點(diǎn)，注冊成功的那個(gè)kafka broker成為controller缎罢，然后伊群，之前的那個(gè)kafka controller就需要各種shut down去關(guān)閉各種節(jié)點(diǎn)和事件的監(jiān)聽。但是當(dāng)kafka的讀寫流量都非常巨大的時(shí)候策精，TalkingData的一個(gè)bug是舰始，由于網(wǎng)絡(luò)等原因，kafka controller和Zookeeper有6s中沒有通信咽袜，于是重新選舉出了一個(gè)新的kafka controller丸卷，但是原來的controller在shut down的時(shí)候總是不成功，這個(gè)時(shí)候producer進(jìn)來的message由于Kafka集群中存在兩個(gè)kafka controller而無法落地询刹。導(dǎo)致數(shù)據(jù)淤積谜嫉。

這里曾經(jīng)還有一個(gè)bug萎坷，TalkingData使用Kafka0.8.1的時(shí)候，當(dāng)ack=0的時(shí)候沐兰，表示producer發(fā)送出去message哆档，只要對(duì)應(yīng)的kafka broker topic partition leader接收到的這條message，producer就返回成功僧鲁，不管partition leader 是否真的成功把message真正存到kafka虐呻。當(dāng)ack=1的時(shí)候，表示producer發(fā)送出去message寞秃，同步的把message存到對(duì)應(yīng)topic的partition的leader上斟叼，然后producer就返回成功，partition leader異步的把message同步到其他partition replica上春寿。當(dāng)ack=all或-1朗涩，表示producer發(fā)送出去message，同步的把message存到對(duì)應(yīng)topic的partition的leader和對(duì)應(yīng)的replica上之后绑改，才返回成功谢床。但是如果某個(gè)kafka controller 切換的時(shí)候，會(huì)導(dǎo)致partition leader的切換（老的 kafka controller上面的partition leader會(huì)選舉到其他的kafka broker上）,但是這樣就會(huì)導(dǎo)致丟數(shù)據(jù)厘线。

-? Consumergroup：各個(gè)consumer（consumer 線程）可以組成一個(gè)組（Consumer group ）识腿，partition中的每個(gè)message只能被組（Consumer group ）中的一個(gè)consumer（consumer 線程）消費(fèi)，如果一個(gè)message可以被多個(gè)consumer（consumer 線程）消費(fèi)的話造壮，那么這些consumer必須在不同的組渡讼。Kafka不支持一個(gè)partition中的message由兩個(gè)或兩個(gè)以上的同一個(gè)consumer group下的consumer thread來處理，除非再啟動(dòng)一個(gè)新的consumer group耳璧。所以如果想同時(shí)對(duì)一個(gè)topic做消費(fèi)的話成箫，啟動(dòng)多個(gè)consumer group就可以了，但是要注意的是旨枯，這里的多個(gè)consumer的消費(fèi)都必須是順序讀取partition里面的message蹬昌，新啟動(dòng)的consumer默認(rèn)從partition隊(duì)列最頭端最新的地方開始阻塞的讀message。它不能像AMQ那樣可以多個(gè)BET作為consumer去互斥的（for update悲觀鎖）并發(fā)處理message攀隔，這是因?yàn)槎鄠€(gè)BET去消費(fèi)一個(gè)Queue中的數(shù)據(jù)的時(shí)候皂贩，由于要保證不能多個(gè)線程拿同一條message，所以就需要行級(jí)別悲觀所（for update）,這就導(dǎo)致了consume的性能下降昆汹，吞吐量不夠先紫。而kafka為了保證吞吐量，只允許同一個(gè)consumer group下的一個(gè)consumer線程去訪問一個(gè)partition筹煮。如果覺得效率不高的時(shí)候，可以加partition的數(shù)量來橫向擴(kuò)展居夹，那么再加新的consumer thread去消費(fèi)败潦。如果想多個(gè)不同的業(yè)務(wù)都需要這個(gè)topic的數(shù)據(jù)本冲，起多個(gè)consumer group就好了，大家都是順序的讀取message劫扒，offsite的值互不影響檬洞。這樣沒有鎖競爭，充分發(fā)揮了橫向的擴(kuò)展性沟饥，吞吐量極高添怔。這也就形成了分布式消費(fèi)的概念。

? ? 當(dāng)啟動(dòng)一個(gè)consumer group去消費(fèi)一個(gè)topic的時(shí)候贤旷，無論topic里面有多個(gè)少個(gè)partition广料，無論我們consumer group里面配置了多少個(gè)consumer thread，這個(gè)consumer group下面的所有consumer thread一定會(huì)消費(fèi)全部的partition幼驶；即便這個(gè)consumer group下只有一個(gè)consumer thread艾杏，那么這個(gè)consumer thread也會(huì)去消費(fèi)所有的partition。因此盅藻，最優(yōu)的設(shè)計(jì)就是购桑，consumer group下的consumer thread的數(shù)量等于partition數(shù)量，這樣效率是最高的氏淑。

? ? 同一partition的一條message只能被同一個(gè)Consumer Group內(nèi)的一個(gè)Consumer消費(fèi)勃蜘。不能夠一個(gè)consumer group的多個(gè)consumer同時(shí)消費(fèi)一個(gè)partition。

? ? 一個(gè)consumer group下假残，無論有多少個(gè)consumer缭贡，這個(gè)consumer group一定回去把這個(gè)topic下所有的partition都消費(fèi)了。當(dāng)consumer group里面的consumer數(shù)量小于這個(gè)topic下的partition數(shù)量的時(shí)候守问，如下圖groupA,groupB匀归，就會(huì)出現(xiàn)一個(gè)conusmer thread消費(fèi)多個(gè)partition的情況，總之是這個(gè)topic下的partition都會(huì)被消費(fèi)耗帕。如果consumer group里面的consumer數(shù)量等于這個(gè)topic下的partition數(shù)量的時(shí)候穆端，如下圖groupC，此時(shí)效率是最高的仿便，每個(gè)partition都有一個(gè)consumer thread去消費(fèi)体啰。當(dāng)consumer group里面的consumer數(shù)量大于這個(gè)topic下的partition數(shù)量的時(shí)候，如下圖GroupD嗽仪，就會(huì)有一個(gè)consumer thread空閑荒勇。因此，我們在設(shè)定consumer group的時(shí)候闻坚，只需要指明里面有幾個(gè)consumer數(shù)量即可沽翔，無需指定對(duì)應(yīng)的消費(fèi)partition序號(hào)，consumer會(huì)自動(dòng)進(jìn)行rebalance。

? ? 多個(gè)Consumer Group下的consumer可以消費(fèi)同一條message仅偎，但是這種消費(fèi)也是以o（1）的方式順序的讀取message去消費(fèi),跨蟹，所以一定會(huì)重復(fù)消費(fèi)這批message的，不能向AMQ那樣多個(gè)BET作為consumer消費(fèi)（對(duì)message加鎖橘沥，消費(fèi)的時(shí)候不能重復(fù)消費(fèi)message）

- Consumer Rebalance的觸發(fā)條件：（1）Consumer增加或刪除會(huì)觸發(fā) Consumer Group的Rebalance（2）Broker的增加或者減少都會(huì)觸發(fā) Consumer Rebalance

- Consumer： Consumer處理partition里面的message的時(shí)候是o（1）順序讀取的窗轩。所以必須維護(hù)著上一次讀到哪里的offsite信息。high level API,offset存于Zookeeper中座咆，low level API的offset由自己維護(hù)痢艺。一般來說都是使用high level api的。Consumer的delivery gurarantee介陶，默認(rèn)是讀完message先commmit再處理message堤舒，autocommit默認(rèn)是true，這時(shí)候先commit就會(huì)更新offsite+1斤蔓，一旦處理失敗植酥，offsite已經(jīng)+1，這個(gè)時(shí)候就會(huì)丟message弦牡；也可以配置成讀完消息處理再commit友驮，這種情況下consumer端的響應(yīng)就會(huì)比較慢的，需要等處理完才行驾锰。

一般情況下卸留，一定是一個(gè)consumer group處理一個(gè)topic的message。Best Practice是這個(gè)consumer group里面consumer的數(shù)量等于topic里面partition的數(shù)量椭豫，這樣效率是最高的耻瑟，一個(gè)consumer thread處理一個(gè)partition。如果這個(gè)consumer group里面consumer的數(shù)量小于topic里面partition的數(shù)量赏酥，就會(huì)有consumer thread同時(shí)處理多個(gè)partition（這個(gè)是kafka自動(dòng)的機(jī)制喳整，我們不用指定），但是總之這個(gè)topic里面的所有partition都會(huì)被處理到的裸扶。框都。如果這個(gè)consumer group里面consumer的數(shù)量大于topic里面partition的數(shù)量，多出的consumer thread就會(huì)閑著啥也不干呵晨，剩下的是一個(gè)consumer thread處理一個(gè)partition魏保，這就造成了資源的浪費(fèi)，因?yàn)橐粋€(gè)partition不可能被兩個(gè)consumer thread去處理摸屠。所以我們線上的分布式多個(gè)service服務(wù)谓罗，每個(gè)service里面的kafka consumer數(shù)量都小于對(duì)應(yīng)的topic的partition數(shù)量，但是所有服務(wù)的consumer數(shù)量只和等于partition的數(shù)量季二，這是因?yàn)榉植际絪ervice服務(wù)的所有consumer都來自一個(gè)consumer group檩咱，如果來自不同的consumer group就會(huì)處理重復(fù)的message了（同一個(gè)consumer group下的consumer不能處理同一個(gè)partition，不同的consumer group可以處理同一個(gè)topic，那么都是順序處理message税手，一定會(huì)處理重復(fù)的蜂筹。一般這種情況都是兩個(gè)不同的業(yè)務(wù)邏輯，才會(huì)啟動(dòng)兩個(gè)consumer group來處理一個(gè)topic）芦倒。

如果producer的流量增大，當(dāng)前的topic的parition數(shù)量=consumer數(shù)量不翩，這時(shí)候的應(yīng)對(duì)方式就是很想擴(kuò)展：增加topic下的partition兵扬，同時(shí)增加這個(gè)consumer group下的consumer。

? ? ? ? ? ? ? ?

- Delivery Mode : Kafka producer 發(fā)送message不用維護(hù)message的offsite信息口蝠，因?yàn)檫@個(gè)時(shí)候器钟，offsite就相當(dāng)于一個(gè)自增id，producer就盡管發(fā)送message就好了妙蔗。而且Kafka與AMQ不同傲霸，AMQ大都用在處理業(yè)務(wù)邏輯上，而Kafka大都是日志眉反，所以Kafka的producer一般都是大批量的batch發(fā)送message昙啄，向這個(gè)topic一次性發(fā)送一大批message，load balance到一個(gè)partition上寸五，一起插進(jìn)去梳凛，offsite作為自增id自己增加就好。但是Consumer端是需要維護(hù)這個(gè)partition當(dāng)前消費(fèi)到哪個(gè)message的offsite信息的梳杏，這個(gè)offsite信息韧拒，high level api是維護(hù)在Zookeeper上，low level api是自己的程序維護(hù)十性。（Kafka管理界面上只能顯示high level api的consumer部分叛溢，因?yàn)閘ow level api的partition offsite信息是程序自己維護(hù)，kafka是不知道的劲适，無法在管理界面上展示 ）當(dāng)使用high level api的時(shí)候楷掉，先拿message處理，再定時(shí)自動(dòng)commit offsite+1（也可以改成手動(dòng)）, 并且kakfa處理message是沒有鎖操作的减响。因此如果處理message失敗靖诗，此時(shí)還沒有commit offsite+1，當(dāng)consumer thread重啟后會(huì)重復(fù)消費(fèi)這個(gè)message支示。但是作為高吞吐量高并發(fā)的實(shí)時(shí)處理系統(tǒng)刊橘，at least once的情況下，至少一次會(huì)被處理到颂鸿，是可以容忍的促绵。如果無法容忍，就得使用low level api來自己程序維護(hù)這個(gè)offsite信息，那么想什么時(shí)候commit offsite+1就自己搞定了败晴。

- Topic & Partition：Topic相當(dāng)于傳統(tǒng)消息系統(tǒng)MQ中的一個(gè)隊(duì)列queue浓冒，producer端發(fā)送的message必須指定是發(fā)送到哪個(gè)topic，但是不需要指定topic下的哪個(gè)partition尖坤，因?yàn)閗afka會(huì)把收到的message進(jìn)行l(wèi)oad balance稳懒，均勻的分布在這個(gè)topic下的不同的partition上（ hash(message) % [broker數(shù)量]? ）。物理上存儲(chǔ)上慢味，這個(gè)topic會(huì)分成一個(gè)或多個(gè)partition场梆，每個(gè)partiton相當(dāng)于是一個(gè)子queue。在物理結(jié)構(gòu)上纯路，每個(gè)partition對(duì)應(yīng)一個(gè)物理的目錄（文件夾）或油，文件夾命名是[topicname]_[partition]_[序號(hào)]，一個(gè)topic可以有無數(shù)多的partition驰唬，根據(jù)業(yè)務(wù)需求和數(shù)據(jù)量來設(shè)置顶岸。在kafka配置文件中可隨時(shí)更高num.partitions參數(shù)來配置更改topic的partition數(shù)量，在創(chuàng)建Topic時(shí)通過參數(shù)指定parittion數(shù)量叫编。Topic創(chuàng)建之后通過Kafka提供的工具也可以修改partiton數(shù)量芒填。

? 一般來說纤子，（1）一個(gè)Topic的Partition數(shù)量大于等于Broker的數(shù)量，可以提高吞吐率。（2）同一個(gè)Partition的Replica盡量分散到不同的機(jī)器忍弛，高可用涯贞。

? 當(dāng)add a new partition的時(shí)候均践，partition里面的message不會(huì)重新進(jìn)行分配椒袍，原來的partition里面的message數(shù)據(jù)不會(huì)變，新加的這個(gè)partition剛開始是空的寇损，隨后進(jìn)入這個(gè)topic的message就會(huì)重新參與所有partition的load balance

- Partition Replica：每個(gè)partition可以在其他的kafka broker節(jié)點(diǎn)上存副本凸郑，以便某個(gè)kafka broker節(jié)點(diǎn)宕機(jī)不會(huì)影響這個(gè)kafka集群。存replica副本的方式是按照kafka broker的順序存矛市。例如有5個(gè)kafka broker節(jié)點(diǎn)芙沥，某個(gè)topic有3個(gè)partition，每個(gè)partition存2個(gè)副本浊吏，那么partition1存broker1,broker2而昨，partition2存broker2,broker3。找田。歌憨。以此類推（replica副本數(shù)目不能大于kafka broker節(jié)點(diǎn)的數(shù)目，否則報(bào)錯(cuò)墩衙。這里的replica數(shù)其實(shí)就是partition的副本總數(shù)务嫡，其中包括一個(gè)leader甲抖，其他的就是copy副本）。這樣如果某個(gè)broker宕機(jī)心铃，其實(shí)整個(gè)kafka內(nèi)數(shù)據(jù)依然是完整的准谚。但是，replica副本數(shù)越高去扣，系統(tǒng)雖然越穩(wěn)定柱衔，但是回來帶資源和性能上的下降；replica副本少的話厅篓，也會(huì)造成系統(tǒng)丟數(shù)據(jù)的風(fēng)險(xiǎn)秀存。

? （1）怎樣傳送消息：producer先把message發(fā)送到partition leader，再由leader發(fā)送給其他partition follower羽氮。（如果讓producer發(fā)送給每個(gè)replica那就太慢了）

? （2）在向Producer發(fā)送ACK前需要保證有多少個(gè)Replica已經(jīng)收到該消息：根據(jù)ack配的個(gè)數(shù)而定

? （3）怎樣處理某個(gè)Replica不工作的情況：如果這個(gè)部工作的partition replica不在ack列表中，就是producer在發(fā)送消息到partition leader上惫恼，partition leader向partition follower發(fā)送message沒有響應(yīng)而已档押，這個(gè)不會(huì)影響整個(gè)系統(tǒng)，也不會(huì)有什么問題祈纯。如果這個(gè)不工作的partition replica在ack列表中的話令宿，producer發(fā)送的message的時(shí)候會(huì)等待這個(gè)不工作的partition replca寫message成功，但是會(huì)等到time out腕窥，然后返回失敗因?yàn)槟硞€(gè)ack列表中的partition replica沒有響應(yīng)粒没，此時(shí)kafka會(huì)自動(dòng)的把這個(gè)部工作的partition replica從ack列表中移除，以后的producer發(fā)送message的時(shí)候就不會(huì)有這個(gè)ack列表下的這個(gè)部工作的partition replica了簇爆。

? （4）怎樣處理Failed Replica恢復(fù)回來的情況：如果這個(gè)partition replica之前不在ack列表中癞松，那么啟動(dòng)后重新受Zookeeper管理即可，之后producer發(fā)送message的時(shí)候入蛆，partition leader會(huì)繼續(xù)發(fā)送message到這個(gè)partition follower上响蓉。如果這個(gè)partition replica之前在ack列表中，此時(shí)重啟后哨毁，需要把這個(gè)partition replica再手動(dòng)加到ack列表中枫甲。（ack列表是手動(dòng)添加的，出現(xiàn)某個(gè)部工作的partition replica的時(shí)候自動(dòng)從ack列表中移除的）

- Partition leader與follower：partition也有l(wèi)eader和follower之分扼褪。leader是主partition想幻，producer寫kafka的時(shí)候先寫partition leader，再由partition leader push給其他的partition follower话浇。partition leader與follower的信息受Zookeeper控制脏毯，一旦partition leader所在的broker節(jié)點(diǎn)宕機(jī)，zookeeper會(huì)沖其他的broker的partition follower上選擇follower變?yōu)閜arition leader凳枝。

- Topic分配partition和partition replica的算法：（1）將Broker（size=n）和待分配的Partition排序抄沮。（2）將第i個(gè)Partition分配到第（i%n）個(gè)Broker上跋核。（3）將第i個(gè)Partition的第j個(gè)Replica分配到第（(i + j) % n）個(gè)Broker上

- 消息投遞可靠性

一個(gè)消息如何算投遞成功，Kafka提供了三種模式：

- 第一種是啥都不管叛买，發(fā)送出去就當(dāng)作成功砂代，這種情況當(dāng)然不能保證消息成功投遞到broker；

- 第二種是Master-Slave模型率挣，只有當(dāng)Master和所有Slave都接收到消息時(shí)刻伊，才算投遞成功，這種模型提供了最高的投遞可靠性椒功，但是損傷了性能捶箱；

- 第三種模型，即只要Master確認(rèn)收到消息就算投遞成功动漾；實(shí)際使用時(shí)丁屎，根據(jù)應(yīng)用特性選擇，絕大多數(shù)情況下都會(huì)中和可靠性和性能選擇第三種模型

? 消息在broker上的可靠性旱眯，因?yàn)橄?huì)持久化到磁盤上晨川，所以如果正常stop一個(gè)broker，其上的數(shù)據(jù)不會(huì)丟失删豺；但是如果不正常stop共虑，可能會(huì)使存在頁面緩存來不及寫入磁盤的消息丟失，這可以通過配置flush頁面緩存的周期呀页、閾值緩解妈拌，但是同樣會(huì)頻繁的寫磁盤會(huì)影響性能，又是一個(gè)選擇題蓬蝶，根據(jù)實(shí)際情況配置尘分。

? 消息消費(fèi)的可靠性，Kafka提供的是“At least once”模型疾党，因?yàn)橄⒌淖x取進(jìn)度由offset提供音诫，offset可以由消費(fèi)者自己維護(hù)也可以維護(hù)在zookeeper里，但是當(dāng)消息消費(fèi)后consumer掛掉雪位，offset沒有即時(shí)寫回竭钝，就有可能發(fā)生重復(fù)讀的情況，這種情況同樣可以通過調(diào)整commit offset周期雹洗、閾值緩解香罐，甚至消費(fèi)者自己把消費(fèi)和commit offset做成一個(gè)事務(wù)解決，但是如果你的應(yīng)用不在乎重復(fù)消費(fèi)时肿，那就干脆不要解決庇茫，以換取最大的性能。

- Partition ack：當(dāng)ack=1螃成，表示producer寫partition leader成功后旦签，broker就返回成功查坪，無論其他的partition follower是否寫成功。當(dāng)ack=2宁炫，表示producer寫partition leader和其他一個(gè)follower成功的時(shí)候偿曙，broker就返回成功，無論其他的partition follower是否寫成功羔巢。當(dāng)ack=-1[parition的數(shù)量]的時(shí)候望忆，表示只有producer全部寫成功的時(shí)候，才算成功竿秆，kafka broker才返回成功信息启摄。這里需要注意的是，如果ack=1的時(shí)候幽钢，一旦有個(gè)broker宕機(jī)導(dǎo)致partition的follower和leader切換歉备，會(huì)導(dǎo)致丟數(shù)據(jù)。

?

- message狀態(tài)：在Kafka中匪燕，消息的狀態(tài)被保存在consumer中威创，broker不會(huì)關(guān)心哪個(gè)消息被消費(fèi)了被誰消費(fèi)了，只記錄一個(gè)offset值（指向partition中下一個(gè)要被消費(fèi)的消息位置）谎懦，這就意味著如果consumer處理不好的話，broker上的一個(gè)消息可能會(huì)被消費(fèi)多次溃斋。

- message持久化：Kafka中會(huì)把消息持久化到本地文件系統(tǒng)中界拦，并且保持o(1)極高的效率。我們眾所周知IO讀取是非常耗資源的性能也是最慢的梗劫，這就是為了數(shù)據(jù)庫的瓶頸經(jīng)常在IO上享甸，需要換SSD硬盤的原因。但是Kafka作為吞吐量極高的MQ梳侨，卻可以非常高效的message持久化到文件蛉威。這是因?yàn)镵afka是順序?qū)懭雘（1）的時(shí)間復(fù)雜度，速度非匙卟福快蚯嫌。也是高吞吐量的原因。由于message的寫入持久化是順序?qū)懭氲谋铮虼薽essage在被消費(fèi)的時(shí)候也是按順序被消費(fèi)的择示，保證partition的message是順序消費(fèi)的。一般的機(jī)器,單機(jī)每秒100k條數(shù)據(jù)晒旅。

- message有效期：Kafka會(huì)長久保留其中的消息栅盲，以便consumer可以多次消費(fèi)，當(dāng)然其中很多細(xì)節(jié)是可配置的废恋。

- Produer : Producer向Topic發(fā)送message谈秫，不需要指定partition扒寄，直接發(fā)送就好了。kafka通過partition ack來控制是否發(fā)送成功并把信息返回給producer拟烫，producer可以有任意多的thread该编，這些kafka服務(wù)器端是不care的。Producer端的delivery guarantee默認(rèn)是At least once的构灸。也可以設(shè)置Producer異步發(fā)送實(shí)現(xiàn)At most once上渴。Producer可以用主鍵冪等性實(shí)現(xiàn)Exactly once

- Kafka高吞吐量： Kafka的高吞吐量體現(xiàn)在讀寫上，分布式并發(fā)的讀和寫都非诚舶洌快稠氮，寫的性能體現(xiàn)在以o(1)的時(shí)間復(fù)雜度進(jìn)行順序?qū)懭搿Ｗx的性能體現(xiàn)在以o(1)的時(shí)間復(fù)雜度進(jìn)行順序讀取半开， 對(duì)topic進(jìn)行partition分區(qū)隔披，consume group中的consume線程可以以很高能性能進(jìn)行順序讀。

- Kafka delivery guarantee(message傳送保證)：（1）At most once消息可能會(huì)丟寂拆，絕對(duì)不會(huì)重復(fù)傳輸奢米；（2）At least once 消息絕對(duì)不會(huì)丟，但是可能會(huì)重復(fù)傳輸纠永；（3）Exactly once每條信息肯定會(huì)被傳輸一次且僅傳輸一次鬓长，這是用戶想要的。

- 批量發(fā)送：Kafka支持以消息集合為單位進(jìn)行批量發(fā)送尝江，以提高push效率涉波。

- push-and-pull : Kafka中的Producer和consumer采用的是push-and-pull模式，即Producer只管向broker push消息炭序，consumer只管從broker pull消息啤覆，兩者對(duì)消息的生產(chǎn)和消費(fèi)是異步的。

- Kafka集群中broker之間的關(guān)系：不是主從關(guān)系惭聂，各個(gè)broker在集群中地位一樣窗声，我們可以隨意的增加或刪除任何一個(gè)broker節(jié)點(diǎn)。

- 負(fù)載均衡方面： Kafka提供了一個(gè) metadata API來管理broker之間的負(fù)載（對(duì)Kafka0.8.x而言辜纲，對(duì)于0.7.x主要靠zookeeper來實(shí)現(xiàn)負(fù)載均衡）笨觅。

- 同步異步：Producer采用異步push方式，極大提高Kafka系統(tǒng)的吞吐率（可以通過參數(shù)控制是采用同步還是異步方式）侨歉。

- 分區(qū)機(jī)制partition：Kafka的broker端支持消息分區(qū)partition屋摇，Producer可以決定把消息發(fā)到哪個(gè)partition，在一個(gè)partition 中message的順序就是Producer發(fā)送消息的順序幽邓，一個(gè)topic中可以有多個(gè)partition炮温，具體partition的數(shù)量是可配置的。partition的概念使得kafka作為MQ可以橫向擴(kuò)展牵舵，吞吐量巨大柒啤。partition可以設(shè)置replica副本倦挂，replica副本存在不同的kafka broker節(jié)點(diǎn)上，第一個(gè)partition是leader,其他的是follower担巩，message先寫到partition leader上方援，再由partition leader push到parition follower上。所以說kafka可以水平擴(kuò)展涛癌，也就是擴(kuò)展partition犯戏。

- 離線數(shù)據(jù)裝載：Kafka由于對(duì)可拓展的數(shù)據(jù)持久化的支持，它也非常適合向Hadoop或者數(shù)據(jù)倉庫中進(jìn)行數(shù)據(jù)裝載拳话。

- 實(shí)時(shí)數(shù)據(jù)與離線數(shù)據(jù)：kafka既支持離線數(shù)據(jù)也支持實(shí)時(shí)數(shù)據(jù)先匪，因?yàn)閗afka的message持久化到文件，并可以設(shè)置有效期弃衍，因此可以把kafka作為一個(gè)高效的存儲(chǔ)來使用呀非，可以作為離線數(shù)據(jù)供后面的分析。當(dāng)然作為分布式實(shí)時(shí)消息系統(tǒng)镜盯，大多數(shù)情況下還是用于實(shí)時(shí)的數(shù)據(jù)處理的岸裙，但是當(dāng)cosumer消費(fèi)能力下降的時(shí)候可以通過message的持久化在淤積數(shù)據(jù)在kafka。

- 插件支持：現(xiàn)在不少活躍的社區(qū)已經(jīng)開發(fā)出不少插件來拓展Kafka的功能速缆，如用來配合Storm降允、Hadoop、flume相關(guān)的插件艺糜。

- 解耦:? 相當(dāng)于一個(gè)MQ拟糕，使得Producer和Consumer之間異步的操作，系統(tǒng)之間解耦

- 冗余:? replica有多個(gè)副本倦踢，保證一個(gè)broker node宕機(jī)后不會(huì)影響整個(gè)服務(wù)

- 擴(kuò)展性:? broker節(jié)點(diǎn)可以水平擴(kuò)展，partition也可以水平增加侠草，partition replica也可以水平增加

- 峰值:? 在訪問量劇增的情況下辱挥，kafka水平擴(kuò)展, 應(yīng)用仍然需要繼續(xù)發(fā)揮作用

- 可恢復(fù)性:? 系統(tǒng)的一部分組件失效時(shí)，由于有partition的replica副本边涕，不會(huì)影響到整個(gè)系統(tǒng)晤碘。

- 順序保證性：由于kafka的producer的寫message與consumer去讀message都是順序的讀寫，保證了高效的性能功蜓。

- 緩沖：由于producer那面可能業(yè)務(wù)很簡單园爷，而后端consumer業(yè)務(wù)會(huì)很復(fù)雜并有數(shù)據(jù)庫的操作，因此肯定是producer會(huì)比consumer處理速度快式撼，如果沒有kafka童社，producer直接調(diào)用consumer，那么就會(huì)造成整個(gè)系統(tǒng)的處理速度慢著隆，加一層kafka作為MQ扰楼，可以起到緩沖的作用呀癣。

- 異步通信：作為MQ，Producer與Consumer異步通信弦赖。