如何分析數(shù)據(jù)通過中轉(zhuǎn)后傳輸?shù)終afka集群的過程

如何分析數(shù)據(jù)通過中轉(zhuǎn)后傳輸?shù)終afka集群的過程，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

由于當前海外的數(shù)據(jù)節(jié)點較多,同時也較為分散,原本海外數(shù)據(jù)直接通過公網(wǎng)寫入到Kafka由于當前海外的數(shù)據(jù)節(jié)點較多,同時也較為分散,原本海外數(shù)據(jù)直接通過公網(wǎng)寫入到Kafka集群中。但是由于海外網(wǎng)絡進行公網(wǎng)傳遞的問題，存在非常大的延遲。導致某些業(yè)務直接無法使用。例如異常告警等。

海外數(shù)據(jù)延遲問題

我們海外的節(jié)點很多，但是又非常的分散。可能某個國家僅僅有幾臺機器，為了實現(xiàn)日志分析的業(yè)務需要把海外的數(shù)據(jù)傳輸回國內(nèi)的數(shù)據(jù)中心上來。當前的選型是通過Kafka進行傳輸。直接通過公網(wǎng)的方式把數(shù)據(jù)寫入到Kafka，國內(nèi)的數(shù)據(jù)中心節(jié)點對Kafka的數(shù)據(jù)進行消費。

國內(nèi)的公網(wǎng)傳輸?shù)难舆t也還可以，因為我們本身對于數(shù)據(jù)的延遲性要求也不是太高?？赡苣承└婢惖臉I(yè)務需要考慮延遲性。

隨著告警業(yè)務的增多，對于海外數(shù)據(jù)的延遲性有了一些要求，但是在實際使用中發(fā)現(xiàn)，海外數(shù)據(jù)的延遲問題非常大

這里是ping的當時的狀態(tài)?？梢钥吹絹G包與時延都很高，同時又進行了traceroute的跟蹤，發(fā)現(xiàn)某些數(shù)據(jù)的寫入繞著地球轉(zhuǎn)了半圈再回到國內(nèi) (好想做一個數(shù)據(jù)包一秒鐘環(huán)游世界)

不同的地區(qū)的延時不一樣，最嚴重的地區(qū)丟包非常的高，時延也非常的高。

解決方案

咨詢了相關的廠商，給予了三個解決方案。專線、海外計算獲得結(jié)果后只傳輸結(jié)果、搭建中轉(zhuǎn)節(jié)點。分析到最后，最終選擇了中轉(zhuǎn)節(jié)點的方案。

我們選擇了一個網(wǎng)絡情況較好的某個地區(qū)進行網(wǎng)絡測試，就是從其他的各個節(jié)點中傳輸數(shù)據(jù)到該地區(qū)的服務器，查看網(wǎng)絡狀況，最終測試結(jié)果網(wǎng)絡最差的地區(qū)仍然有200ms的時延，但是丟包情況已經(jīng)基本不存在。而通過該中轉(zhuǎn)節(jié)點到Kafka節(jié)點的時延在30ms左右。

ok，那么現(xiàn)在就在該節(jié)點搭建了一臺服務器進行日志數(shù)據(jù)的傳輸。

搭建nginx進行數(shù)據(jù)中轉(zhuǎn)

由于Kakfa使用的TCP協(xié)議，nginx的搭建也比較簡單，直接把接收到的相關的數(shù)據(jù)直接透傳到Kafka節(jié)點即可,配置如下

stream {
	upstream proxy_port {
		hash $remote_addr consistent;
	server kafka_1:9092;
	server kafka_1:9092;
	server kafka_1:9092;
	}
	server {
		listen     9000;
		proxy_connect_timeout 20s;
		proxy_timeout 5m;
		proxy_pass proxy_port;
	}
}

配置完成后，producer節(jié)點修改為寫入到nginx的 9000端口，觀察發(fā)現(xiàn)數(shù)據(jù)已經(jīng)通過中轉(zhuǎn)節(jié)點寫入成功。

同時數(shù)據(jù)的延遲問題得到了很大的改善，當然仍然有部分節(jié)點存在寫入到中轉(zhuǎn)節(jié)點的時延較高，但是丟包情況基本上得到解決。當然，公網(wǎng)傳輸仍然可能出現(xiàn)問題。但是基本已滿足要求。

跨境數(shù)據(jù)的傳輸需要進行相關合法性審查。

關于如何分析數(shù)據(jù)通過中轉(zhuǎn)后傳輸?shù)終afka集群的過程問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業(yè)資訊頻道了解更多相關知識。