Kafka的消息發(fā)送機(jī)制(ack機(jī)制)

Kfaka的消息發(fā)送機(jī)制(ack機(jī)制)2知識目標(biāo)Kafka消息傳遞語義發(fā)送、消費(fèi)語義ack機(jī)制、總結(jié)01能力目標(biāo)了解Kafka消息語義掌握ack機(jī)制總結(jié)02學(xué)習(xí)目標(biāo)3目錄01Kafka消息傳遞語義02發(fā)送、消費(fèi)的語義03ack機(jī)制04總結(jié)Kafka消息傳遞語義4

對于消息傳遞語義，一般存在三種類型語義:1.Atmostonce-消息傳遞過程中有可能丟失，丟失的消息也不會(huì)重新傳遞，其實(shí)就是保證消息不會(huì)重復(fù)發(fā)送或者重復(fù)消費(fèi)2.Atleastonce-消息在傳遞的過程中不可能會(huì)丟失，丟失的消息會(huì)重新傳遞，其實(shí)就是保證消息不會(huì)丟失，但是消息有可能重復(fù)發(fā)送或者重新被消費(fèi)3.Exactlyonce-這個(gè)是大多數(shù)場景需要的語義，其實(shí)就是保證消息不會(huì)丟失，也不會(huì)重復(fù)被消費(fèi)，消息只傳遞一次

發(fā)送時(shí)的語義5現(xiàn)在假如有這么個(gè)場景:

當(dāng)Producer發(fā)送一條消息給Kafka集群中的某個(gè)topic時(shí)，這個(gè)時(shí)候網(wǎng)絡(luò)出問題了，那么Kafka會(huì)怎么處理呢？在0.11.0.0之前版本的Kafka，因?yàn)椴恢肋@條消息是否發(fā)送成功，會(huì)選擇再一次的重發(fā)這條消息。這就符合Atleastonce語義了，因?yàn)橛龅骄W(wǎng)絡(luò)錯(cuò)誤的那條消息可能發(fā)送成功了，這個(gè)時(shí)候如果再重新發(fā)送的話，就會(huì)導(dǎo)致一條消息被重復(fù)發(fā)送兩次了

在0.11.0.0版本開始，Kafka的Producer開始支持了冪等發(fā)送消息了，其實(shí)說白了，就是重復(fù)發(fā)送一條消息不會(huì)導(dǎo)致brokerserver中存儲兩條一樣的消息了。這樣的話Kafka在消息的發(fā)送的語義就可以達(dá)到Exactlyonce了為了實(shí)現(xiàn)冪等發(fā)送消息，在0.11.0.0版本，Kafka給每一個(gè)Producer一個(gè)唯一的ID，以及給發(fā)送的每一條消息一個(gè)唯一的sequencenumber，利用這兩個(gè)信息就可以在brokerserver段對消息進(jìn)行去重了消費(fèi)時(shí)的語義6

消費(fèi)者消費(fèi)消息的時(shí)候是根據(jù)topic+partition+offset進(jìn)行消費(fèi)的，當(dāng)消費(fèi)者進(jìn)程一切正常的時(shí)候，這個(gè)消費(fèi)之消費(fèi)到的offset的信息可以存放在消費(fèi)者進(jìn)程中的內(nèi)存中但是，假如有這么一個(gè)場景：當(dāng)一個(gè)消費(fèi)者在消費(fèi)某個(gè)topic的某個(gè)partition的時(shí)候，突然間這個(gè)消費(fèi)者進(jìn)程掛了，這個(gè)時(shí)候我們會(huì)再次啟動(dòng)這個(gè)消費(fèi)者進(jìn)程，我們怎么保證繼續(xù)從掛了之前消費(fèi)到的offset開始消費(fèi)消息呢？消費(fèi)時(shí)的語義7

1.消費(fèi)者可以讀取消息，然后將offset保存在持久化系統(tǒng)中，然后消息進(jìn)行處理。那么消費(fèi)者進(jìn)程有可能在保存offset之后，保存處理消息的結(jié)果之前掛掉了，在這種情況下，當(dāng)消費(fèi)者進(jìn)程重新啟動(dòng)后，就會(huì)從已經(jīng)存儲的offset開始消費(fèi)消息并處理消息了，掛掉之前的消費(fèi)者進(jìn)程處理消息的結(jié)果可能還沒來得及保存，所以在這種情況下，有一些消息就可能沒有得到處理了，那么，這種場景是符合Atmostonce語義的，因?yàn)楫?dāng)消費(fèi)者進(jìn)程掛了之后，有些消息可能得不到處理2.消費(fèi)者可以讀取消息，然后處理消息，將處理之后的結(jié)果進(jìn)行保存，最后再保存消費(fèi)到的消息offset了。那么消費(fèi)者進(jìn)程有可能在保存消息處理結(jié)果之后，保存消費(fèi)到的消息offset之前掛了，這種情況下，當(dāng)消費(fèi)者進(jìn)程重新啟動(dòng)的時(shí)候，則從上一次保存的消費(fèi)的消息的offset開始處理消息了，這個(gè)時(shí)候就可能會(huì)導(dǎo)致重復(fù)處理消息了，因?yàn)樵趻斓糁翱赡苡胁糠謹(jǐn)?shù)據(jù)處理成功了。那么這種場景符合Atleastonce語義了，因?yàn)闆]有漏掉處理消息，但是有可能重復(fù)處理消息了。ack機(jī)制8在Producer向Kafka集群發(fā)送一條消息的時(shí)候，如果消息發(fā)送失敗的話，并且我們設(shè)置了retries屬性的話，Producer有重新發(fā)送消息的機(jī)制，這種機(jī)制主要是提高消息的發(fā)送成功率如果我們想Producer發(fā)送的消息一定能發(fā)送成功，不會(huì)丟失的話，除了上面的消息重發(fā)機(jī)制，還有就是ack機(jī)制。ack機(jī)制9一個(gè)topic可以分成多個(gè)partition，每一個(gè)partition可以有多個(gè)副本，在多個(gè)副本中有一個(gè)Leader副本和若干個(gè)Follower副本，Leader副本提供這個(gè)分區(qū)消息的讀寫服務(wù)如果Producer發(fā)送了一條消息，這個(gè)消息如果已經(jīng)發(fā)送并存儲在Leader副本中的日志文件中，那其實(shí)就可以說明這條消息已經(jīng)發(fā)送成功了，但是如果這個(gè)Leader副本可能會(huì)掛掉，所以數(shù)據(jù)只存儲在Leader副本也不能保證數(shù)據(jù)不會(huì)丟，所以有的時(shí)候Producer需要等到發(fā)送的消息都存儲到ISR列表中的備份的時(shí)候才算成功，這個(gè)時(shí)候消息就不容易丟失了根據(jù)上面的特點(diǎn)，Producer在發(fā)送消息的時(shí)候就可以指定acks的值了，acks值可以是[0,1,-1,all],如果是flume是沒有all的ack機(jī)制101.當(dāng)acks=0的時(shí)候，Producer發(fā)送消息到發(fā)送端的buffer中就直接返回了，至于這個(gè)消息有沒有真的發(fā)送到BrokerServer，Producer不關(guān)心，即使消息發(fā)送失敗，上面說的retry機(jī)制也不起作用，所以在這種場景下，可能就會(huì)丟失消息了(類似UDP,只管發(fā),不管對方有沒有接收到消息)2.當(dāng)acks=1的時(shí)候，Producer發(fā)送的消息一定要存儲到對應(yīng)的分區(qū)的Leader副本日志文件中才算消息發(fā)送成功，要是失敗的話，則會(huì)嘗試retry。在這種場景下，只有當(dāng)消息已經(jīng)存儲在Leader副本中，但是消息還沒有被Follower副本同步的時(shí)候，如果Leader副本所在的brokerserver掛了，消息才會(huì)丟失3.當(dāng)acks=-1或者等于all的時(shí)候，Producer發(fā)送的消息一定要存儲到對應(yīng)的分區(qū)的所有的在ISR列表中的副本日志文件中才算消息發(fā)送成功，要是失敗的話，則會(huì)嘗試retry。這種場景下消息就很難丟失了，除非所有的副本所在的BrokerServer都掛了總結(jié)11acks是英文單詞acknowledgments的縮寫，可以表示響應(yīng)，即消息發(fā)送端發(fā)送消息給Kafka集群得到的響應(yīng)，比如acks=all的時(shí)候，只有所有的ISR副本存儲好消息之后才給客戶端一個(gè)響應(yīng)，表示消息存儲成功acks上面的三種取值可以根據(jù)你的業(yè)務(wù)需求來設(shè)置，消息的持久性是越來越強(qiáng)的，但是性能肯定越來越差的，上