3.2.1 分區(qū)策略?
1）分區(qū)的原因?
（1）方便在集群中擴(kuò)展，每個(gè) Partition 可以通過(guò)調(diào)整以適應(yīng)它所在的機(jī)器，而一個(gè) topic又可以有多個(gè) Partition 組成，因此整個(gè)集群就可以適應(yīng)任意大小的數(shù)據(jù)了；?
（2）可以提高并發(fā)，因?yàn)榭梢砸?Partition 為單位讀寫了。?
2）分區(qū)的原則?
我們需要將 producer 發(fā)送的數(shù)據(jù)封裝成一個(gè) ProducerRecord 對(duì)象。?

?
（1）指明 partition 的情況下，直接將指明的值直接作為 partiton 值；?
（2）沒(méi)有指明 partition 值但有 key 的情況下，將 key 的 hash 值與 topic 的 partition?數(shù)進(jìn)行取余得到 partition 值；?
（3）既沒(méi)有 partition 值又沒(méi)有 key 值的情況下，第一次調(diào)用時(shí)隨機(jī)生成一個(gè)整數(shù)（后面每次調(diào)用在這個(gè)整數(shù)上自增），將這個(gè)值與 topic 可用的 partition 總數(shù)取余得到 partition?值，也就是常說(shuō)的 round-robin 算法。?

3.2.2 數(shù)據(jù)可靠性保證?
為保證 producer 發(fā)送的數(shù)據(jù)，能可靠的發(fā)送到指定的 topic，topic 的每個(gè) partition 收到
producer 發(fā)送的數(shù)據(jù)后，都需要向 producer 發(fā)送 ack（acknowledgement 確認(rèn)收到），如果
producer 收到 ack，就會(huì)進(jìn)行下一輪的發(fā)送，否則重新發(fā)送數(shù)據(jù)。?

1）副本數(shù)據(jù)同步策略??

?Kafka 選擇了第二種方案，原因如下：?
1.同樣為了容忍 n 臺(tái)節(jié)點(diǎn)的故障，第一種方案需要 2n+1 個(gè)副本，而第二種方案只需要 n+1個(gè)副本，而 Kafka 的每個(gè)分區(qū)都有大量的數(shù)據(jù)，第一種方案會(huì)造成大量數(shù)據(jù)的冗余。?
2.雖然第二種方案的網(wǎng)絡(luò)延遲會(huì)比較高，但網(wǎng)絡(luò)延遲對(duì) Kafka 的影響較小。?
2）ISR?
?采用第二種方案之后，設(shè)想以下情景：leader 收到數(shù)據(jù)，所有 follower 都開(kāi)始同步數(shù)據(jù)，但有一個(gè) follower，因?yàn)槟撤N故障，遲遲不能與 leader 進(jìn)行同步，那 leader 就要一直等下去，直到它完成同步，才能發(fā)送 ack。這個(gè)問(wèn)題怎么解決呢？??Leader 維護(hù)了一個(gè)動(dòng)態(tài)的 in-sync replica set (ISR)，意為和 leader 保持同步的 follower 集合。當(dāng) ISR 中的 follower 完成數(shù)據(jù)的同步之后，leader 就會(huì)給 follower 發(fā)送 ack。如果 follower長(zhǎng)時(shí)間未 向 leader 同 步 數(shù) 據(jù) ， 則 該 follower 將 被 踢 出 ISR ， 該 時(shí) 間 閾 值 由replica.lag.time.max.ms 參數(shù)設(shè)定。Leader 發(fā)生故障之后，就會(huì)從 ISR 中選舉新的 leader。?
3）ack 應(yīng)答機(jī)制?
對(duì)于某些不太重要的數(shù)據(jù)，對(duì)數(shù)據(jù)的可靠性要求不是很高，能夠容忍數(shù)據(jù)的少量丟失，所以沒(méi)必要等 ISR 中的 follower 全部接收成功。?所以 Kafka 為用戶提供了三種可靠性級(jí)別，用戶根據(jù)對(duì)可靠性和延遲的要求進(jìn)行權(quán)衡，選擇以下的配置。?

acks 參數(shù)配置：?
acks：?
0：producer 不等待 broker 的 ack，這一操作提供了一個(gè)最低的延遲，broker 一接收到還沒(méi)有寫入磁盤就已經(jīng)返回，當(dāng) broker 故障時(shí)有可能丟失數(shù)據(jù)；?
1：producer 等待 broker 的 ack，partition 的 leader 落盤成功后返回 ack，如果在 follower同步成功之前 leader 故障，那么將會(huì)丟失數(shù)據(jù)；?

acks = 1 數(shù)據(jù)丟失案例

-1（all）：producer 等待 broker 的 ack，partition 的 leader 和 follower 全部落盤成功后才返回 ack。但是如果在 follower 同步完成后，broker 發(fā)送 ack 之前，leader 發(fā)生故障，那么會(huì)造成數(shù)據(jù)重復(fù)。?

acks = -1 數(shù)據(jù)重復(fù)案例

4）故障處理細(xì)節(jié)?

? ? Log文件中的HW和LEO

LEO：指的是每個(gè)副本最大的 offset；?
HW：指的是消費(fèi)者能見(jiàn)到的最大的 offset，ISR 隊(duì)列中最小的 LEO。?
（1）follower 故障?
follower 發(fā)生故障后會(huì)被臨時(shí)踢出 ISR，待 該 follower 恢復(fù)后，follower 會(huì)讀取本地磁盤記錄的上次的 HW，并將 log 文件高于 HW 的部分截取掉，從 HW 開(kāi)始向 leader 進(jìn)行同步。等該 follower 的 LEO 大于等于該 Partition 的 HW，即 follower 追上 leader 之后，就可以重新加入 ISR 了。?
（2）leader 故障?
leader 發(fā)生故障之后，會(huì)從 ISR 中選出一個(gè)新的 leader，之后，為保證多個(gè)副本之間的數(shù)據(jù)一致性，其余的 follower 會(huì)先將各自的 log 文件高于 HW 的部分截掉，然后從新的 leader同步數(shù)據(jù)。?

注意：這只能保證副本之間的數(shù)據(jù)一致性，并不能保證數(shù)據(jù)不丟失或者不重復(fù)。?
3.2.3 Exactly Once 語(yǔ)義?
將服務(wù)器的 ACK 級(jí)別設(shè)置為-1，可以保證 Producer 到 Server 之間不會(huì)丟失數(shù)據(jù)，即 At? Least Once 語(yǔ)義。相對(duì)的，將服務(wù)器 ACK 級(jí)別設(shè)置為 0，可以保證生產(chǎn)者每條消息只會(huì)被發(fā)送一次，即 At Most Once 語(yǔ)義。?At Least Once 可以保證數(shù)據(jù)不丟失，但是不能保證數(shù)據(jù)不重復(fù)；相對(duì)的，At Least Once可以保證數(shù)據(jù)不重復(fù)，但是不能保證數(shù)據(jù)不丟失。但是，對(duì)于一些非常重要的信息，比如說(shuō)交易數(shù)據(jù)，下游數(shù)據(jù)消費(fèi)者要求數(shù)據(jù)既不重復(fù)也不丟失，即 Exactly Once 語(yǔ)義。在 0.11 版本以前的 Kafka，對(duì)此是無(wú)能為力的，只能保證數(shù)據(jù)不丟失，再在下游消費(fèi)者對(duì)數(shù)據(jù)做全局去重。對(duì)于多個(gè)下游應(yīng)用的情況，每個(gè)都需要單獨(dú)做全局重，這就對(duì)性能造成了很大影響。?0.11 版本的 Kafka，引入了一項(xiàng)重大特性：冪等性。所謂的冪等性就是指 Producer 不論向 Server 發(fā)送多少次重復(fù)數(shù)據(jù)，Server 端都只會(huì)持久化一條。冪等性結(jié)合 At Least Once 語(yǔ)義，就構(gòu)成了 Kafka 的 Exactly Once 語(yǔ)義。即：?
At Least Once + 冪等性 = Exactly Once?
要啟用冪等性，只需要將 Producer 的參數(shù)中 enable.idompotence 設(shè)置為 true 即可。Kafka的冪等性實(shí)現(xiàn)其實(shí)就是將原來(lái)下游需要做的去重放在了數(shù)據(jù)上游。開(kāi)啟冪等性的 Producer 在初始化的時(shí)候會(huì)被分配一個(gè) PID，發(fā)往同一 Partition 的消息會(huì)附帶 Sequence Number。而B(niǎo)roker 端會(huì)對(duì)<PID, Partition, SeqNumber>做緩存，當(dāng)具有相同主鍵的消息提交時(shí)，Broker 只會(huì)持久化一條。?但是 PID 重啟就會(huì)變化，同時(shí)不同的 Partition 也具有不同主鍵，所以冪等性無(wú)法保證跨分區(qū)跨會(huì)話的 Exactly Once。?

總結(jié)一句話：這個(gè)冪等性只能解決單次會(huì)話數(shù)據(jù)不重復(fù)，根據(jù)這個(gè)PID?Partition??SeqNumber三個(gè)條件確定是不是同一條數(shù)據(jù)，來(lái)保證數(shù)據(jù)不重復(fù)

總結(jié)

以上是生活随笔為你收集整理的大数据技术之 Kafka (第 3 章 Kafka 架构深入 ) Kafka 生产者的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。