共計 3422 個字符，預計需要花費 9 分鐘才能閱讀完成。

這篇文章主要介紹“Kafka Producer 相關問題有哪些”，在日常操作中，相信很多人在 Kafka Producer 相關問題有哪些問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Kafka Producer 相關問題有哪些”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！

Producer 相關

    1：我該怎么設置：metadata.broker.list? 

           Producre 會通過 metadata.broker.list 來取得自己所想要的 Metadata，一旦成功取得 metada，生產

      者就會直接發射 Produce 的 request 到這個持有了相對 topic/partition 的 Broker 上。在 Zookeeper 上用  

      ip/port 去注冊這個 Broker，任意的一個 Broker 能夠 Serve 這個 metadata 的請求，Client 必須確保

      在  metadata.broker.list 之中存在有至少一個 Broker 是能夠提供服務的，在一個 load balancer 之中有一種方

      式去 achieve 這些，那就是通過 VIP（目前不知道什么是 VIP）

    2：為什么 Producer 在 async 模式運行的過程之中會得到 QueueFullException？

      這一個現象很典型的發生在 Producer 發射消息的速度要遠遠超過 Broker 能夠處理的速度，如果

      你的日志能夠不允許被 Block，那么唯一的方式就是，不得不添加新的足夠的 Broker，使他們和之前的

      Broker 協同處理，如果您的日志數據是能夠被允許 Block 的，那么您可以通過設置如下：

 queue.enqueueTimeout.ms:-1，

      通過這種方式，一旦我們的隊列滿了，生產者將會 Block 這些數據，而不是直接丟棄。

?  3：當我使用的 Zk_based 的 Producer 在 0.7 版，我只是看到數據在一些 Broker 上消費，而不是全部？?

        這個問題主要和 kafka0.7 系列相關： http://apache.markmail.org/thread/c7tdalfketpusqkg

          簡單點來說，對于一個新的 Topic 而言，Producer 將會使用所有存在的 Brokers，然而，如果 Topic 在其他的 Brokers 之上已經存在，而這個時候你又新添加了新的 Broker，這個時候，這些 Producer 將不會看到這些新添加的 Producer。一個替代的方案是去手動的為這些 Topic，在新添加的 Broker 上創建 log 目錄。

  4：為什么更改壓縮級別以后，我們的 Brokers 并沒有接收到來自于 Producer 生產的數據？

        這個現象發生在當我 通過設置 compression.codec 為 1，試圖開啟 Gzip 壓縮的時候，伴隨著 Codec 的改變，你可能會發現，即便的數據發射已經一秒鐘以后，這一條數據你依舊沒有收到，任何地方都沒有出現日志記錄錯誤，后來通過增加了 log4j.properties 到我的 Producer 的 classPath 并且將日志的記錄級別設置為 DEBUG 模式，我發現了在 Producer 端出現了： org/xerial/snappy/SnappyInputStream NotClass 錯誤，通過添加了 Snappy jar 以后錯誤消失了

    5：我們是否能夠刪除掉 kafka 之中的一個 Topic？

  到目前為止 kafka Version0.8 還不能直接的刪除，如果你要刪除 topic，您需要在刪除 kafka 之中存放的一系列的數據，并且將保持在 Zookeeper 上的狀態和數據一并刪除

Consumers 相關

     1：為什么我們的消費者從來都拿不到數據？

  在默認的情況之下，消費者如果是【歷史第一次開始消費】，那么他它將忽略整個 Topic 之中，所有的現有的數據，他將只是消費目前 Consumer 啟動以后，最新到來的數據。因此，請嘗試在啟動之后多發射一些數據，或者您可以通過設定： auto.offset.reset to smallest .

     2：為什么消費者取數的時候得到：invalidMessageSizeException？

            通常的情況住下，這意味著 消費者的”Fetch.Size“的大小還不夠，每一次消費者從 Broker 提取數據的

過程之中，都會讀取一個已經配置好的上限的數據，如果這個大小，比我們 kafka 單條日志的大小【最大】還要

小，就會拋出 invalidMessageSizeException，要解決這個問題，需要通過設置屬性：

 fetch.message.max.bytes

 fetch.size

默認的 Fetch.Size 的尺寸是 300,000

     3：我是否需為當前的消費者選擇多個 group ID，或則只是一個？

  如果所有的消費者都使用相同的組 id，在主題中的信息就被分發到這些消費者。換句話說，每個消費者

將得到消息的非重疊子集。同一組中擁有更多的消費者增加了并行度和消費的總體吞吐量。另一方面，如果每個

消費者擁有其自己的組 ID，那么每個消費者將得到所有消息的完整的副本。

      4：為什么在一個消費者組中間的一些消費者一直都沒有拿到數據？

              在當前的角度之上，相對于一個 ConusmerGroup 中的 Consumer 而言，一個 Topic 的分區【partition】

就是最小的單元，于是，如果你一個 Consumer 組中間的 Consumer 數量大于 Partition 的數目，那就會有一些

Consumer 空閑得不到數據了。要解決這個問題，可以通過增加你的 Partitions 的數目。

      5：為什么有很多 reblance 在我門的消費者 log 之中？

       【過多平衡調整】的一個典型原因是消費者側 GC。如果是這樣，您將看到 Zookeeper 會話失效在消費者日志（過期 grep）。偶然幾次的 Rebalnce 是有必要的，但是一旦次數過多，那么將降低我們消費 Consumer 的次數，這個時候 Java GC 需要我們去調整

      6：我們可以預測 kafka  consumer rebalance 的結果么？

       7：我自己的 Conusmer 看起來已經停止了，這是為什么？

        8：為什么我的數據 在消費的過程之中出現延遲了。

        9：如何去提高 kafka remote Consumer 的吞吐量？

        10：如何在消費的過程之中重置這個偏移量

         11：如果我不想目前 kafka 自身去管理消費的偏移量，我想自身去管理，那該怎么辦？

          12：Fetch.wait.max.ms 和 Socket.timeout.ms 的關系是怎樣的？

          13：用怎么樣的方式才能從 kafka 拿到一條 精確的消息？

         14：怎么通過 OffsetFetchRequest，用 TimeStamp 去精確得到指定的消息的偏移量

Brokes 相關

        1：kafka 是如何依賴 Zookeeper 的？

        2：為什么控制關閉失敗了？

          3：為什么我的 Consumer/Producer 連接不上 Broker

          4：為什么我們的 Partiton Leaders 會遷移他們自己？

           5：我們能夠擁有多少個 topic？

           6：對于一個 Topic 而言，我們應該如何去選擇分區的數？

           7： Why do I see lots of Leader not local exceptions on the broker during controlled shutdown?

 ——–   中文不太好翻譯  ——–

            8：如何在 ISR 階段減少 Churns？什么時候一個 Broker 會離開 ISR 階段？

            9：每當 Bouncing 一個 Borker，為什么在啟動的時候我們會遭遇到：LeaderNotAvaible or NotLeaderFor Excetpion？

           10：我們是否能夠動態的向集群添加一個新的 Broker？

到此，關于“Kafka Producer 相關問題有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注丸趣 TV 網站，丸趣 TV 小編會繼續努力為大家帶來更多實用的文章！