柚子快報(bào)邀請(qǐng)碼778899分享：分布式 Kafka問題紀(jì)要

http://yzkb.51969.com/

1. 取 如何獲取 topic 主題的列表

bin/kafka-topics.sh --list --zookeeper localhost:2181

2. 生產(chǎn)者和消費(fèi)者的命令行是什么？

生產(chǎn)者在主題上發(fā)布消息： bin/kafka-console-producer.sh --broker-list 192.168.43.49:9092 --topicHello-Kafka 注意這里的 IP 是 server.properties 中的 listeners 的配置。接下來每個(gè)新行就是輸入一條 新消息。 消費(fèi)者接受消息： bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topicHello-Kafka --from-beginning

3. consumer 是推還是拉？

Kafka 最初考慮的問題是，customer 應(yīng)該從 brokes 拉取消息還是 brokers 將消息推送到 consumer，也就是 pull 還 push。在這方面，Kafka 遵循了一種大部分消息系統(tǒng)共同的傳統(tǒng) 的設(shè)計(jì)： producer 將消息推送到 broker，consumer 從 broker 拉取消息。 一些消息系統(tǒng)比如 Scribe 和 Apache Flume 采用了 push 模式，將消息推送到下游的 consumer。這樣做有好處也有壞處：由 broker 決定消息推送的速率，對(duì)于不同消費(fèi)速率的 consumer 就不太好處理了。消息系統(tǒng)都致力于讓 consumer 以最大的速率最快速的消費(fèi)消 息，但不幸的是，push 模式下， 當(dāng) broker 推送的速率遠(yuǎn)大于 consumer 消費(fèi)的速率時(shí)，consumer 恐怕就要崩潰了。最終 Kafka 還是選取了傳統(tǒng)的 pull 模式。 Pull 模式的另外一個(gè)好處是 consumer 可以自主決定是否批量的從 broker 拉取數(shù)據(jù) 。 Push 模式必須在不知道下游 consumer 消費(fèi)能力和消費(fèi)策略的情況下決定是立即推送每條 消息還是緩存之后批量推送。如果為了避免 consumer 崩潰而采用較低的推送速率，將可能 導(dǎo)致一次只推送較少的消息而造成浪費(fèi)。Pull 模式下，consumer 就可以根據(jù)自己的消費(fèi)能 力去決定這些策略。 Pull 有個(gè)缺點(diǎn)是，如果 broker 沒有可供消費(fèi)的消息，將導(dǎo)致 consumer 不斷在循環(huán)中輪詢， 直到新消息到 t 達(dá)。為了避免這點(diǎn)，Kafka 有個(gè)參數(shù)可以讓 consumer 阻塞知道新消息到達(dá) (當(dāng)然也可以阻塞知道消息的數(shù)量達(dá)到某個(gè)特定的量這樣就可以批量發(fā)送)。

4. 講 講講 kafka 維護(hù)消費(fèi)狀態(tài)跟蹤的方法

大部分消息系統(tǒng)在 broker 端的維護(hù)消息被消費(fèi)的記錄：一個(gè)消息被分發(fā)到 consumer 后 broker 就 上進(jìn)行標(biāo)記或者等待 customer 的通知后進(jìn)行標(biāo)記。這樣也可以在消息在消費(fèi)后 立 就刪除以減少空間占用。但是這樣會(huì)不會(huì)有什么問題呢？如果一條消息發(fā)送出去之后就 立即被標(biāo)記為消費(fèi)過的，旦 consumer 處理消息時(shí)失敗了（比如程序崩潰）消息就丟失了。 為了解決這個(gè)問題，很多消息系統(tǒng)提供了另外一個(gè)個(gè)功能：當(dāng)消息被發(fā)送出去之后僅僅被標(biāo) 記為已發(fā)送狀態(tài)，當(dāng)接到 consumer 已經(jīng)消費(fèi)成功的通知后才標(biāo)記為已被消費(fèi)的狀態(tài)。這雖 然解決了消息丟失的問題，但產(chǎn)生了新問題，首先如果 consumer 處理消息成功了但是向 broker 發(fā)送響應(yīng)時(shí)失敗了，這條消息將被消費(fèi)兩次。第二個(gè)問題時(shí)，broker 必須維護(hù)每條 消息的狀態(tài)，并且每次都要先鎖住消息然后更改狀態(tài)然后釋放鎖。這樣麻煩又來了，且不說 要維護(hù)大量的狀態(tài)數(shù)據(jù)，比如如果消息發(fā)送出去但沒有收到消費(fèi)成功的通知，這條消息將一 直處于被鎖定的狀態(tài)，Kafka 采用了不同的策略。Topic 被分成了若干分區(qū)，每個(gè)分區(qū)在同 一時(shí)間只被一個(gè) consumer 消費(fèi)。這意味著每個(gè)分區(qū)被消費(fèi)的消息在日志中的位置僅僅是一 個(gè)簡(jiǎn)單的整數(shù)：offset。這樣就很容易標(biāo)記每個(gè)分區(qū)消費(fèi)狀態(tài)就很容易了，僅僅需要一個(gè)整 數(shù)而已。這樣消費(fèi)狀態(tài)的跟蹤就很簡(jiǎn)單了。 這帶來了另外一個(gè)好處：consumer 可以把 offset 調(diào)成一個(gè)較老的值，去重新消費(fèi)老的消息。

5. 講一下主從同步

Kafka 允許 topic 的分區(qū)擁有若干副本，這個(gè)數(shù)量是可以配置的，你可以為每個(gè) topci 配置副 本的數(shù)量。Kafka 會(huì)自動(dòng)在每個(gè)個(gè)副本上備份數(shù)據(jù)，所以當(dāng)一個(gè)節(jié)點(diǎn) down 掉時(shí)數(shù)據(jù)依然是 可用的。 Kafka 的副本功能不是必須的，你可以配置只有一個(gè)副本，這樣其實(shí)就相當(dāng)于只有一份數(shù)據(jù)。

6. 為什么需要消息系統(tǒng)，mysql 不能滿足需求嗎？

（1）解耦： 允許你獨(dú)立的擴(kuò)展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。 （2）冗余： 消息隊(duì)列把數(shù)據(jù)進(jìn)行持久化直到它們已經(jīng)被完全處理，通過這一方式規(guī)避了數(shù)據(jù)丟失 險(xiǎn)。 許多消息隊(duì)列所采用的”插入-獲取-刪除”范式中，在把一個(gè)消息從隊(duì)列中刪除之前，需要 你的處理系統(tǒng)明確的指出該消息已經(jīng)被處理完畢，從而確保你的數(shù)據(jù)被安全的保存直到你使 用完畢。 （3）擴(kuò)展性： 因?yàn)橄㈥?duì)列解耦了你的處理過程，所以增大消息入隊(duì)和處理的頻率是很容易的，只要另外 增加處理過程即可。 （4）靈活性 & 峰值處理能力： 在訪問量劇增的情況下，應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量并不常 。如果 為以能處理這類峰值訪問為標(biāo)準(zhǔn)來投入資源隨時(shí)待命無疑是巨大的浪費(fèi)。使用消息隊(duì)列能夠 使關(guān)鍵組件頂住突發(fā)的訪問壓力，而不會(huì)因?yàn)橥话l(fā)的超負(fù)荷的請(qǐng)求而完全崩潰。 （5）可恢復(fù)性： 系統(tǒng)的一部分組件失效時(shí)，不會(huì)影響到整個(gè)系統(tǒng)。消息隊(duì)列降低了進(jìn)程間的耦合度，所以即 使一個(gè)處理消息的進(jìn)程掛掉，加入隊(duì)列中的消息仍然可以在系統(tǒng)恢復(fù)后被處理。 （6）順序保證： 在大多使用場(chǎng)景下，數(shù)據(jù)處理的順序都很重要。大部分消息隊(duì)列本來就是排序的，并且能保 證數(shù)據(jù)會(huì)按照特定的順序來處理。（Kafka 保證一個(gè) Partition 內(nèi)的消息的有序性） （7）緩沖： 有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度，解決生產(chǎn)消息和消費(fèi)消息的處理速度不一致的情 況。 （8）異步通信： 很多時(shí)候，用戶不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許用戶把一 個(gè)消息放入隊(duì)列，但并不立即處理它。想向隊(duì)列中放入多少消息就放多少，然后在需要的時(shí) 候再去處理它們。

7. Zookeeper 于 對(duì)于 Kafka 的作用是什么？

Zookeeper 是一個(gè)開放源碼的、高性能的協(xié)調(diào)服務(wù)，它用于 Kafka 的分布式應(yīng)用。 Zookeeper 主要用于在集群中不同節(jié)點(diǎn)之間進(jìn)行通信 在 Kafka 中，它被用于提交偏移量，因此如果節(jié)點(diǎn)在任何情況下都失敗了，它都可以從之 前提交的偏移量中獲取除此之外，它還執(zhí)行其他活動(dòng)，如: leader 檢測(cè)、分布式同步、配置 管理、識(shí)別新節(jié)點(diǎn)何時(shí)離開或連接、集群、節(jié)點(diǎn)實(shí)時(shí)狀態(tài)等等。

8. 數(shù)據(jù)傳輸?shù)氖聞?wù)定義有哪三種？

和 MQ TT 的事務(wù)定義一樣都是 3 種。 （1）最多一次: 消息不會(huì)被重復(fù)發(fā)送，最多被傳輸一次，但也有可能一次不傳輸 （2）最少一次: 消息不會(huì)被漏發(fā)送，最少被傳輸一次，但也有可能被重復(fù)傳輸. （3）精確的一次（Exactly once）: 不會(huì)漏傳輸也不會(huì)重復(fù)傳輸,每個(gè)消息都傳輸被一次而且 僅僅被傳輸一次，這是大家所期望的

9. Kafka 判斷一個(gè)節(jié)點(diǎn)是否還活著有那兩個(gè)條件？

（1）節(jié)點(diǎn)必須可以維護(hù)和 ZooKeeper 的連接，Zookeeper 通過心跳機(jī)制檢查每個(gè)節(jié)點(diǎn)的連 接 （2）如果節(jié)點(diǎn)是個(gè) follower,他必須能及時(shí)的同步 leader 的寫操作，延時(shí)不能太久

10. Kafka 統(tǒng) 與傳統(tǒng) MQ 消息系統(tǒng)之間有三個(gè)關(guān)鍵區(qū)別

(1).Kafka 持久化日志，這些日志可以被重復(fù)讀取和無限期保留 (2).Kafka 是一個(gè)分布式系統(tǒng)：它以集群的方式運(yùn)行，可以靈活伸縮，在內(nèi)部通過復(fù)制數(shù)據(jù) 提升容錯(cuò)能力和高可用性 (3).Kafka 支持實(shí)時(shí)的流式處理

11. 講 講一講 kafka 的 的 ack 的三種機(jī)制

request.required.acks 有三個(gè)值 0 1 -1(all) 0:生產(chǎn)者不會(huì)等待 broker 的 ack，這個(gè)延遲最低但是存儲(chǔ)的保證最弱當(dāng) server 掛掉的時(shí)候 就會(huì)丟數(shù)據(jù)。 1：服務(wù)端會(huì)等待 ack 值 leader 副本確認(rèn)接收到消息后發(fā)送 ack 但是如果 leader 掛掉后 他不確保是否復(fù)制完成新 leader 也會(huì)導(dǎo)致數(shù)據(jù)丟失。 -1(all)：服務(wù)端會(huì)等所有的 follower 的副本受到數(shù)據(jù)后才會(huì)受到 leader 發(fā)出的 ack，這樣數(shù) 據(jù)不會(huì)丟失

12. 消費(fèi)者如何不自動(dòng)提交偏移量，由應(yīng)用提交？

將 auto.commit.offset 設(shè)為 false，然后在處理一批消息后 commitSync() 或者異步提交 commitAsync()

13. 消費(fèi)者故障，出現(xiàn)活鎖問題如何解決？

出現(xiàn)“活鎖”的情況，是它持續(xù)的發(fā)送心跳，但是沒有處理。為了預(yù)防消費(fèi)者在這種情況下 一直持有分區(qū)，我們使用 max.poll.interval.ms 活躍檢測(cè)機(jī)制。 在此基礎(chǔ)上，如果你調(diào)用的 poll 的頻率大于最大間隔，則客戶端將主動(dòng)地離開組，以便其他消費(fèi)者接管該分區(qū)。 發(fā)生 這種情況時(shí)，你會(huì)看到 offset 提交失?。ㄕ{(diào)用 commitSync （）引發(fā)的 CommitFailedException）。 這是一種安全機(jī)制，保障只有活動(dòng)成員能夠提交 offset。所以要留在組中，你必須持續(xù)調(diào)用 poll。 消費(fèi)者提供兩個(gè)配置設(shè)置來控制 poll 循環(huán)： max.poll.interval.ms：增大 poll 的間隔，可以為消費(fèi)者提供更多的時(shí)間去處理返回的消息（調(diào) 用 poll(long)返回的消息，通常返回的消息都是一批）。缺點(diǎn)是此值越大將會(huì)延遲組重新平衡。 max.poll.records：此設(shè)置限制每次調(diào)用 poll 返回的消息數(shù)，這樣可以更容易的預(yù)測(cè)每次 poll 間隔要處理的最大值。通過調(diào)整此值，可以減少 poll 間隔，減少重新平衡分組的 對(duì)于消息處理時(shí)間不可預(yù)測(cè)地的情況，這些選項(xiàng)是不夠的。 處理這種情況的推薦方法是將 消息處理移到另一個(gè)線程中，讓消費(fèi)者繼續(xù)調(diào)用 poll。 但是必須注意確保已提交的 offset 不超過實(shí)際位置。另外，你必須禁用自動(dòng)提交，并只有在線程完成處理后才為記錄手動(dòng)提交 偏移量（取決于你）。 還要注意，你需要 pause 暫停分區(qū)，不會(huì)從 poll 接收到新消息，讓 線程處理完之前返回的消息（如果你的處理能力比拉取消息的慢，那創(chuàng)建新線程將導(dǎo)致你機(jī) 器內(nèi)存溢出）。

14. 如何控制消費(fèi)的位置

kafka 使用 seek(TopicPartition, long)指定新的消費(fèi)位置。用于查找服務(wù)器保留的最早和最新 的 offset 的特殊的方法也可用（seekToBeginning(Collection) 和 seekToEnd(Collection)）

15. kafka 分布式 （ 不是單機(jī) ） 的情況下 ， 如何保證消息的

順序消費(fèi)? Kafka 分布式的單位是 partition，同一個(gè) partition 用一個(gè) write ahead log 組織，所以可以 保證 FIFO 的順序。不同 partition 之間不能保證順序。但是絕大多數(shù)用戶都可以通過 message key 來定義，因?yàn)橥粋€(gè) key 的 message 可以保證只發(fā)送到同一個(gè) partition。 Kafka 中發(fā)送 1 條消息的時(shí)候，可以指定(topic, partition, key) 3 個(gè)參數(shù)。partiton 和 key 是 可選的。如果你指定了 partition，那就是所有消息發(fā)往同 1 個(gè) partition，就是有序的。并 且在消費(fèi)端， Kafka 保證，1 個(gè) partition 只能被 1 個(gè) consumer 消費(fèi)?；蛘吣阒付?key （ 比如 order id），具有同 1 個(gè) key 的所有消息，會(huì)發(fā)往同 1 個(gè) partition。

16. kafka 如何減少數(shù)據(jù)丟失

Kafka 到底會(huì)不會(huì)丟數(shù)據(jù)(data loss)? 通常不會(huì)，但有些情況下的確有可能會(huì)發(fā)生。下面的參 數(shù)配置及 Best practice 列表可以較好地保證數(shù)據(jù)的持久性(當(dāng)然是 trade-off，犧牲了吞吐量)。

block.on.buffer.full = true

acks = all

retries = MAX_VALUE

max.in.flight.requests.per.connection = 1

使用 KafkaProducer.send(record, callback)

callback 邏輯中顯式關(guān)閉 producer：close(0)

unclean.leader.election.enable=false

replication.factor = 3

min.insync.replicas = 2

replication.factor > min.insync.replicas

enable.auto.commit=false

消息處理完成之后再提交位移

17. kafka 如何不消費(fèi)重復(fù)數(shù)據(jù)？比如扣款。

其實(shí)還是得結(jié)合業(yè)務(wù)來思考，我這里給幾個(gè)思路： 比如你拿個(gè)數(shù)據(jù)要寫庫，你先根據(jù)主鍵查一下，如果這數(shù)據(jù)都有了，你就別插入了，update 一下好吧。 比如你是寫 Redis，那沒問題了，反正每次都是 set，天然冪等性。 比如你不是上面兩個(gè)場(chǎng)景，那做的稍微復(fù)雜一點(diǎn)，你需要讓生產(chǎn)者發(fā)送每條數(shù)據(jù)的時(shí)候，里 面加一個(gè)全局唯一的 id，類似訂單 id 之類的東西，然后你這里消費(fèi)到了之后，先根據(jù)這個(gè) id 去比如 Redis 里查一下，之前消費(fèi)過嗎？如果沒有消費(fèi)過，你就處理，然后這個(gè) id 寫 Redis。如果消費(fèi)過了，那你就別處理了，保證別重復(fù)處理相同的消息即可。 比如基于數(shù)據(jù)庫的唯一鍵來保證重復(fù)數(shù)據(jù)不會(huì)重復(fù)插入多條。因?yàn)橛形ㄒ绘I約束了，重復(fù)數(shù) 據(jù)插入只會(huì)報(bào)錯(cuò)，不會(huì)導(dǎo)致數(shù)據(jù)庫中出現(xiàn)臟數(shù)據(jù)。

小白路漫漫，讓我們一起加油?。?！

柚子快報(bào)邀請(qǐng)碼778899分享：分布式 Kafka問題紀(jì)要

http://yzkb.51969.com/

好文推薦