啥是異步模式

kafka的生產者可以選擇使用異步方式發送數據，所謂異步方式，就是我們調用 send() 方法，并指定一個回調函數， 服務器在返回響應時調用該函數。

kafka在客戶端里暴露了兩個send方法，我們可以自己選擇同步或者異步模式。我們來看一個kafka的生產者發送示例，有個直觀的感受。這個示例是一個同步的模式。

ProducerRecord<String, String> record = new ProducerRecord<>(“Kafka”, “Kafka_Products”, “測試”);//Topic Key Value
try{
Future future = producer.send(record);
future.get();//獲取執行結果
} catch(Exception e) {
e.printStackTrace();
}

我們從源碼層面來繼續看下。

首先kafka定義了一個接口，

然后KafkaProducer實現了這兩個方法，我們看下異步方法的實現邏輯。

可以看到最終是調用doSend方法，調用的時候傳入一個回調。這個回調就是監聽方法的執行結果的。

異步模式也會阻塞的

很多人會認為，既然是異步模式，不管結果是成功還是失敗，肯定方法調用會馬上返回的。那我只能告訴你，不好意思，不一定是這樣。我自己就曾經踩過這個坑。

我們當時有個業務流程需要在執行完成后發送kakfa消息給某個業務方，為了盡量減少影響我這個主流程的執行時間，采用了異步方式發送kafka消息。在使用中，因為配錯了kafka的TOPIC信息，發現流程阻塞發送消息這里長達6秒（kafka默認的發送超時時間）。

究竟為啥異步方式還會阻塞呢？我們繼續看源碼。

不管是同步模式還是異步模式，最終都會調用到doSend方法，注意看上圖中的waitOnMetadata方法，我上面說的阻塞的情況就是阻塞在這個方法里。那我們繼續看這個方法。

通過代碼中的注釋我們大概能了解這個方法的功能，不過我這里還是要解釋下。（防止有人看不懂英文，哈哈）

waitOnMetadata獲取當前的集群元數據信息，如果緩存有，并且分區沒有超過指定分區范圍則緩存返回，否則觸發更新，等待新的metadata。這個等待的操作在下面這行代碼：

metadata.awaitUpdate(version, remainingWaitMs);

然后就繼續跟嘍，

這個方法很好理解，就是一直在等一個條件，這個條件達到了就返回，否則一直等待超時退出。而這個條件就是當前的版本號要大于上個版本號。

那么誰來更新版本號呢？就是我們前面提到的sender線程。當我們的topic配置錯誤的時候導致metadata一直無法更新，然后一直等到超時。