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

今天就跟大家聊聊有關 Kafka 數據中轉傳輸的示例分析，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

需求起源

由于某些海外節點的數據發送到 Kafka 的上海集群會產生較高的延遲, 因為公網訪問的時候數據可能會進行多次中轉, 而導致網絡延遲較高。所以增加了一個地區中轉，該地區的網絡情況到所有的節點的網絡情況較好 (廠商推薦)。

所以想把數據通過該地區做一次中轉，再發送到上海。這樣來看整體時延約 120ms+。所以在 Kafka 的 producer 直接把 host 配置為該中轉節點。經過測試，發現數據能夠到上海。

設想的數據流程

出現異常，延遲依然很高

通過幾天的觀察，發現峰值時刻的異常依然很高，而當時地區節點之間的網絡情況還不錯。其他地區到中轉地區節點的時延約 90ms+，中轉地區到上海節點的時延約 30ms+。修改了 ping 數據包的大小, 數量。發現丟包率, 時延等一切都很正常。Kafka 數據依然延遲。

網絡原因基本排除。那么就是其他的原因。

Kafka 壓力測試

后來在某地區節點購買了一臺服務器，使用  kafka-producer-perf-test 進行壓力測試，直接出現大量的 timeout。網絡情況非常不好。

但是 ping 的結果還好啊 …

查看程序日志

查看進程發送的日志，從日志上發現一個問題。由于我使用了 nginx 進行轉發，所以我數據發送到 nginx 的端口修改成了 9000，也就是 producer 配置的是 nginx 的 host:9000，但是我發現我日志上出現的依然是發送至 kafka 的端口：9092。
進程沒有重啟？應該所有人的第一反應就是這個，所以重啟進行咯 …
重啟進程，盯日志 …

發現請求發送到 nginx 的 9000 端口.. 這次應該是對了 …

緊接著出來建立鏈接  kafka1:9092,kafka2:9092,kafka3:9092

一臉懵逼, 重啟依然是這樣 … 盯了一下 nginx 服務器的網絡，最近幾天的帶寬太低了 …

查找原因

基于以上問題, 基本可以判斷。producer 發送的數據絕對沒有通過 nginx。查詢相關文檔發現。

Kafka 無法把數據通過 nginx 代理方式進行傳輸，而通過 nginx 的只有首次連接。producer 節點通過 nginx 獲取到 kafka 的 metadata 信息。然后通過 metadata 里面的 IP 進行訪問 …

也就是說實際通過 nginx 的方式是這樣的, 首次發送只是通過 nginx 獲取到 metadata 的信息,metadata 包含 kafka 的 broker 各 ip 地址。然后 producer 則會直接把數據發送到 kafka 集群。

看完上述內容，你們對 Kafka 數據中轉傳輸的示例分析有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。